Now that everybody in the software industry is talking about DevOps practices, we've seen a large number of software-powered organizations adopting both DevOps microservices architecture.
Moving to Microservices
"Microservices" is a strong and fancy word, isn’t it? Everybody is talking about it, so why not you?
Check out some benefits of moving to microservices architecture here.
Everybody is only talking about the positive parts of moving to microservices. Do you really need microservices architecture? To find out, you should ask yourself these questions:
How independent do you want your services to be?
How well your code is organized? Mono repo or multiple repositories?
How much operational complexity can your team handle?
Do you have a Continuous Delivery platform in place?
How is your team organized? Do they have knowledge about different toolsets and microservices architecture?
The third and fourth points are very strong because they talk about operational complexity and CD platforms. Microservices greatly increase operational complexity since you need to rethink operations from a very fundamental standpoint.
You need to consider the following aspects.
Infrastructure
Defining infrastructure requirements for microservices and then provisioning and maintaining infra for each microservice adds a degree of complexity that most Ops engineers working on monoliths are not accustomed to. Plus, as these services are scaled up and down, infrastructure needs to be provisioned and brought down automatically, so you need a very sophisticated level of automation.
Load Balancing and Scaling
You will likely need a scaling strategy that is much more complicated than for monolithic applications, which are always scaled out (x-axis). With microservices, you will need to figure out if you need to scale all services or just a subset when there is a spike in demand. Your Ops team will need to understand y-axis scaling since the microservices approach is consistent with it, as well as z-axis scaling to get the benefits of x and y.
Service Discovery
The set of service instances in a microservices world changes dynamically due to scaling and upgrades. Also, services have dynamic network locations, so you need a way for new service instances to be discovered. We recommend a service registry like Consul for this, since it has worked very well for us.
Monitoring
This has to be configured and maintained for every microservice, increasing the complexity for Ops engineer(s). Also, the monitoring solution has to handle scenarios where a subset of services are scaled up and down.
The operational complexity itself should give you some pause before you decide to move to microservices. Unless you are aware of the challenges with microservices and have a plan to address them, it will be a painful transition.
Do You Have a CD Pipeline in Place?
Organizations like Netflix and Amazon that evangelize microservices have the resources to build homegrown custom Continuous Delivery pipelines for their microservices. However, not every organization can afford to do that. You might have to depend on external platforms like Shippable, Circle CI, XebiaLabs, or Travis CI to do things for you.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}