Interest in microservices has been growing since 2014. Can microservices do more harm than good? In this post I will try to look critically at the topic of microservices and answer the question posed above.

In most cases, software developers prefer small and light projects, so the idea of microservices as a number of small projects seems like it could be a hit. Here one should answer the question of how big the microservice can be if we think of it as a small project. We can find many absurd metrics describing the size of microservices on the Internet. Some think that a microservice should contain no more than one thousand lines; others think that a team who creates microservices should consume no more than three pizzas; still others think that it should be possible to rewrite a microservice in one typical scrum sprint, so about two weeks. Personally, I think that a microservice should be as large as necessary and as small as possible. Of course, size is just one of the characteristics of microservices. A microservice should be connected with a culture of automation, hide details related to internal implementation, be deployed independently, isolate failure and be modeled around business concepts.

Looking at the above features, one can come to the conclusion that microservices are much better when compared to traditional monolithic architecture. What developers want, i.e. the development of small projects and the ease of implementation and delivery, suits the above features. The business team should also be satisfied because, as part of an architecture based on microservices, it receives an application which is scalable and, most importantly, resistant to failures. Unfortunately, that’s where the theory ends, because practical experience reveals many problems and threats associated with an application based on microservices.

Microservices – why not?

It cannot be denied that the dynamic development of microservices was made possible due to the DevOps (development and operations) method of software development. This is due to the fact that each service requires the separate management of logs, implementation or other administrative operations. In the case of one or even several monolithic applications, it is no problem for one person to take care of it. Unfortunately, the workload usually grows linearly along with subsequent applications, which means that a staff of administrators would be required for several dozen or even several hundred microservices were it not for DevOps, and in particular automation in the broadly understood sense. This way we have defined the first requirement that is necessary, but unfortunately not sufficient in itself, to start a project based on micro-services, meaning the preparation of an appropriate environment for our application, automated to the greatest possible degree.

Read more about Project Delivery model. 

Network communication problems

In the age of the availability and popularity of cloud computing, too many developers forget about network communication and the problems it can create. Two applications which communicate with each other do not do so in a faultless, let alone magical, way. Such incorrect assumptions have been defined and described by L Peter Deutsch as “fallacies of distributed computing”:

  • The network is reliable.
  • Latency is zero.
  • Bandwidth is infinite.
  • The network is secure.
  • Topology does not change.
  • There is one administrator.
  • The cost of transport is zero.
  • The network is homogeneous.

If the abovementioned erroneous assumptions about the network are not taken into account and the distributed application is not prepared on that basis, then it is likely that any problems in communication between microservices will arise faster than we may have expected.

Data consistency

Another challenge is related to data consistency. In a system dispersed in accordance with the CAP created by Eric Brewer, it is impossible to achieve consistency, accessibility and partition tolerance simultaneously. We can assume that total partitioning, meaning the failure of part of the system, is rare; however, we could look at a delay, and the latency, of the update between nodes as a temporary partitioning. In this situation the choice is between consistency and availability. In practice, most people prefer availability to consistency; it is also possible to bet on consistency but with no guarantees that the system will be available 100% of the time.

As I wrote at the beginning of this post, each microservice should be associated with a single responsibility, i.e. be closely related to a specific domain based on the bounded context. Newly created systems have related requirements which change frequently in the initial phase of their creation, which may involve blurring the border between microservices through the migration of mutual responsibilities. The result is that the system consists of many microservices, each responsible for everything. Of course, this does not have much in common with the microservice application. This is nothing more than a distributed monolith.

Microservices are also a different work culture than the one that often prevails when working on a large monolithic application. Instead of one large team, we should have many small ones, with testers, developers, etc. being responsible for each microservice. The advantage of this approach is having clearly defined responsibilities for each domain, i.e. microservices.

Microservice project in practice: “Insurance Company under the Digital Transformation – Case Study” 

Microservices – when?

To sum up, the purpose of this post is not to convince the reader that microservices are good or bad, but to realize which problems are created, and understand that the transition from monolithic to microservice architecture does not solve problems, but only shifts them around. If we approach microservices in a responsible and thoughtful way, they can prove to be a good choice. Microservices are also worth considering in the case of new projects, starting with monolithic architecture and switching to a microservice after the initial stage of development, in cases where the main requirements will not change too often and the boundary between domains will not be moved regularly. It is also easier to separate domains and define bounded context in a monolith, that is, something that already exists, than to share something that is not there yet.

Author:
Java Developer

Java programmer at JCommerce. His daily responsibilities focus on minimalism and pure code, using the latest technologies. Tolerates JavaScript, loves trips to the mountains and electronics, and sometimes builds something out of nothing. A lover of data analysis.

Comment

CONTACT US!

Would you like to learn more about the possibilities of cooperation? Do you have a question? Write to us!

    I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for commercial purposes.
    I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for marketing purposes.
    I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for recruitment purposes.
    I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for future recruitment purposes.
    I have been informed by JCommerce Sp. z o.o., 3 Ks. Piotra Sciegiennego St. 40-114 Katowice – the personal data controller – that: - The provision of the aforementioned personal data is voluntary but essential for commercial purposes if I have chosen a request for proposal, or recruitment purposes, if I have chosen the remaining options;
    - I have the right to access the content of my data, including to receive copies of it and correct it, delete it and limit the processing of it, as well as the right to transfer it, the right to object to the processing of it, and the right to withdraw my consent at any time. However, the withdrawal of my consent shall not affect the lawfulness of processing carried out on the basis of the consent in question prior to its withdrawal;
    - A statement of withdrawal of my consent to the processing of personal data should be submitted to the headquarters of JCommerce Sp. z o.o. or sent to the following e-mail address: zgody@jcommerce.pl. The withdrawal of consent to the processing of personal data shall result in the inability to fulfil the aforementioned processing purposes;
    - The personal data provided shall be shared by JCommerce Sp. z o.o. with the company’s authorised employees and individuals collaborating with JC under civil-law contracts, who are involved in the implementation of the purpose of the processing;
    - The data provided shall be processed on the basis of the relevant provisions of Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), ‘GDPR’;
    - Should you have any questions regarding the protection of your personal data, please contact us by e-mail: odo@jcommerce.pl;
    - The personal data provided shall be processed for the purpose for which it was supplied, or until I express my objection in this regard. In the event of filing an objection, JCommerce Sp. z o.o. shall no longer process my personal data for the aforementioned purposes, unless it can demonstrate that there are valid and legally justified grounds overriding my interests, rights and freedoms or my data is necessary to establish, pursue or defend a claim, if any;
    - I have the right to file a complaint to the supervisory authority if I consider that the processing of the aforementioned personal data violates the provisions of the General Data Protection Regulation of 27 April 2016.
    I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for commercial purposes.
    I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for marketing purposes.
    I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for recruitment purposes.
    I hereby agree that JCommerce Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as my name, surname, e-mail address, telephone number and company name, for future recruitment purposes.
    I have been informed by JCommerce Sp. z o.o., 3 Ks. Piotra Sciegiennego St. 40-114 Katowice – the personal data controller – that: - The provision of the aforementioned personal data is voluntary but essential for commercial purposes if I have chosen a request for proposal, or recruitment purposes, if I have chosen the remaining options;
    - I have the right to access the content of my data, including to receive copies of it and correct it, delete it and limit the processing of it, as well as the right to transfer it, the right to object to the processing of it, and the right to withdraw my consent at any time. However, the withdrawal of my consent shall not affect the lawfulness of processing carried out on the basis of the consent in question prior to its withdrawal;
    - A statement of withdrawal of my consent to the processing of personal data should be submitted to the headquarters of JCommerce Sp. z o.o. or sent to the following e-mail address: zgody@jcommerce.pl. The withdrawal of consent to the processing of personal data shall result in the inability to fulfil the aforementioned processing purposes;
    - The personal data provided shall be shared by JCommerce Sp. z o.o. with the company’s authorised employees and individuals collaborating with JC under civil-law contracts, who are involved in the implementation of the purpose of the processing;
    - The data provided shall be processed on the basis of the relevant provisions of Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), ‘GDPR’;
    - Should you have any questions regarding the protection of your personal data, please contact us by e-mail: odo@jcommerce.pl;
    - The personal data provided shall be processed for the purpose for which it was supplied, or until I express my objection in this regard. In the event of filing an objection, JCommerce Sp. z o.o. shall no longer process my personal data for the aforementioned purposes, unless it can demonstrate that there are valid and legally justified grounds overriding my interests, rights and freedoms or my data is necessary to establish, pursue or defend a claim, if any;
    - I have the right to file a complaint to the supervisory authority if I consider that the processing of the aforementioned personal data violates the provisions of the General Data Protection Regulation of 27 April 2016.