An Introduction to Microservices

In computing and software, we hear about new cool technologies and trends almost every week.
In this series, we’ll go on a journey to explore the world of Microservices. We’ll learn about how they work, how they are structured and how they can be implemented.

Before Microservices: the Monolithic Software

By U.S. Geological Survey [Public domain], via Wikimedia Commons

To understand which issues and goals Microservices are addressing, it can be helpful to briefly see their counterpart, the Monolithic architecture, which is one of the most adopted way to build and mantain software.

The word “monolithic” is pretty self-explicative, and really gives the idea behind it: a single, connected and interdependent codebase from which a software is built. Monolithic architectures looks great in the beginning, because allow developers to get a  product off the ground in a very limited time. They are easy to understand. The codebase is the same, and developers can be highly productive from the beginning. Even the deployment of a monolithic product is easy and straightforward, most of the times involving just one setup that get the software installed.

But as the software grows, monolithic architectures tend to be cumbersome, hurting productivity and making difficult to make new changes or improvements to the product. Often developers have knowledge of only part of the monolith, and any big change in the product must be carefully coordinated, which slows down development. Adopting new technology, or facing new challenges, can mean rewrite the whole application.

Over time, monolithic software needs more developers to be maintained, and less time is spent on writing new features, causing it to become obsolete and unmarketable.

Furthermore, monolithic architectures don’t fit well for today’s market, where software must be able to work in the cloud, ready to scale, and easy to change and maintained.

To get rid of all those issues, considering a Microservices architecture might be more appropriate.

What are Microservices?

In a Microservices architecture,  all the application features are broken apart and made available on a set of indepedent services. Each one must be able to communicate with other services, and it must have its own deployment.
The cooperation between these small modules forms the whole application.

Advantages of Microservices

  1. In term of productivity, building and maintaining a single service is better because developers can focus on a smaller, easy to work with codebase. This makes faster adding new features to the product.
  2. Because each microservice has one single purpose, it’s easier to make it more solid. Furthermore, teams become more confident with their domains, and tend to reach a thorough knowledge of their service. At the same time, it’s easier for new team members to understand and change the code.
  3. Because microservices are independently deployed, they can be updated and provisioned without affecting the whole application. For example, we can restart the microservice responsible of the shopping cart, without affecting the microservice that lists the products.
  4. Because each Microservice can be developed with a different language, it’s up to the team choosing which language or technology to use. This improves biodiversity, especially in big group of people.
  5. Because Microservices architectures work well with containers technologies like Docker, it’s a breeze to pack a microservice oriented application with its dependencies into a container, then spawn it on the cloud.
    Moreover, containers allow an application to reach a desiderable level of isolation for its parts, making them high available and high resilient.

Tradeoffs of Microservices

Because designing Microservices is more complicated than Monoliths, we should be prepared to unexpected pitfalls.

  • A Microservices based architecture must be designed carefully and requires top quality expertise, which comes at great expenses.
  • The communication between many different services can be complicated and slow. Exchanging messages and data between services arises networking issues (security, bandwidth, errors management and replication, etc)
  • Everytime a microservice changes, the team shouldcommunicate the new behaviors to other teams, in order to avoid any   application break

The Bottom Line on Microservices

Today, Microservices are on the rise. They fit well modern software needs, especially cloud applications.
They win the battle with monoliths when it comes to scalability and maintainability over time, but with the cost of additional architectural complexity.

Monoliths are agile on the start, but tend to become cumbersome over time. For small projects, they are still a winning choice,
but when if you have to design a web application with scalability and easy maintenance in mind, then Microservices architecture will worth a thorough look.

Leave a Reply

Your email address will not be published. Required fields are marked *