It's hard to describe microservice in a single sentence. In this article, we will let you know why and what are aspects of microservices that we love most about.
Microservices are independently deployable modules. Let's take Muse Zade's favourite domain ecommerce as an example and divide it into modules as follows:
Ordering items
Items Search
User/Product Registration
Normally, all of these modules would be implemented together in one application. In this case, a change in one of the modules can only be brought into production by bringing a new version of the entire application with all its modules into production. However, when the modules are implemented as microservices, the ordering process cannot only be changed independently of the other modules, but it can even be brought into production independently. This speeds up deployment and reduces the number of necessary tests since only a single module needs to be deployed. Due to this greater level of decoupling, a large project can turn into a number of smaller projects. Each project is in charge of an individual microservice.
To achieve this at the technical level, every microservice has to be an independent process. A better solution for decoupling microservices is to provide an independent virtual machine or Docker container for each microservice.
In that case, a deployment will replace the Docker container of an individual microservice with a new Docker container, which starts the new version and its direct requests. The other microservices will not be affected if such an approach is used.
Size of a microservice
First, the common confusion about microservices is that people think it's only is a smaller chunks of existing modules, which might not be true. Some microservices keep an entire team busy, while others comprise only a few hundred lines of code. The above definition of microservices does not say anything about the size of a microservice. Of course, the term microservice suggests that especially small services are meant. However, in practice, microservices can vary hugely in size.
Scaling the product
Muse Zade works with teams of other companies, but within our own tech stacks within the same projects, which has been possible only because of microservices architecture. Below are some of the features of microservices in product management across unrelated teams:
Each teams responsible for an individual microservice can make most technology decisions on their own
When the microservices are delivered as Docker containers, each Docker container only has to offer an interface for the other containers.
The internal structure of the containers does not matter as long as the interface is present and functions correctly. Therefore, it is irrelevant which programming language a microservice is written in. Consequently, the responsible team can make such decisions on their own. Of course, the selection of programming languages can be restricted in order to avoid increased complexity. However, even if the choice of the programming language in a project has been restricted, a team can still independently use an updated library with a bug fix for their microservice.
When a new feature only requires changes in one microservice, it can not only be developed independently, but it can also be brought into production on its own.
Working with Legacy Codes
Microservices help when working with legacy systems since the existing code does not necessarily have to be changed. Instead, new microservices can replace parts of the old system. No pre-existing codebase has to be used. In addition, developers can employ a completely different technology stack. This immensely facilitates work compared to having to modify the legacy code itself.
Challenges you might face
1. Deployment must be automatedMicroservice architectures can only work when the deployment is automated! Microservices substantially increase the number of deployable units compared to a deployment monolith. This is only feasible when the deployment processes are automated.
2. Difficult to replaceIt is difficult to replace a microservice, on which numerous other microservices depend since changes might affect the other microservices. Thus, to achieve replaceability, the dependencies between microservices have to be managed appropriately.
3. More tests and increased latencyDue to the split into microservices, there are more interfaces to test, and testing has to be independent for both sides of the interface.
Hence, the challenges are mostly associated with operation. Appropriate technological decisions should strengthen the intended benefits, and at the same time they should minimize disadvantages like the complexity in operation.
Of course, integration and communication between microservices is more complex than the calls between modules within a deployment monolith. The added technological complexity represents an additional important challenge for microservice architectures.
