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.
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.
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).
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.
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.