In my last Industry Insight, I discussed some of the benefits of using the cloud as an alternative model for consuming IT services. In this article, I will discuss microservices, containers and orchestration.
Functional cloud architectures enable continuous integration and continuous deployment with automated quality assurance.
Modern cloud architectures enable scalability, reliability and velocity at the same time. Containers and microservices change the game for software foundations.
As cloud development evolved, software architectures were built with considerably more flexibility and modularity, with loosely coupled services that are easier to monitor and scale independently.
Together with this new distributed and scalable design, new software tools were invented to manage the deployment, monitoring and dynamic change of the system.
These concepts are known as containers, microservices and orchestration. They are the software building blocks of the modern cloud.
Microservices
Microservices are a software design technique in which an application is broken down into small operating pieces with well-defined boundaries of functionality. The individual pieces (in other words, services) are woven together via application programming interfaces (APIs) in a loosely coupled environment.
Microservices are a little bit like a car. The car is the application. But the car (application) is made up of component parts (services) that provide some function. Each part is optimised for its own specific purpose.
Modern cloud architectures enable scalability, reliability and velocity at the same time.
Additionally, each part has a well-defined interface to the rest of the car, and in most cases, you can modify, upgrade, or replace parts in a modular fashion without tinkering with the rest of the vehicle.
Each part represents an isolated fault domain so that component issues and failures have a limited impact on the rest of the system. You can replace headlights or tyres without thinking about engines or the exhaust system. Or you can enhance the audio without worrying about the alternator.
Your car is analogous to a single unified application with many loosely coupled parts. In software, a microservices design does the same thing. By decoupling services into small manageable parts (those parts are usually containers), each service can be designed with a software stack that is ideal for its function.
Most traditional networking applications were built for on-premises fixed-footprint servers. So they are monolithic by design and bounded by scale constraints, by necessity. They are built as a single-tier program (called monolithic applications).
When you think of monolithic software, think of wired earbud headphones. When you lay them down on a table, they always get tangled up. When putting a pile of cords, cables and earbuds together, the tangle becomes such a mess that it is difficult to tease one part out from the other.
This is what happens with tightly-coupled monolithic architectures as they evolve over time. Another term for this is spaghetti code.
Microservices, on the other hand, are segmented out into their own contained functional blocks with well-defined interfaces. Microservices have linkage within the application to other services where necessary. Just as importantly, microservices do not interface where they are not needed.
They have emerged as the de facto software architecture for cloud-based applications that are dynamic and complex, with many functions and moving parts − like scalable networking systems.
Containers
Containers are lightweight, standalone executable software packages that include everything needed to run, including code, system tools, binaries, libraries, frameworks and settings. Docker is the open source standard platform for running containers.
Containers are simply a way to bundle together some code and all of its operating dependencies so that the entire package is all-inclusive. By packaging everything as a bundle, the software components become self-contained. Therefore, the software package can function reliably in any container environment, which makes it more predictable and easier to maintain and operate.
The problems that containers solve are not very obvious when you think about version 1.0 of an application. However, the interoperation matrix grows exponentially with added features, underlying software components and versioning, and dependencies.
For example, Feature-A needs Component-Y to be on Version-N; and Feature-B needs Component-Y to be on Version-Q, and so on. The end result is that quality assurance (QA) teams have issues keeping up with all the changes and dependencies. Containers, as a part of a microservices architecture, solve this complexity problem for both developers and QA.
Compared to other software design options, containers provide several benefits:
Lightweight: Containers reduce the resource footprint by running directly on the host’s kernel without requiring a guest OS, which takes up CPU, memory and disk.
Predictable: By packaging an application with all of its dependencies, containers are predictable and portable because they work the same way in any container environment.
Fast and scalable: In a production application with dynamic real-time requirements, containers start up very quickly and do not rely on an underlying virtual machine to boot. Once started, they can also be scaled up or down independently from other services in other containers.
Orchestration
A microservices architecture often comprises many containerised services to deliver the application. It is not uncommon to have over 30 different services, which could each be a single container, a collection of containers, or a distributed set of containers.
To control the dynamic deployment, operation and scaling of those containers, these architectures rely on an orchestration layer.
Orchestration solves the following operational challenges:
- Deploys containers and containerised applications.
- Monitors services for operation and automate actions (for example, restart a failed container, delete containers, replicate containers on new hosts).
- Scales container deployments as application load changes.
- Manages container updates.
In my next article, I will discuss what happens when putting all of these architecture concepts together.
Share