General Information About Microservices

What can you find in this article?

This article covers general information about micro services like:

What is the definition of microservices?

As name stated, a micro service is a small service. It has one, well defined purpose. Actually size does not matter that much in this context. A micro service may be for calculating a report so it has a single responsibility, but it is big. That’s why it’s better not to think about its size, but its responsibilities.

Another key thing in definition is its role in a system. When you have micro services, they work together and produce results. To the great extension each of the micro services is independent of each other.

A micro service, is a service, designed for one purpose. It produces desired results working with other services.

When to use microservices?

Firstly let’s assume that you have a monolith system. You have set up good a foundation in the main service. The monolith grow into a significant size, and its maintainability started to become challenging. To improve maintainability, it’s better to split the monolith into small services.

In the next case, you may have again a monolith system. This time, you would like to add a new feature. To reduce cost of extending the big system, you create a new service and integrate it with the existing one.

The other case may be up front design for micro services. Let’s say that you have a customer who needs a system with lots of integrations. Also the system should be easy to extended with new ones. That is a good usage for micro services, as you define small services which handle each part of the system on their own.

Another great usage is for grouping coworkers into teams working on separate services. This way you may have people across the globe. You group them together in teams by a country. Then each team handles just their own services.

What are the advantages of microservices?

A great advantage of a micro service architecture is that it allows to make independent changes to the system. This option enables you to be more flexible and responsive to your customer’s requirements.

It allows you to scale each part of the system separately. Thus you are free to focus your attention on just one service, e.g. the one which slows the system down, and scale the service to get what you need. What is more, when you add an auto scaling option for a micro service, you can handle scaling automatically.

One of the key things for bigger customers in particular, is the time needed to release features. By using micro services, you are very often able to release new features faster. You just need to modify independent services, rather than the entire system.

The micro service pattern enables you to aggregate certain services into groups. For instance, a Virtual Private Cloud (VPC) or an Availability Zone in AWS. When you work with a monolithic system, each part of the system is in one place - in one VPC. A monolithic system does not give you as much flexibility as you have with a microservices-based solution.

Another great advantage that comes with microservices is the possibility to use a number of different technologies for different services operating within one system. It is, for example, useful when you developed a system using one main technology, e.g. Python, and later you need to migrate the system into Scala or Haskell for better performance / speed. In a monolithic system it is impossible. You need to migrate the entire system into a new technology.

Another benefit is that you can focus on just one service which requires enhancements. Firstly, it is easier to check the performance of the system by examining its different services rather than trying to analyse a monolithic system in its entirety. Secondly, you move on to improve just the slowest service(s). A similar approach can be adopted for dealing with security issues. You may find that a given service needs improvements in terms of security, e.g. it calls for a new data encryption method. It is easier to do so in one relevant service rather than handle a similar issue in a big monolithic system.

Last but not least, you can deploy separate teams to work on specific services. While working on a monolithic system, with more dependencies, it may be harder to split the work in a clear and straightforward fashion. It is particularly useful when you work with collaborators from different geographic locations.

What are the disadvantages of microservices?

The first drawback is connected with a somewhat limiting architecture design. For instance, due to weak encapsulation you may face a lot of issues while extending the system. Though repairing such a design is possible, it is also challenging and fairly expensive.

At the beginning of the project customers may not be able to see some very tangible value, despite significant effort invested in developing the microservices-based architecture. It is especially noticeable when you work with start-ups. They very often attempt to create systems speedily, which may be rather hard to achieve with microservices as opposed to monolithic architectures.

Another challenge is testing. When you create a number of micro services, you will find it challenging to test them properly. If you want to ensure solid test coverage it may be more expensive.

The use of services facilitates the application of different technologies on the same project. This is a great advantage for some contexts but it is also a double-edged sword. When you have too many options to choose from, you are more likely to select an option which has not been designed for solving a given problem or introduce unnecessary complexity into the system built.

It might also be hard to change anything within such a complex system, especially when you deliver service to a corporate client. Changes in such situations require approval by many levels of staff. It leads to time consuming bureaucracy.

There is also a challenge associated with the hierarchy of services; if there is an issue at an upper-level service, you may find it hard to trace its root cause if the issue is visible at the lower-level services. To handle the challenge one needs to ensure a good overview of information flows across all services levels. Otherwise you will end up with issues which are hard to trace and debug.

Last but not least, you need to remember about deployment automation. If you do not automate deployment processes or testing, you will end up with a lot of manual and error-prone work to do. There is for sure an upfront investment to make to set it up at the beginning and it will only pay off only later in the process.

Back