The “hype” of Microservices has gaining 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 destructives 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 one more 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 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?
Off the Shelf
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.
On-Premise or Cloud? That’s the question!
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:
DevOps is the way to go!
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.
But wasn’t that the idea behind SOA?
It’s been a while (decades, to be honest) we’ve talked about SOA, and in a way, both share multiple practices: Loose coupling, independent services, etc. You’re surely going to hear many people saying that there is no difference between them and vice versa.
This is a discussion that would require a table at a bar and some beers; some people say that adopting an ESB is mandatory for SOA, or use the communication protocols as a way to differ one from the other, or they say that even the difference between them is in the services’ granularity.
Anyhow, there’s a big similarity between the fundamental concepts of SOA and Microservices, but they may and must coexist.
Microservices are a way to apply SOA concepts. Many of the SOA conventional deployments created a service layer on the applications, which replicated data and processes, while Microservices make the “Service” the owner of information and processes, and the applications become channels that consume those REST exposed services.
New Organization: New organization
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 gaining supporters in multiple R&D and IT departments. They tell a little bit how they deployed it in this link.
Microservices need to be managed
One the most effective ways to support a Microservices Architecture is using an API Management Platform, like Sensedia’s, since every microservice must be RESTful, as I said.
A platform like this one will provide the necessary features so that the integrations between your microservices, 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.