What Service Providers are Learning from the Cloud? Part2
Part 2 – Microservices and Containers
When Service Providers (SPs) look to the future they see a tsunami bearing down that threatens to drown their traditional world. The over-the-top (OTT) delivery of cloud-based services has already diminished the SP role in many cases to being a pipe supplier and bit transporter. Cloud services are now also beginning to endanger SP’s value-added business, residential, and mobile services.
Microservices is an architectural style that structures an application as a collection of autonomous loosely-coupled services. Each microservice fulfills a well-defined business function and is responsible for its own data, so that it has no external dependencies. Microservices communicate with each other using well-defined stateless protocols like HTTP. They are a sharp departure from the previous mainstream enterprise Service-Oriented Architecture (SOA) that was used extensively by SPs.
For example, an SDN optical domain controller application might be composed of microservices for: a) parent optical domain control, b) vendor A equipment control, and c) vendor B equipment control.
Microservices enable a highly modular development and deployment environment, whereby each microservice can be individually upgraded, repaired, or replaced in an application without affecting other ones. This allows for “continuous delivery” of applications, which is a central benefit of the target DevOps environment. In the example of the SDN optical domain controller, new vendor equipment can be rolled out without the need for extensive integration and back testing with the parent controller. Release management is fluid and light weight.
Microservices also enable applications to scale effortlessly. If a particular microservice is a bottleneck, then it can be moved to more powerful hardware, or additional instances of the microservice can be spun-up. Microservices also make applications more robust. If an individual microservice fails, then the application carries on as best as it can with the remaining microservices. These attributes make it easier for SPs to meet Service Level Agreement commitments.
Each microservice pictured above is shown in a geared circle – or its container. It is useful to think of software containers as having similar functionality to shipping containers. A shipping container holds virtually any type of goods, and facilitates their transport in a common manner over multiple modes of transportation, like trucks, railways, and ships. A software container holds virtually any type of software code (and it is especially compatible with microservices) enabling the code to run transparently over multiple runtime environments, like development, testing, integration, and production. As such, containers are a central pillar in realizing DevOps. They make applications portable, facilitating seamless handoff of code both within and between development and operations organizations, speeding up the rollout of applications.
Software containers, like shipping containers, also enable dense packing on underlying resources. Applications can be broken up and distributed across fewer servers than is possible under an SOA, saving on capital costs.
A container essentially is a thin virtual machine layer that isolates the software code from the underlying operating system. It enables the containerized software to run identically, regardless of the environment. The most popular container standard is Docker, which has built up a large ecosystem and has widespread use. A colorful term you may have heard is Docker Swarm, which is a tool that lets administrators and developers manage a large number of Docker containers.
Stay tuned for the final blog in this series, where we complete the picture, and discuss how container-based microservice applications run on top of a Service Provider Platform-as-a-Service (PaaS).