Love, hatred, microservices

4 min read

Love, hatred, microservices

Rodolfo Cordero

Software Developer

I’m not a great fan of booming architectures, to put it bluntly. Many new projects have focused their design towards a microservice-oriented architecture. We are talking about an evolution (which does not necessarily bring about improvement, but change) related to many iterations and planning in software development. It can be said that it first started with the idea of avoiding spaghetti code, when originally the idea was to create components, reusable libraries, which can be improved to create high cohesion and low coupling. All these are concepts which have been around for a while in the object-oriented programming.

Problems ofthe monolithic architecture

People have been talking formally about architecture of microservices thanks to the support of agile methodologies and the adaptation of companies such as Netflix, Uber or Amazon. On this video you can see how Netflix have created an ecosystem of thousands of microservices.

Microservices are here to overcome issues of apps which have become monolithic (insert here the movie: 2001: A Space Odissey, just in the scene where a huge rock coming down from the sky collides in front of a bunch of monkeys). We refer to the following issues:

  • It is a huge effort for equipment to make strong testing throughout the application when it is high time to launch it.
  • The difficult part of infrastructure growth, which is more prone to scaling vertically since it is more expensive to go horizontally. Hence, scalability options are reduced.

How do microservices help?

Microservices allow us to work with each feature independently.

  • Adopt any technology or language you deem convenient for each of them
  • Easily scale the most important and high-usage ones, without scaling those which do not carry the same impact
  • Launch new versions any time and go back without a high impact, it should also be said that his depends on the criticality of the micorservice).

Drawbacks of microservices

The development of microservices may bring about several snags:

  • For the infrastructure team and architects it can be a pain to solve issues that come up along the way –for instance- network latency, message formats, load balance and tolerance to failure.
  • Anyway, the infrastructure team should wage its own fight: multiple virtual machines or containers and the deployment of apps and versions will make microservices somewhat complex.

Precautions to bear in mind when choosing microservices

Consequently, how can we ensure better results?

  • When an architecture of microservices is defined it is recommendable to have a separated repository for each microservice (servers, databases and so forth), since tolerance to failure is sought after. For instance, we can see on the following image a communication sample between different microservices on Netflix.
  • To achieve to full potential of microservices, it is recommended to automate and orchestrate infrastructure, we are thus facilitating redundancy and tolerance to failure.
  • Microservices almost force developers to organize themselves in smaller multidisciplinary teams, developing products which tend to develop in shorter time periods.
  • From a DevOps standpoint, automation is key to make the job easier and essentially when microservices and the architecture complexity are increased. (From “Book of the Lazy people”, chapter “I work and now I rest all week long”).
  • Communication among teams is key as in any agile methodology.
  • Documentation is of great help, plus highly appreciated when you need to support a microservice which has remained unchanged for quite a while. (From the book “I should have written the documentation”, chapter “Reflexive thoughts in times of crisis”, first edition).
  • Automated tests are like cheese for hamburgers, necessary and essential (Basic philosophy from the potential overweight person).


Although microservices allow us to create any language or technology as long as the message format is respected, and though this offers a great opportunity of experimentation and innovation, at the same time it is possible that the architecture becomes a zoo of technologies. Maintenance and rotation of developers will become a crusade without Indiana Jones. Bear in mind the previously mentioned tips which will help us make it to see the end of Game of Thrones.

Challenge everything!
About pattern image
  • Data and files
  • Confirmation

How can we help you?

Please provide information so we can contact you.
Please provide correct name
Please provide correct e-mail
Please provide correct description
Attach a file if you wish
You can upload up to 5 files. Max file size: 5MB Allowed file types: .pdf, .doc, .docx, .docm, .ppt, .pptx. File name length must be less than 50 characters File name must not contain two or more spaces in a row File name must not contain the following characters: \/?|<>:*'"+,;=[]&
    We adjusted your file name to our file naming convention. This file extension is not accepted. Please upload one of following file types: .pdf, .doc, .docx, .docm, .ppt, .pptx. This file is too large. The max upload file size is 5MB. Your file size is tiny, please check if you upload correct file.
    Please read and agree to the terms and conditions in order to continue.
    • The controller of personal data in relation to the recruitment is intive GmbH spółka z ograniczoną odpowiedzialnością Oddział w Polsce with its registered office in Warsaw, 1 Sierpnia 8, 02-134 Warsaw. More information on the principles of personal data processing, including the purposes of processing and the rights of individuals, is available in our Privacy Policy.

    Message Sent

    Thank you for your trust, {name}.
    We are looking forward to talk to you.
    Our representative will contact you.
    Dirk Heider

    VP, Project Delivery

    Oh no!

    We have run into problems while submitting your form. Please try again later.