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

closed as too broad by Robert Harvey, user22815, GlenH7, user40980, durron597 May 20 '15 at 2:43

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    you are actually asking a question about project and team management, and not about software architecture... you are asking how to dived responsibility for a system between developers, and how to make management choices to make the system more maintainable. These questions apply to all software architectures. – AK_ May 15 '15 at 13:20
  • 1
    Don't use "Update1" in your questions; this isn't a newsfeed. Questions on Stack Exchange are expected to be written like questions, not a play-by-play. – Robert Harvey May 15 '15 at 15:11

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.

  • 1
    couldn't agree more with the last paragraph – AK_ May 15 '15 at 13:23
  • On one hand. I agree. On other hand, one of the benefits of microservices is ability to choose the rights tools to implement it (which sometimes means a different stack). And I believe documentation isn't enough to have useful Ops team (they need way more) – Victor Ronin May 15 '15 at 14:55
  • @VictorRonin sure, I just said "documentation" as an encompassing set of all the stuff they need, which is mainly documentation. A company can choose a different stack if necessary, but they need to understand the implications of doing that. (eg I know a place that has their system comprised of RoR, erlang and scala... guess what - they can't find the staff who know all those techs to support it!) – gbjbaanb May 15 '15 at 15:43
  • Yeah. Pretty much it was my question, what happens if microservices are built on different stacks... – Victor Ronin May 15 '15 at 16:05

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:

enter image description here

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.

  • Hey... You described the pros of microservices which I am aware of :) I am still not sure how to handle the downside (centralized Ops may not work well with microservices and decentraized Ops don't work because of team size) – Victor Ronin May 15 '15 at 15:00
  • 1
    Any good decision will be based on both pros and cons, not just cons. – Robert Harvey May 15 '15 at 15:15

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

  • Yeah. I am not sure that I formulated corretly. Plain crash is solved easily. However, performance problems in production, some unexpected data which screws everything up and so on (some things which is hard to solve upfront programmatically). A person needed at this moment to fix it. – Victor Ronin May 15 '15 at 14:57

Not the answer you're looking for? Browse other questions tagged or ask your own question.