Throw a rock in an airport bookstore and you’ll find a management book explaining that success comes from making decisions based on data and responding to change quickly. Terms like data-driven, engineering-driven and Agile IT are more than business buzzwords. These concepts are changing the way applications are developed, operated and maintained. Practically implementing these in the real world, however, is something many organizations still struggle with.
KubeCon + CloudNativeCon is centered on this theme and Kubernetes, which is at the center of the Agile IT revolution. Juniper will be at the conference next week in sunny San Diego as a platinum sponsor.
Kubernetes is part management application, part orchestration platform and part kitchen sink. Over the past decade, many container orchestration platforms have emerged to compete for mind share and corporate cash. When the dust settled, Kubernetes won. But what are containers and why are they important? What drives their adoption in the real world?
A Monolithic Problem
Organizations looking to become more responsive to change realize this really means IT needs to be more responsive to change. For this to happen, applications should be regularly updated in a non-disruptive fashion and be able to scale according to business needs. Plus, both of these feats need to be performed in a cost-efficient manner
Traditional application design creates monolithic applications consisting of a small number of large executables. To update any part of the application, one needs to update the entire application. In addition, the only way to scale monolithic applications is to provide more resources to the server or virtual instance that runs that application. This is a significant challenge because there are very real, hard limits to how many resources a single server or virtual instance can have.
In order to respond to change quickly, including grow rapidly when needed, organizations needed to change how application development was done. A number of movements occurred over the years to accomplish this, with Agile and DevOps being the most notable.
Agile aimed to change how developers responded to change requests during the development phase. DevOps aimed to bring developers and operations teams closer together to ensure that developers get rapid feedback about how the changes they make to applications affect their operation.
Modern modular architectures, often referred to as microservices, enable both high availability through application component redundancy and high performance through the scale-out approach. The microservices model of application development enabled both Agile and DevOps, led to the adoption of containers and set the stage for the rise of Kubernetes. But what are microservices?
The Microservices Solution
The ideal microservices application consists of a bunch of individual “services” that act together to create a whole greater than the sum of its parts. Instead of being one large monolithic blob, microservices-based applications are broken up into a bunch of smaller workloads.
In an ideal microservices application, each individual service can be scaled independently of the others, simply by adding more instances of a given service type. If the database is a bottleneck, for example, simply add more database instances. To make an update to a given service, spin up new instances of a service that uses the new code, then retire instances with the old code.
This approach has the added benefit of making it much easier to live test code changes. With a microservices-based application, developers can spin up a limited number of service instances with the new code and direct some portion of traffic to them. This canary testing allows changes to be tested on a small subset of users before being rolled out to all.
Microservices-based applications rely on having multiple instances of multiple services that all make up a single application. If organizations have to use a VM or bare-metal server for each instance, this approach would get costly quite quickly. Containers allow multiple applications – or microservices – to share a single operating system. This allows for greater instance density in the same physical hardware footprint, but comes at a cost: if the host VM or server is restarted, all containers operating on that system will be terminated.
In our upcoming blogs, we will delve more into how Kubernetes orchestration works wonders for orchestrating microservices but leaves certain challenges as an exercise for the Kubernetes operator. You may not be surprised to learn that security, networking, monitoring and storage might be some of them. Juniper’s engineering efforts are aimed squarely on these areas.
Stay tuned for our next blog and don’t be a stranger at KubeCon. In the meantime, find out more about Juniper’s cloud-native solutions at juniper.net/cloud-native.
