I have a question for people who implemented microservices in large enterprises.
There are obviously huge amount of benefits to microservices (comparatively to monolith architecture).
However, there is one thing which is problematic. It’s harder to do Ops job.
In the case of monolith. There is a group of Ops engineers who make sure that production is up and running. And what is more important there are enough people to create 24/7 on call rotation. As example, if you have 15 Ops then you can create a schedule in which you have couple of persons (for redundancy) on call for a week and everybody will be scheduled only once in two month.
Now, let say a company implemented microservices and each team is responsible for it’s own microservice. A team which has 4-5 engineers will still need somebody on call. And if you try to have the same couple of persons on call then they will be schedule each other week (which would be quite stressfull).
On other hand, you can’t centralize Ops with microservices, because each microservice may have different technological stack, different way of troubleshooting and monitoring. So, central Ops team will be just drowning in amount of info to handle all microservices.
I heard an argument that microservices will be more stable and easily manageable. I believe it’s the case. However, even increase in stability doesn’t remove a need of a person to fix problems if the service went down at 3am and your company business heavily depends on it.
I am curious. How, it’s handled in large enterprises?
One more suggestion was that microservices should use the same stack to allow centralized Ops. Interesting idea. However, I feel that it decrement a value (you can’t choose best technologies for your microservices and have to use standard set).
2
Now, let say a company implemented microservices and each team is
responsible for it’s own microservice.
That’s a fallacy. A company may implement many services from different teams, but its a single production team that will be responsible for keeping it running. That means the dev teams will have to ship enough documentation and/or tools to ensure they can do their job. Which is not much different from any other architecture.
On other hand, you can’t centralize Ops with microservices, because
each microservice may have different technological stack, different
way of troubleshooting and monitoring
Sure, but again – this just means the documentation to keep it running needs to be more complete than if the dev team had produced a standard system using existing tools (as a ‘baseline’ platform would already be understood and thus not need re-documenting).
Most enterprises will only develop on a standard architecture anyway, if you’re a .NET shop the team that releases a Ruby on Rails service will be unappreciated (if they are allowed to deliver such a thing in the first place).
the other aspect to maintenance is that an enterprise will also have standard monitoring requirements. So a production team will say that they expect to see logs in a certain format, with error reports in a certain template, etc. While this doesn’t help with 3rd party services that are bought in, it does mitigate the maintenance cost significantly.
In short, a microservice is not carte blanche for a dev team to throw away existing standards and do whatever they feel like this week. Requirements for the service to work within the existing environment will still be specified in the original request.
4
Microservices are much simpler than their more heavyweight counterparts like JSF, ROR, MVC, CORBA or any number of other enterprise technology acronyms. Simpler means easier to maintain and keep running. Node.JS and NoSQL are also part of this trend towards simpler, more decoupled architectures.
Maintenance is not the only consideration when deciding whether or not to use microservices, however. As you correctly point out, microservices add complexity of their own accord:
Most companies don’t need microservices. Martin Fowler says:
Don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services.
The real challenge is integration of heterogenous components into a coherent system, but this has always been the case, and that problem can be simplified by having all of the microservices conform to a REST architecture and the general simplicity of components that microservices encourages.
2
Micro-services and SoA in general are cool, but they do rely on a comprehensive and resilient infrastructure.
If you havent got enough failover that you still need engineers to come out at 3am when something breaks you probably have more work to do in this area!
In my opinion, its not the ‘server X has crashed emergency!’ that you need to worry about with this architecture, as this can be handled with traditional fail over and redundancy.
It’s the lost messages and broken orchestration between microservices which is the real extra pain over a traditional setup. ‘0.3% of customers don’t get their order when the clocks go forward!’ or ‘products begining with Z aren’t having the sale price modification applied!’ wtfs are your new nightmare
1