Demystifying Microservices

By Ruth Gantly

It’s easy to see why microservices have become so popular.

Netflix’s shift to microservices has famously helped it to serve up its content to so many different devices. Companies such as Twitter and Airbnb have leveraged microservices to dramatically accelerate development. South American retailer Magazine Luiza’s adoption of microservices has helped it transform from a brick-and-mortar company with basic e-commerce capabilities to, as some analysts have put it, the “Amazon of Brazil.”* In an age when delivering great digital experiences is more important than ever, microservices have shown themselves to be an important part of the mix.

But microservices are also notoriously complicated — in no small part because it’s not always clear what microservices even are. Are they basically just an evolved version of service-oriented architectures (SOA)? Since a microservice must be exposed via an application programming interface (API) for an organization to scale it to new developers, does that mean managing microservices is basically the same as managing APIs?

As this article will discuss, the answer to both of these questions is a clear “no” — and companies looking to get the most from their microservices need to understand why.

What are microservices anyway?

Broadly, the term “microservices” refers to a software development methodology organized around granular business capabilities that can be recombined at scale for new apps. A microservice architecture, then, is a method of developing software applications more quickly by building them as collections of independent, small, modular services.

A primary benefit of this architecture is to empower decentralized governance that allows small, independent teams to innovate faster. Rather than working as a large team on a monolithic application, these small teams work on their own granular services, share those services with others via APIs so the services can be leveraged for more apps and digital experiences, and avoid disrupting the work of other developers or end user experiences because each microservice can be deployed independently.

Microservices can be deployed independently and easily moved across clouds because — unlike monolithic applications — microservices are deployed in containers that include all the business logic the service needs to run. Developers can use APIs to create applications composed of services from multiple clouds, and microservices in one cloud can interact via APIs with systems elsewhere.

In more specific terms, microservices are:

• fine-grained services that deliver a unique, single responsibility crucial to an overall business goal.
• independent and event-driven. They share nothing with other microservices and can be deployed or replaced without impacting other services.
• deployed separately but able to communicate with other services though a well-defined interface, generally RESTful APIs that expose the service for developer consumption.
• code components that are typically replaced wholesale, rather than versioned, and can be disposed of without affecting other components of the architecture.
• governed decentrally. Microservices architectures are generally incompatible with centralized legacy operational approaches that generally lock down IT assets and impose heavy governance. Microservices still requires some blanket governance practices — security concepts such as OAuth should apply to all APIs being used to consume microservices, for example. But it is important to let teams develop in the best way for them, with the best tools for their work and the autonomy to innovate.

How are businesses implementing microservices?

In many top businesses, the shift from a single development pipeline to multiple pipelines, and from waterfall development to automated continuous integration/continuous delivery (CI/CD) processes that facilitate rapid iteration, is already happening. Microservices are a major driver. Release cycles that were once long and arduous have now been reduced so that businesses can release daily or even multiple times in one day. Magazine Luiza, for example, leveraged microservices to accelerate from fewer than 10 deployments per month to more than 40 per day.

These changes emphasizes that microservices may not be useful when a company is merely trying to bolt technology onto its status quo business model. Rather, microservices are a way for businesses to use technology to change how they operate. If a company uses one large, slow-moving development team, microservices may not be much use until it has reorganized around dozens or even hundreds of small, fast-moving development teams. That transition doesn’t and typically won’t happen overnight —but microservices are built to empower small, independent teams, so a company may need at least skunkworks projects to get started.

In a blog post, T-Mobile CIO Cody Sanford describes this trend well:

“Gone are the highly-coupled applications, massive waterfall deliveries, broken and manual processes, and mounting technical debt. In their place are digital architecture standards, exposed APIs, hundreds of applications containerized and in the cloud, and a passionate agile workforce.”

If an organization is prepared to make the right organizational changes, microservices can accelerate multi-cloud strategies because the services can be scaled elastically, enabling more workloads to run in the cloud and across clouds. They can be deployed to create a more flexible architecture in which individual services can be released, scaled, and updated without impact to the rest of the system.

Monolithic applications contain all of the business logic, rules, authentication, authorization, and data tied together, which typically makes them much more difficult and time-intensive to update in even relatively modest ways. Microservices architecture, in contrast, support the separation of duties into individual self-contained entities that work together to deliver the full experience — instead of a team spending months or years creating tightly-coupled code for a single app, many teams create microservices daily or weekly that can be leveraged indefinitely in changing contexts.

How should I manage microservices?

For many businesses, the best way to manage microservices will be through a combination of a mesh network such as Istio and an API management platform. It’s important not to conflate these two things. The former handles service-to-service interactions, such as load balancing, service authentication, service discovery, routing, and policy enforcement. The latter provides the tools, control, and visibility to scale microservices via APIs to new developers and connect them via APIs to new systems.

More specifically, a service mesh can provide fine-grained visibility and insights into the microservices environment, control traffic, implement security, and enforce policies for all services within the mesh. The advantage is that it all happens without making changes to application code.

API management, meanwhile, provides for easy developer consumption of microservices. Organizations need APIs so that teams can share microservices and interact with other systems. These APIs should not be designed for simple exposure but rather as products designed and managed to empower developers. An API management platform should provide mechanisms to onboard and manage developers, create an API catalog and documentation, generate API usage reporting, productize or monetize APIs, and enforce throttling, caching, and other security and reliability precautions.

Consequently, microservices are distinct but deeply connected to APIs. Both APIs and microservices are also distinct from legacy SOA techniques in several crucial ways, including that microservices thrive in more decentralized environments with more autonomous teams and that the emphasis is not just on reusing digital assets but also making them easy to consume so that developers can leverage them in new ways.

Microservices: only one piece of the digital transformation puzzle

The benefits of microservices don’t typically emerge until a business needs to scale a service, both in terms of the number of requests it needs to handle and the number of developers who need to work with it. Additionally, while companies may break some existing systems into microservices or use microservices for current development goals, many older systems, such as enterprise service bus (ESB) or mainframe systems, will remain part of an enterprise’s overall topology. These heterogeneous systems typically communicate with one another via APIs, emphasizing again that though APIs are central to microservices, what can be done with a microservice and what can be done with an API are not the same.

Microservices will remain challenging as organizations continue to implement them — but with the right understanding of how microservices fit alongside other technologies and should be managed, this complexity may be more conquerable than it appears!

*Magazine Luiza is a Google Cloud customer and user of Apigee’s API management platform.

[Looking for more insights about microservices? Read our free eBook, Maximizing Microservices.]