Applications are traditionally built as a monolith. This usually means that any small change to the client-side user interface or the server-side application has to be rolled out as a new version. And when you’re scaling up, the entire application has to be scaled up, even if there’s higher demand only for some aspects of the application. This is where microservices come up.
Microservices are a variant of Service-Oriented Architecture. Here an application is built as multiple services. Each service has its own functionality and the different services communicate over a network. You could picture the individual services as different departments in an organisation. Each service has their own languages, databases, as well as hardware, just like how different departments in an organisation have their own way of doing things.
Origins of the microservices model
Origins of the microservices model can be traced back to 1999 in Dexter research project at Hewlett Packard Labs. They were trying to make large scale, complex software systems robust to change. In 2005, the term Micro Web services were introduced at the Web Services Edge Conference.
The underlying principles of the world wide web and Unix systems have had a role in the evolution of microservices architecture. For example, the very idea of services essentially follows the Unix philosophy of “Do one thing and do it well”. And Unix philosophy is about developing short modular code.
The term microservice was decided as the most appropriate word to describe a common architectural style a group of software architects were exploring and was first used in May 2011.
How is a microservice architecture implemented?
Individual services are developed around business capabilities in a microservice architecture. In a traditional monolithic architecture, there are three or so different components, and the development teams are divided to work on these components. There will be a team for the user interface, another for middleware, and another for a different component. The teams are all focused on that one aspect they are working.
In a microservice architecture, the teams are cross-functional, and instead of focusing on an individual monolith, the teams develop these individual services using their own languages and database technologies. And often, as seen in Amazon, microservice proponents follow the “You built it, you run it” principle; instead of the team building it handing it off to a maintenance team. To follow up with the “departments in an organisation” analogy, you can imagine each of these departments handling a service.
There’s also the question of how micro a microservice is. As you may have guessed after reading many articles about microservices, it doesn’t have a clear definition. The meaning of microservice has slowly evolved over the years.
Once again to use Amazon as an example, the teams are limited to 8-12 people. They call it a two-pizza team, as in a team you can feed with 2 pizzas. These teams are built around services. They have the authority to solve problems in service any way they see fit. But there are also situations in which a single team handles multiple services as well.
Advantages of microservices architecture
One of the key benefits is that these services can be deployed independently. The rest of them can function properly even if one of them has any issues. The services are loosely coupled and patches and updates can be deployed much more easily compared to a monolithic architecture.
Microservices architecture is also highly scalable. Amazon was able to solve their scale-up issues by shifting to microservices architecture with the services built around business capabilities. Monolithic architecture can also be scaled up but only to a certain extent.
Building services around business capabilities also make it easy to scale up based on demand. In a monolithic architecture, if there’s an increased demand for one out of three functions, the entire application has to be scaled up. But with a microservices architecture, only the specified service has to be scaled up.
The microservice architecture also brings a lot of flexibility into the development process. Depending on the specific use case, the best languages and the database technologies can be used. While monolithic applications can make use of different languages, it’s not very common. This can be compared to building a car. Consider the different components of an application to be like different components of a car. With a microservice architecture, you don’t have to use metal to build the entire car, you can use rubber for tyre, and leather for seats.
This flexibility also allows teams to solve problems in a way they see fit without a lot of constraints. Microservice architecture as a whole rethinks what comprise a team. In most implementations, the team that builds a service owns it and maintains it. The team has the authority to find the best solution to a problem and solve it with the best tools.
Disadvantages
The advantages of microservices may appear as disadvantages from another perspective. The fact that the microservice architecture is flexible also means there are a lot more languages and database systems to maintain. And instead of a single monolith, you now have to take care of multiple different services. In short, microservices architecture is more complex than a monolithic architecture.
Communication between services can be expensive, as it will result in a lot of remote calls. There’s higher network latency, with one service calling another, which in turn may call another ten. And these multiple calls introduce a lot of failure points.
Shifting to microservices also needs an organizational change. There is a change in team composition as well as the working culture.
Shifting to microservices comes with many benefits. But you have to plan it well and anticipate problems along the way.
