Select Page

Microservices are independently deployable modules. For example, an e-commerce system can be divided into modules for:



Product search

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.

 Introduction To MicroServices


Advantages of this microservice definition

The definition of microservices as independently deployable modules has several advantages:

For Free, Demo classes Call: 8237077325
Registration Link: Click Here!

  • It is very compact.
      • It is very general and covers all kinds of systems which are commonly denoted as microservices.
      • The definition is based on modules and is thus a well-understood concept.
      • This allows us to adopt many ideas concerning modularization.
      • This definition also highlights that microservices are part of a larger system and cannot function entirely on their own. Microservices have to be integrated with other microservices.
      • The independent deployment is a feature that creates numerous advantages and is therefore very important. Thus, the definition, in spite of its brevity, explains what the most essential feature of a microservice really is.

Deployment monolith

A system that is not made up of microservices can only be deployed in its entirety. Therefore, it is called a deployment monolith. Of course, a deployment monolith can be divided into modules. The term deployment monolith does not make a statement about the internal structure of the system.

For Free, Demo classes Call: 8237077325
Registration Link: Click Here!

Size of a microservice

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. Some microservices keep an entire team busy, while others comprise only a few hundred lines of code. Thus, the size of microservices is ill-suited to be part of the definition.

Microservices for scaling development

One reason for the use of microservices is the easy scalability of development. Large teams often have to work together on complex projects. With the help of microservices, the projects can be divided into smaller units that can work independently of each other. For example, the 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. This allows the teams to work on features completely independently. Thus, with the help of microservices, teams can act independently regarding domain logic and technology. This minimizes the coordination effort required for large projects.

Replacing legacy systems

The maintenance of a legacy system is frequently a challenge since: The code is often badly structured.

  1. The changes are not checked by tests.
  2. Developers might have to deal with outdated technologies.

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. This requires integration between the old system and the new microservices, for example, via data replication, REST, messaging, or at the level of UI. Besides, problems such as a uniform single sign-on for the old system and the new microservices have to be solved. But then the microservices are very much like a greenfield project. 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.

For Free, Demo classes Call: 8237077325
Registration Link: Click Here!

Sustainable development

Microservice-based architectures promise that systems remain maintainable even in the long run.

Replaceability of microservices

  • An important reason for this is the replaceability of microservices. When a microservice can no longer be maintained, it can be rewritten. Compared to changing a deployment monolith, this entails less effort because the microservices are much smaller.
  • However, it 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.
  • Replaceability is a great strength of microservices. Many developers work on the question of how to replace this system after it has turned into a legacy system is rarely asked. Microservices with their replaceability provide an answer.
  • Hence, individual microservices remain maintainable. If the code of a microservice is unmaintainable, it can just be replaced and it would not influence any of the other microservices.

Dependencies have to be managed

To achieve maintainability, the dependencies between the microservices have to be managed in the long term.

In Classical Architectures

      • Classical architectures often have difficulties at this level. A developer writes new code and unintentionally introduces a new dependency between two modules, which had been forbidden in the architecture.
      • Typically, the mistake goes unnoticed because attention is only paid to the code level of the system and not to the architectural level. Often, it is not immediately clear which module a class belongs to. So it is also unclear to which module the developer just introduced a dependency.
      • In this manner, more and more dependencies are introduced over time. The originally designed architecture becomes more violated, culminating in a completely unstructured system.

In the microservices architecture:

      • Microservices have clear boundaries due to their interface irrespective of whether the interface is implemented as a REST interface or via messaging.
      • When a developer introduces a new dependency on such an interface, they will notice this because the interface has to be called appropriately. For this reason, it is unlikely that architecture violations will occur at the level of dependencies between microservices.
      • The interfaces between microservices are in a way architecture   firewalls since they prevent architecture violations
      • The architecture at the level of dependencies between microservices also remains maintainable. Developers cannot unintentionally add dependencies between microservices. Therefore, microservices can ensure a high architecture quality in the long term both inside each microservice and between the microservices.                    
      • Thus, microservices enable sustainable development where the speed of change does not decline over time.
  • Increased operations effort: –

  • For Free, Demo classes Call: 8237077325
    Registration Link: Click Here!

Running a microservices requires more effect than a monolithic architecture. This is due to the fact that in a microservice system, many more deployable units exist that all have to be deployed and monitored. This is feasible only when the operation is largely automated and the correct functioning of the microservices is guaranteed via appropriate monitoring

  • Must Be Independently Deployable

Microservices have to be independently deployable. For example, dividing them, into Docker containers is a prerequisite for this, but it is not enough on its own. Changes to interfaces must be implemented in such a way that an independent deployment of individual microservices is still possible.

  • Testing must be independent 

Also, testing must be independent. When all microservices have to be tested together, one microservice can block the test stage and prevent the deployment of the other microservices making testing much harder.

  • Difficult to change multiple microservices 

       We need to maintain several changes that affect multiple microservices than the changes that concern several modules of a deployment monolith. In a microservice system, such changes require several deployments. These deployments must be coordinated. In the case of a deployment monolith, only one deployment would be necessary.

  • Lost overview 

In a microservice system, the overview of the microservices can get lost. However, experience teaches that in practice, a sound domain-based division can restrict changes to one or a few microservices. Therefore, the overview of the system is less important because the interaction between the microservices hardly influences development due to the high degree of independence.

  • Increased latency and failures 

For Free, Demo classes Call: 8237077325
Registration Link: Click Here!

Microservices communicate through the network. Compared to local communication, The latency is much higher. It is also more likely that communication will fail. A microservices system cannot rely on the availability of other microservices. This makes the systems more complex. 



Pallavi Kadam

Call the Trainer and Book your free demo class now!!!

call icon

© Copyright 2019 | Sevenmentor Pvt Ltd.

 SevenMentor Pvt Ltd

Pin It on Pinterest

× How can I help you?