Microservices, Containers, and the Shift to Cloud‑Native Architectures

The concept of microservices is fueled by the need to develop apps faster, be more resilient and offer a great experience for the customer. It’s a concept equated with scaled‑out, automated systems that run software on simple, commodity infrastructure. It’s the economic efficiencies that containers provide that will make microservices such a major theme in 2016.

The need for fast application development affects the entire organization and how it views the way its business has historically been organized. The new practices that come with microservices means the need for small teams that work iteratively in a manner that is unfamiliar to companies that work in a top‑down fashion. This means sweeping changes to how businesses function.

Now we have the container ecosystem emerging as a core theme for a new thinking about application architectures and microservices.

There are some basic tenets to consider about microservices, noted Battery Ventures Technology Fellow Adrian Cockcroft. First, it’s now less expensive to build software, and containers have made it even more affordable. Docker is on everyone’s roadmap — from software vendors to end users, all trying to figure out how to use containers — because they can accelerate software delivery. But it also means that the systems need to be instrumented at the application level, which means different requirements for developing, deploying and managing applications.

Adrian Cockcroft’s microservices talk at OOP Software Architectures conference, as rendered into cartoon form by Remarker.

For example, monitoring is more critical than ever for companies dealing with a growing scope of services and stacks. To solve problems, companies have to analyze the data logs — logs that are likely stretched across potentially ephemeral nodes and across multiple services. This need to have granular monitoring and better tooling helps practitioners better grasp how these building blocks are affecting the potential dozens of microservices that the application depends upon.

So what works? It starts with the organization and the API: A microservices‑based product team and a separate backend‑based platform team with an API between them, where the API calls are made and the infrastructure responds consistently and accordingly.

Microservices is defined as a loosely‑coupled, service‑oriented architecture with bounded context. It allows updates without needing to understand how everything else works. Services are built across organizations, and ownership stays in one place. Microservices architecture serves more as point‑to‑point calls between systems. You must have flexible message formats; irrespective of the versions, everything still works. That means when building a microservices architecture, you need some tooling to configure, discover, route traffic and observe and build systems.

IBM’s Andrew Hately, distinguished engineer and chief technology officer for IBM Cloud Labs, notes that fifteen years ago people might check their bank balance once a week; the Internet made it possible to check more often, and smartphones accelerated it to instant access. This speed forces businesses to develop services at the scale of social networks and search companies.

Businesses must handle constant interaction between employees, customers, systems, and all possible combinations, fully connected and always available. Without rapid experimentation and fast feature delivery, revenues suffer and companies become irrelevant.

“Instrumentation is critical,” Hately said.

Code is not supported over hundreds of sites, Hately said. Feedback loops let consumers drive the next set of test cases. This rigorous process provides a way to work as a company and to think about microservices; the ops side of DevOps defines metrics for small code pieces to micro‑segment success and failure.

Building on feedback, IBM created the IBM Bluemix Garage Method, combining agile, DevOps, lean, and other iterative practices to deliver reliable, testable, cloud‑deployed solutions with governance‑compliant monitoring, enabling individuals, teams, and organizations to improve their DevOps skills.

Contracts Around Software

The first generation of container management platforms are supporting these accelerated development processes.

In Docker Compose, the tooling is facilitated by microservices, said Scott Johnston, senior vice president of product at Docker, Inc. The YAML file acts as a manifest to describe the different components. Compose allows developers to describe multi‑container apps in an abstract fashion. It can describe the web container, database container, load balancer and the logical connections between them. It does not require networking or storage implementation.

Microservices are a contract around software, said Engine Yard’s Matt Butcher. Some argue they are SOA done correctly. Developers seek usefulness, feature richness and elegance, returning software development to its Unix roots of doing one thing very well. Microservices are contractual in how they perform a single function well and interact with the environment, similar to a good Unix shell script.

For example, the Kubernetes manifest file format serves as a contract. The manifest provides details about resources, volumes, storage, etc., giving developers and operations professionals clear expectations. It avoids the medieval “throw the code over the wall” relationship.

“Application developers have a hard enough life as it is,” Butcher said. “And then there’s the quintessential problem, that I call ‘throwing it over the wall,’ where you have the DevOps people … and the developers … the handoff often becomes throwing something over the wall.”

When developers build containers, there’s assurance that they will run similarly in production as in development, alleviating many DevOps headaches. Products like Helm can formalize this relationship further, presenting a contract that “blows right through” the wall rather than being thrown.

Development in the Time of Microservices

Software development is iterative and requires continual feedback loops. Tools such as the IBM Bluemix Garage Method support this, but most organizations still operate with top‑down plans unlike the iterative developer workflow.

“I don’t know what to call this but the real world and software world impedance mismatch,” said Pivotal Principal Technologist Michael Coté. He argues that understanding software development prevents trying to model everything as one giant machine; following software development principles lets organizations stay flexible rather than rigidly attached to a single plan.

There is no single way to do microservices, Coté said. They provide runtime and architectural resiliency, allowing simple principles to build complex systems; the simpler the concepts, the greater the possible complexity.

When complexity shifts elsewhere, platforms like Pivotal manage it, removing choices around networking and operating systems so customers can focus on differentiating their offerings at the top of the stack.

“We’re seeing another renaissance moment in the technology industry,” said Hately.

Likewise, the IBM Bluemix Garage Method abstracts complexity away from developers, making them more efficient and enjoyable in their work, driving significant technical and cultural changes across enterprises.

Docker, IBM, Joyent and VMware are sponsors of The New Stack.

Feature image: Close‑up of Remarker’s cartoon of Adrian Cockcroft’s talk.