Analysis / Op-Ed /

Kubernetes and the Microservices Hierarchy of Needs

17 Feb 2017 12:00pm, by

Devised by psychologist Albert Maslow, the Hierarchy of Needs is a psychological theory to explain human motivation, comprising of multitier model of human needs, often depicted as hierarchical levels within a pyramid. Maslow uses terms such as physiological, safety, belongingness and love, esteem, self-actualization, and self-transcendence to describe the stages that human motivation generally moves through. As human beings, first we need our basic needs satisfied, then the psychological ones, and only then we can think of self esteem and achieving our full potential:

The Maslow Hierarchy of Needs

This approach of describing needs is so fundamental that it has been applied to many other domains such as employee engagement, cloud computing, software development, DevOps, etc. So it would make sense to apply it to microservices too, as there is a clear list of needs that has to be satisfied in order to be successful in the microservices journey. So here it is:

The Microservices Hierarchy of Needs

Once I listed the main microservices concerns (the order may vary for you) I couldn’t stop myself noticing that the Kubernetes container orchestration engine does cover a big chunk of these needs pretty well. So I’ve added Kubernetes to the diagram as well.

First, for the base layers, we need some compute resources and ideally have a scalable Standard Operating Environment managed by an infrastructure services cloud provider. Other prerequisites are an automated CI/CD process and artifact registries which Kubernetes can help us to run and manage as well. Still, we will need some specialized software such as Jenkins for builds, and artifact repository such as on-premise Sonatype’s Nexus for Docker and Maven artifacts, or Docker Hub.

Then Kubernetes can help us manage multiple isolated environments (namespaces), manage resources (quotas and limits), storage allocation (persistent volumes), perform deployments and rollbacks (deployments), automated scheduling (scheduler), service discovery and load balancing (services), resilience and fault tolerance (pod health checks).

Bilgin Ibryam
Bilgin Ibryam is an Architect at Red Hat and open source committer at Apache for Camel, OFBiz and Isis projects. He is a blogger, speaker, open-source enthusiast and the author of Camel Design Patterns and Instant Apache Camel Message Routing books. In his day-to-day job, Bilgin enjoys mentoring, training and leading teams to be successful with application integration, distributed systems, microservices, devops, and cloud-native applications.

For some of the needs, we will also need additional tools, such as Docker or rkt for container implementation, in-app resiliency libraries (such as Netflix’s Hystrix) to combine with Kubernetes resiliency features. Then Kubernetes can manage application configurations, and also help us run best of breed centralized logging, metrics collection and tracing software which also becomes important with growing number of services.

Depending on the nature of the Microservices, we may have some specific needs. For API driven Microservices, we will need specialized API Management solution which can also handle service security (not provided by Kubernetes). But Kubernetes can help us run stateful services (StatefulSet), batch jobs (job), and scheduled jobs (cron job) easily.

Having all these features provided by one platform allows the user to perform some more intelligent activities such as application and infrastructure auto scaling and self-healing, through auto-placement, auto-restart, auto-replication, auto-scaling.

With all these needs satisfied by Kubernetes, what is left for the team is to streamline the development processes, embrace the DevOps culture for fast delivery, and achieve Antifragility at organization level.

Red Hat is a sponsor of The New Stack.

Feature image: The Mayan ruins of Chichén Itzá, courtesy of Pixabay.

A digest of the week’s most important stories & analyses.

View / Add Comments