Microservices - the modern alternative to monolithic architecture

What is microservices architecture?

First, let’s be clear what we’re talking about: what is a microservice and microservices architecture?

The clue is in the name: instead of designing a digital product or platform as a single, unified (and complex) block of functions and services, with a microservices approach to the architecture, each product is treated like a suite of individual (and interacting) services.

Each element in a microservice architecture is running its own processes, communicating with other services as needed (usually via an API, or with Message Queues). There is a minimum of built-in central management or ‘oversight’.

Each microservice runs independently and may even be written using a different programming language, or use a different data storage technology to the rest of the architecture. But why not just deal with everything together, in one big, monolithic package? The answer is that what may seem simpler on the surface becomes a problem when we look more deeply…

Microservices vs. monolithic architecture

To compare:

Monolithic architecture:

• A single unit.
• All functionality works via a single process; scaling is by replication of the whole on multiple servers.
• Scaling or updating a feature means dealing with the whole architecture.
• Same programming language and technologies used throughout.
• Maintenance and scaling tends to be managed by a single development team

Microservices architecture:

• A collection of individual, modular units.
• Each function is handled by a separate service; scaling is by replicating individual services on servers, as needed.
• Scaling or updating a specific microservice does not require scaling anything else.
• Option of using different languages and technologies for different services, depending on which are best-suited to the task.
• Option of different services being managed by different development teams.

Microservices architecture components and functions

At this point, you may be wondering where the coherence is in a microservice architecture, scattered across functions, technologies and servers as it is. That coherence is found in the five common components of all microservices architectures.

1. Microservices – Unsurprisingly, the first key feature of a microservice architecture is the self-contained microservices themselves. How ‘big’ is a microservice? That depends on the circumstances and requirements. The idea is to decouple services from each other and minimize any dependencies, using lightweight REST or HTTP APIs to communicate.
2. Containers – A container is a unit of software, packaging code and its dependencies in a single block, making it easier to develop, test and deploy in any environment, whether it’s a public cloud, a private data center, or a developer’s laptop. While not strictly necessary, containers are a common feature of microservices architecture, allowing scaling and deployment of packages without negatively impacting performance of the app or digital product. Container management tools, like Docker, help unify the setup of microservices and, used in tandem with Kubernetes, the pair allows scalable management of clusters of containers.
3. Service mesh – The service mesh is a layer in the architecture that enables communication between the different microservices.
4. Service discovery – Put simply, service discovery is about keeping track of the service instances active within the app or product’s architecture. As the deployment changes, service discovery tracks and distributes load between the various microservices. It includes a service provider (originating service instances), a service registry (storing the location of those instances), and a service consumer (using locations from the registry to communicate with service instances).
5. API gateway – Application Programming Interfaces define and facilitate communication between microservices and outside clients. Much of the communication, administration and security that is ‘baked into’ a monolithic architecture is handled by the API gateway, ensuring the microservices themselves remain as lightweight as possible.

Why use microservices architecture?

Having explored what microservices are, the key question becomes, when should you use them? Under what circumstances is a microservice architecture the best option?

1. Non-disruptive changes to functionality – If you need to make a change and deploy a function without affecting the rest of an app’s functionality, the microservices approach will allow you to do so without downtime. For businesses that need a constant uptime on their software, this can be particularly valuable.
2. Data partitioning – A microservice architecture offers greater isolation of components and therefore, potentially greater security. For health care and financial organizations dealing with PII (personally identifiable information) or PHI (protected health information) this is a valuable feature, allowing developers to dictate precisely which services have contact with such data.
3. Autonomous teams – For organizational structures the devolve authority and decision-making to a team level, a microservices approach allows different teams to be wholly responsible for different functions of an app or platform without increasing risk for the whole.

When not to use the microservices approach?

While we’re on the topic of ‘when’, it’s worth pointing out the circumstance when you might be better off not taking the microservices approach:

1. First, microservices development can be more expensive. It depends on what you’re building but creating a well-functioning microservices architecture can be complex, requiring a broad skillset and specific experience from the development team (or teams). Microservices is an elegant solution but not one to use if it’s not necessary.
2. Then there’s the complexity issue. Microservices should not be the default option. Especially if the domain is new, and unknown on both the business and development team sides. People often talk as if monolithic equals bad but it can still be a pragmatic and cost-effective solution. Maybe there’s no easy way to compartmentalize the services into neat divisions, or maybe your business goal just doesn’t need a microservices level of complexity.

Microservices architecture characteristics

Let’s dive just a little deeper into microservices by identifying some of the common characteristics that microservices architectures share:

• Using services as components – Monolithic structures will use libraries as a source of individual components (individually replaceable or upgradeable units of software). Microservices treat the independently deployable services as components.
• Team organization – The teams working on a monolithic architecture are often analogous to the parts of the architecture they’re responsible for: e.g. UI, middleware, and database. Microservices architecture is more likely to be organized by business function or feature, and the development teams tend to do likewise, meaning that each team is working on a complete service and is therefore cross-disciplinary, streamlining the development process.

This phenomenon is described by Conway’s Law:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

• A focus on the product – Another effect of the team organization described above is that the team is focused on the service as a complete product, including its longer term maintenance and upgrading. This focus ensures a closer link with the business goals of the app and the users it aims to serve.
• Decentralized governance and data management – When you’re not required to choose a single tech platform to handle your governance and data management, you’re free to choose a variety of best-fit options for different uses or functions.
• Automated infrastructure – While not obligatory, it’s common for microservices teams to use infrastructure automation, usually in the form of automated testing and automated deployment as part of a continuous delivery pipeline to minimize disruption for users when scaling or upgrading.

Benefits of microservices architecture

There are multiple benefits to adopting a microservices architecture. For the product itself, the approach is flexible and reliable, allowing for:

1. Improved scalability

As user traffic fluctuates (and hopefully grows!) over time, apps need to scale, increasing capacity and even adding new features to keep pace with the market and your product’s success. With a microservice architecture, individual elements can be scaled and tested without disrupting wider performance.

2. Flexibility

With services being separate units, with their own deployment cycles and requirements, you can diversify the performance, and costs, of the setups. If a microservice needs to process a lot of data but needs to be quick, you can set it up with additional computing power without changes to other services. The monolith, on the other hand, only performs as well as its slowest process.

3. Programming language and technology agnostic

As already mentioned, unlike a monolithic approach, microservices allow for designers and developers to choose the perfect framework, programming language, etc. for each individual element, meaning better and more focused performance.

4. Better security and fault isolation

Through the separation of microservices (potentially each service has its own database, for example) user data is less vulnerable to outside attacks or internal errors.

5. Great for enterprise applications

The smaller code bases of individual microservices are easier to manage, update, and troubleshoot, making them an easier and simpler option for enterprise-level apps.

Benefits of microservices for business

Microservices may be good for enterprise-level apps but they’re also good for the enterprise. Not least because the benefit of isolated services and undisrupted operation extends to the organization itself. Furthermore, a microservices approach can benefit the business.

1. Service-specific development teams

With the option of having individual teams working on specific services, covering all the elements of maintenance, upgrading and development, each service benefits from its dedicated, and holistic, attention. Teams are committed to their microservices longer term, instead of performing a task, handing it off, and moving on to the next.

2. Business agility

The microservices approach is compatible with an Agile culture. The focus on all aspects of the individual service, the rapid iterations and improvements, the rapid, cost-effective delivery of improved services to the market… the microservices approach is a good match for teams that apply agile development; and for those that don’t, it encourages them to do so.

3. Cost efficiency

The flexibility of microservices development (especially the capacity to choose the best practice tools for each specific job) also means the option to make the most cost-effective choices for each task.

Are microservices the future?

It would certainly seem so. Right from the early days of microservices, there was significant adoption (including big names such as Netflix, eBay, Twitter and PayPal) and this approach to architecture, isolating individual units and providing more dedicated development, is becoming well-established. Unsurprisingly so, given the clear benefits that adopters are reaping. After all, in a 2020 O’Reilly survey, 92% of respondents reported a level of success when using microservices architecture.