Introduction to Microservices

Microservices are getting more and more attention nowadays. You can read about them on blogs, hear about them on conferences and take part in discussions about them on social media. Expectations are really, really huge. Software community is divided. Supporters are fascinated by microservices, but skeptics claim that it’s nothing new. However, both defenders and naysayers agree on one thing - Microservices Architecture pattern has many benefits. Microservices might be defined as architectural approach, which depends on decomposing applications into single-purposed services. In other words, they divide big monolithic application, which is often packed as a single archive, into much smaller and simpler apps. Each one of them does just one thing and thanks to that, it does it well. Every single application is built by full-stack team in order to eliminate potential misunderstanding between different teams. Microservices are much better for complex applications, which have grown over time, instead of simpler applications. Microservices and its concept is similar to SOA (Service-oriented Architecture) and that’s why it’s being called "SOA with DevOps", "SOA for hipsters" or "SOA 2.0".

Key Characteristics:

Single Responsibility Principle: Each service does just one thing, and does it well.
Explicitly Published Interface: An interface, published by producer service, is being used by consumer service.
Independent Deploy, Update, Replace, Scale: Each service might be deployed, updated, replaced and scaled independently from the other ones.
Lightweight Communication: Lightweight protocols are being used in communication between services, for example REST over HTTP, STOMP over WebSocket, etc.
Centralized Monitoring: it should be one of the most important components of your platform. Are you facing with cascading failures? Monitoring will help you. It’ll show you if encountered failure is occuring service wide or it’s connected to specific to a specific instance of service.

Benefits

Independent of scaling

Each microservice can scale independently - it might be X-axis (cloning with more CPU or memory) or Z-axis (sharding) scaling. On the other side, monolithic applications are very different, because they might have requirements, which must be deployed at the same time.

Independent upgrades and easy maintenance

Code is responsible for one function and because of that, it’s easier to understand and upgrade. IDEs load the smaller amounts of code in simpler way and developers can be more productive, thanks to increased readability. Developer can also implement changes to a service without coordination with other teams.

Potential diversity and variety of languages

There aren’t any restrictions about the language and the stack, so developers can choose them freely, by answering question: which ones will be the best for specific service? This allows them to rewrite the service using better practices instead of being limited due to past decisions. It gives them freedom to choose technology, tool and framework.

Improved communication between teams

It’s full-stack team, that builds a microservice. All of their members, related to a domain, work together in one team. As a result, communication between team members, significantly improves, because they share the same goal.

Drawbacks

Complexity

Microservices application is a distributed system, and developers need to both choose and implement communication mechanism. They also need to write code to handle partial failure, just in case of slow or unavailable request. It’s much more complex and difficult than in a monolithic application.

Partioned database structure

In monolithic application, you need to update only one database. As opposed to that, in microservices there are multiple databases owned by different services. Business transactions that are helpful with that are fairly common, but many of today’s NoSQL databases and messaging brokers don’t support them. You end up with necessity of using an eventual consistency based approach, which is a great challenge for developers.

Testing

It’s much more complex than testing monolithic application, which is simple by using Springe Book framework to test its REST API. In contrast, the similar test for a service requires launching that service and any services that it depends upon.

Implementing changes

If you want to implement changes to services A, B and C, where A depends upon B, and B depends upon C, it’s more complicated in microservice application than in monolithic application. What you need to do is to plan those changes careful. Fortunately, multi-service changes are relatively rare.

Deploying

A monolithic application is deployed in simple way on some identical servers. On the other hand, a microservice application is built with large number of services: Hailo has 160, Netflix has 600. Each service has multiple runtime instances, which means a lot of moving parts, that need to be configured, deployed, scaled and monitored. Because of that, if you want to successfully deploy microservice application, developers need to have greater control of deployment methods and a high level of automation.

Summary

It’s great challenge to build complex application, which works well. Using a monolithic architecture may not be the best idea, because it’s best for simple, lightweight applications. However, a microservice architecture it’s a solution you are looking for. It may be hard to overcome challenges related to it, but it’s worth its price.