6 overlooked facts of microservices

You could probably count on one hand the number of people in the world of enterprise IT who've not heard of microservices. One 2020 IT pro survey showed a staggering 96% had not only heard of microservices but claimed to be either 'very' or 'somewhat' familiar with them.

We shouldn't be too surprised at these statistics, given that microservices are widely considered to be one of the building blocks for a modern IT infrastructure. The Cloud Native Computing Foundation (CNCF) puts microservices in a list of technologies it says exemplify a cloud-native, and therefore modern, IT infrastructure. Also on that list are containers and Kubernetes, which recorded a strong, year-on-year jump in production environments, according to survey results. Microservices have crossed the Rubicon—no longer the tool of developers but something the business relies on too.

Plenty of organizations claim to be adopting microservices: 73% according to TechRepublic. A third of those in a separate O'Reilly survey reckoned they are in the process of moving to a microservices architecture, with half planning to implement the bulk of their systems as microservices.

But success with microservices is not so clear cut or universal, according to both O'Reilly and continuous-delivery godfather Dave Farley, who cautioned we should beware of the misperceptions that surround microservices. Farley, co-author of Continuous Delivery with Jez Humble, says some people are implementing what they think are microservices but, in fact, are not.

And that's a problem. Not only does it misrepresent microservices, but it means organizations are incurring extra costs and potential problems without benefiting from the value offered by true microservices.

It's all too easy to confuse the medium with the message on microservices, to conflate technologies that can be used to deliver microservices, such as containers. It is entirely possible to build microservices without using containers, but containers have become a popular way to build them. The wider awareness about containers may be one reason why so many architects claim to understand microservices. Others, according to Forrester's Randy Heffner, have been saying microservices when they really mean APIs.

At the other end of the scale are the definitions of microservices. Sam Newman, author of Building Microservices, describes microservices as "small, autonomous services that work together." Others describe microservices as a loosely-coupled, service-oriented architecture with bounded contexts.

So far, so simple... but maybe a little too simple? Such descriptions of microservices are handy introductions at the watercooler, but they don't provide much on implementation.

Treading the middle path is Farley, who's stripped things back to a level that should resonate with architects tasked with migrating their applications and infrastructure. Farley has listed six factors that tend to get overlooked or (in some cases) whose importance is overstated and that between them could damage your rollout.

1. Size

As the name suggests and as Newman affirms, microservices are indeed small. But what does "small" mean when re-architecting systems? It's received wisdom that if you are an enterprise, then microservices means breaking up your large, monolithic applications into smaller, discrete functions and technical services. However, that doesn't answer the "What is small?" question, inevitably followed by the "What's too big?" and "What's the right size?" There's no prescriptive answer, but Farley offers a rule of thumb: A microservice should have been architected to focus on doing one task, and doing it well. How long would it take to re-implement if you tore it down? A few days or weeks? If the idea of starting again scares you, then your microservice is too big.

2. Distributed

The focus on size obscures a bigger issue: Complexity. Microservices are a distributed architecture and, as such, must be able to communicate over a larger area—across data centers, servers, clusters, and meshes. They must run across networks of varying quality and across different hardware. This will inevitably mean challenges in terms of performance, availability, concurrence, latency, and reliability. Distributed, therefore, means building an architecture for an application or service that caters to the kinds of variables that can slow performance, reduce availability, and introduce latency. For example, it might mean building an architecture that relies on smaller volumes of data being transported during a transaction, that sees data cached locally, or that relies on stateless transactions. It might mean streamlining the number of service calls needed to complete a transaction. It could entail load balancing, especially if workloads fluctuate according to demand at given times of a day or during an event. On top of architecture comes the need for monitoring and management—using tools to ensure your application or service hits the required service levels and provides warnings when it doesn't.

3. Bounded context

Bounded context is an important point when trying to architect microservices. Breaking up monolithic applications into smaller sets of services will require communications between those services to operate in a federated way. This will breed increased network traffic and necessitate more detailed management. You can reduce communications and complexity by grouping services around a problem domain. This is an idea from Eric Evans, defined as "bounded context," in his book Domain Driven Design. In this approach, particular terms, definitions, and rules related to each other are applied consistently. Lack of consistency is an issue that can, and has, frustrated IT projects long before cloud. It can, for example, be a lack of consistency in project definitions or data in different systems that mean the same thing but are described differently and must be translated or required a schema registry. In the cloud, microservices that are aligned around a problem—within that bounded context—will mean fewer interfaces and chatty interactions.

4. Autonomy

Microservices should be architected to be autonomous, able to operate and be maintained without relying on other microservices. If they can operate independently of each other, they will neither be derailed by problems or performance issues in another microservice nor act as a point of failure. All this adds up to performance, scalability, and elasticity.

"It's [autonomy] the biggest value of microservices - this is the thing that allows microservices to work in organizations that scale enormously," says Farley, "but it's also the most commonly missed attribute of microservices. What I see frequently is teams claim they are implementing microservices but building, testing and deploying all those pieces together."

Rather like small, the idea of autonomous can be relative and difficult to architect. You can't eliminate coupling, but you can reduce it, and you can apply several tests to determine whether coupling has undermined your service's independence. Mintel chief architect Ben Morris lists those tests here. They include finding out whether you can make changes to a microservice without referencing another and ascertaining whether stopping one microservice would affect others.

5. Independently deployable

The biggest stumbling block of microservices is the inability to build services that are independently deployable. If you must test your service on others before it's released, or if you demand that others must update their services with yours, then your services have not been architected to be independent and, according to Farley, are not microservices.

This is not simply a technology architecture issue, though. The shape of the microservices you architect will be greatly influenced by how the teams building and maintaining the software that delivers your architecture are organized. Look at the architecture of your software and stakeholder teams—and decouple them. Farley is not alone in this thinking. His colleague Dr. Nicole Forsgren—co-author of Accelerate with Farley's fellow writer and thinker Jez Humble—says a loosely-coupled architecture and autonomous teams are the best way to ensure continuous delivery of an application or service.

What's the proof of a decoupled team? When they don't have to manage the dependencies of other teams or engage in lots of communications to make changes. This means they have greater freedom to build and deploy applications and services because they don't have to coordinate with others.

6. REST is not the only way

Representational State Transfer (REST) has become synonymous with microservices, much like containers have. RESTful APIs are used by microservices to communicate, so they operate as a single service and with client-side applications. REST is an accessible and low-maintenance technology because it lets microservices talk over HTTP without additional infrastructure. However, while REST is closely associated with microservices, it is simply one of several techniques. Microservices can also use RPC, gRPC, JSON, asynchronous messaging, and Function as a Service.

Build wisely

Microservices are a modernizing force for enterprise IT, helping to deliver the flexibility and resilience organizations need to respond to changes and grow at scale. It's possible, however, to conflate microservices with some of the technologies enabling them. It's also possible for a received wisdom—something passed on as a fact, but that isn't necessarily true—to take hold and shape our understanding of the characteristics that define microservices' architectures.

It's important for the success of microservices architectures—their rollout and long-term sustainability—to reacquaint ourselves with the six facts described in this piece.