.png){kind=small}
.png){kind=small}
Microservices has gained a lot of strength during the last few years, and no wonder why. With poster boys like Amazon and Netflix, it’s hard to argue against it. But what do CIOs need to know about Microservices?
Those giant destroyers of “traditional” business models are the best cases of Microservices Architecture, and let’s be honest, they worked VERY well, but in the end, what does all of that mean?
Microservices Architecture is another design pattern for software architecture. It consists of multiple independent services that carry out specific business functions, and the coupling of these services must be done through a simple and light protocol, that’s why RESTful APIs and gRPC are, normally, the “go to” when performing those integrations.
The advantage of an architecture like that is the possibility to separate each “block” by value delivered to the user. This leads to very specific and smaller services, making the software maintenance easier and adding flexibility, especially if we compare with more restricted monolithic systems.
But then, what do you need to know about Microservices Architecture before diving right in?
Just like all the architectural practices and models, Microservices is not something “purchasable” either, you don’t just decide to purchase a solution ready for your business in a store and suddenly your company is running in this model.
It’s necessary to understand the scenario and all the details of the model, in order to deploy something like this, because each monolithic presents different and specific challenges, and this happens even in scenarios in which an application will be created from scratch.
One of the main considered variables is the form of deploying, the option for Cloud or On-Premise is crucial, since one of the benefits expected in this model is exactly the Deploy speed. For Cloud applications, this benefit is very clear; on the other hand, On-Premise situations might demand an infrastructure different from the current one, and some Deploy coordination efforts.
Which leads me to the next topic:
If you’re talking about Deploy speed, you’re talking about DevOps.
One of the main drivers for Microservices is that you can have the functionalities of that “Microservice” guided by business demands, and enable it to be tested, changed and innovated with the necessary speed to meet those demands. And the best way to guarantee this is through continuous DevOps and releases.
No, the title above is not wrong!
Adopting a Microservices Architecture impacts the Organization architecture, and it can also impact the organization of IT Teams, neither increasing nor reducing, but specializing.
When adopting an architecture like this, some companies reorganized their teams to meet specific business demands, highly specialized teams in some services. And the results come up as significant improvements of “time-to-market”, an exclusive dedication to the value delivered by that specific service, and the increase of autonomy and responsibilities of those teams inside confined environments.
A good example of “reorganization” is the “Squads” methodology, deployed in Spotify, in which every “Squad” has people of different technical skills focusing on a “Mission”: it is normally a specific service, and the people are the experts who will develop this service and solve any problems. The Spotify Engineering Culture has gained supporters in multiple R&D and IT departments. They tell a little bit how they deployed it in this link.
In 2015, we had Jamie Kirkpatrick, from Spotify, speaking at APIX, a spectacular content about their development team, which you can see here.
One the most effective ways to support a Microservices Architecture is using an API Management Platform for North-South communications combined with a Service Mesh tool to East-West communications.
A combination like this will provide the necessary features so that the integrations between your microservices, Web APIs and even your Backend are managed and monitored. In addition, it provides security not only against attacks directed to your API, but also against integrations that might generate an overload in your API. Another important feature to consider in a platform like this one is the possibility to generate metrics and indicators of your APIs, not only of “health”, but also of Business.
If you want to talk to a specialist, fill the form below.
