Taming the Complexity Monster in a Cloud Native World
Twistlock sponsored this post. Want to learn more about building, shipping, and securing cloud native applications? Register today for the free Cloud Native Live virtual conference on Jan. 29.
Cloud native is not simple, at least in comparison to traditional on-premise deployments. When you enter the world of cloud native applications, you are confronted with a shifting, almost entirely virtualized infrastructure — and an application architecture consisting of swarms of ephemeral, free-floating microservices, individually wrapped in thin containers made from yet another layer of virtualized infrastructure. Even the most basic strategies for managing monolithic, hardware-based applications appear at first glance to be utterly irrelevant to the cloud native world.
What does all of that complexity actually amount to, though, and what can you do to manage it? In this post, we’ll look at the underlying nature of the new complexity, and at strategies for both managing and monitoring today’s cloud native applications.
Cloud Infrastructure Is Soft Infrastructure
One of the first and most obvious differences between traditional, hardware-based deployment and cloud deployment is the nature of the infrastructure. On a local server, the operating system sits on top of bare metal, and the IT team generally has to deal with both layers.
When you deploy an application in the cloud, the underlying hardware is generally irrelevant (with the exception of some specialized, hardware-based services, such as GPU-based processing and backup storage). Actual access to it is hidden from you, not just by one layer of abstraction (e.g., the operating system) but by several. The cloud service provider’s IT staff is the only party that has access to the underlying cloud server hardware or to most of the layers of abstraction that sit between that hardware and the visible elements of the cloud.
Trading Infrastructure for Services
The cloud infrastructure that you see as a cloud-service client is a generally rich and complex ecosystem of platforms and services designed to support a variety of uses. These uses range from Infrastructure as a Service (IaaS), through Platform as a Service (PaaS), to Software as a Service (SaaS). In other words, all of the cloud infrastructure that is available to you is soft infrastructure.
If you are coming from the world of on-premises deployment, cloud infrastructure may not even look like infrastructure — and in many ways, this is true. It may be more useful, in fact, to think of the cloud not as infrastructure, but as an abstract location which includes a set of available services, or packages of services. While it is true that the abstract location and the services sit on top of actual infrastructure, you don’t have access to that infrastructure, so it is not part of your sphere of responsibility as an IT practitioner. You are there to make the most effective use possible of the services and resources that are available — simply understanding that fact helps to reduce the complexity of dealing with the cloud.
Redefining Applications: Microservices
The architecture of cloud native applications bears very little resemblance to that of typical monolithic desktop or server-based applications. Cloud native applications are generally broken down into microservices. They run from within separate containers, and typically communicate via APIs. It may make equal sense to look at such an application as a set of small, coordinated applications, each serving a specific purpose, or as a single, large application made up of loosely connected and separately packaged components.
In either case, however, the underlying architecture is likely to be based on one or more of a handful of basic plans — typically, decomposition into functionally defined microservices (read from database, get user input, etc.), or microservices grouped together as part of larger functional units (database access, processing forms, etc.). While microservice-based architecture may look like a haphazard collection of scattered units at first glance, it is important to understand that in a microservice-based application, both microservices and groups of services are likely to be more clearly defined and organized than they would be in the equivalent monolithic application.
Redefining Applications: Virtual Infrastructure
It is equally important to realize that a cloud native application is more than just a collection of microservices. The containers serving as a relatively thin wrapping around the microservice code are soft infrastructure but are as much a part of the application as the code itself. They typically include a subset of operating system services required by the microservice, as well as those needed to interact with external orchestration and monitoring systems.
There is, in effect, no clear boundary between application and infrastructure, and since the infrastructure including the container OS is virtualized, it makes sense to see the container-related elements of the infrastructure as part of the application. A container isn’t simply a place to put your microservice code — it is a fundamental part of the code itself.
Where Complexity Gets Real: Orchestration and Discovery
How do containers even find each other? How do you coordinate them? How do you manage their interaction with the outside world? It is questions like these that get to the heart of cloud native complexity. If you are deploying thousands or tens of thousands of instances of a single container, you need to be able to put them to work, which, among other things, means connecting them with other parts of the application that need their services.
You need to have a means of orchestrating containers, of organizing and managing large groups of container instances and making them available for use — this is a job made more complex by the ephemeral nature of individual container instances. Cloud native applications also typically need to interact with external applications and services, within the same cloud environment and outside of it. These interactions need to be managed, both in order to locate the services and to provide the application with security from outside attack.
Managing Chaos
Without an effective means of orchestrating containers or managing interactions between microservices or with the outside world, the complexity of the cloud native environment is all too likely to become all-out chaos. With the appropriate tools, however, the complexity can not only be contained, but can also be reduced to a manageable set of interactions conducted along channels which can be clearly understood and monitored.
These tools come in two general types, although there is some overlap between the two sets of functions: orchestration tools and service meshes. Used together, they serve as the key to taming cloud native complexity.
Orchestration
The best-known and most widely used orchestration tool is Kubernetes. It groups container instances into units called pods, which it in turn groups into services. It handles requests for services and routes them to the appropriate pods and container images, handling tasks such as load-balancing and monitoring container activity and health as it does so. It is highly configurable, and serves as a tool not only for orchestration, but also for managing containers on a reasonably fine-grained level.
Service Meshes
Kubernetes sets up an infrastructure for managing containers and microservices. Service meshes, such as Linkerd and Istio, manage the flow of traffic between microservices and between the application and the outside world. A service mesh acts as a proxy, receiving requests for services and managing service discovery. Service meshes can also manage communication with external services, and handle tasks such as authentication and encryption. They are typically rule-based, and can be configured to meet the particular needs of your application.
Monitoring the Cloud
Once you have your orchestration and service management tools in place, the final step in taming the complexity of your cloud native applications is to monitor them for performance and security issues. Cloud service providers typically make a variety of basic monitoring tools and services available to their users; external monitoring services can provide additional tools, and coordinate monitoring data from a variety of sources using sophisticated analytics.
This kind of in-depth monitoring is particularly important when it comes to security. Given the complex nature of the cloud environment and the interaction involved in the day-to-day operation of a cloud native application, you need to monitor for security problems proactively and on a variety of fronts.
In this way, a service such as Twistlock is essential. It can combine firewalling, monitoring, vulnerability detection, and compliance management across multiple cloud platforms, and can integrate with cloud native security.
Cloud native complexity? It requires some understanding, and it does take some work, but yes, it can be managed.
Feature image via Pixabay.