5 ms·

I think the article is missing a key value of microservices, or at least smaller services: service ownership. With a monolith, who is on call for the service wh

by sreque 10y ago

I think the article is missing a key value of microservices, or at least smaller services: service ownership. With a monolith, who is on call for the service when something goes wrong? How does that person find an appropriate person to diagnose the issue in one of the 100 libraries included in the monolith? What does the monolith dashboard look like? The great thing about small services is that a team developing a service can own it from top to bottom: including: 1) being responsible for metrics, alarms, dashboards, and everything else required to monitor the service 2) being oncall for the service and getting directly paged when their are problems And of course, there are other social/organizational problems with a monolith, another example being deployments. I want to deploy my new feature but I'm blocked because someone introduced a bug in some unrelated library that's clogging the entire pipeline. Or, I have to release my feature according to the deployment schedule of the monolith, which may not make sense for my team. With smaller services, a team can own its own deployment pipeline and decide when it wants to deploy. A third organizational benefit of smaller services comes process separation. GC'ed languages work really hard to help developers pretend that memory is free, but memory is still a finite shared resource and it only takes one misbehaving module to cause the whole process to start stalling in large GC pauses. With smaller services you get process separation which makes the problem much more tenable. And of course there are other exhaustible shared resources like threads, and file descriptors. At the end of the day, I prefer smaller services because I like the social organization where a company consists of agile, autonomous teams owning their own services. I feel a monolith service actively discourages that and leads to social organizations that are less productive and successful.

abrookewood 10y ago
All fair points, but I think people ignore the challenges associated with microservices: much more complex to debug (which service is failing); inter-service latency (things run much faster on a single box); VM/instance sprawl (because every service should run on its own host x redundancy x multiple environments); increased costs (see vm sprawl). I still think the advantages outweigh the disadvantages, but they definitely come at a cost.
eloff 10y ago
Those are organizational concerns that you're conflating with microservices vs monolith. They're tangential. I see no reason why you can't assign team responsibility to individual modules vs microservices. You can collect metrics for both modules and microservices and publish them in a dashboard. Alarms and monitoring are probably unnecessary at the module level in most cases - you'd just do it once for the whole monolith.
- sreque 10y ago
  Good point, but I don't think it's necessarily incorrect to conflate organizational concerns with architectural concerns. I am reminded specifically of Conway's law: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law It may be possible to deploy a monolith without having monolithic processes and organizations in place, but does anyone have experience successfully doing so in practice? And how easy is it compared to doing so with smaller services?

by sreque 10y ago

abrookewood 10y ago

All fair points, but I think people ignore the challenges associated with microservices: much more complex to debug (which service is failing); inter-service latency (things run much faster on a single box); VM/instance sprawl (because every service should run on its own host x redundancy x multiple environments); increased costs (see vm sprawl). I still think the advantages outweigh the disadvantages, but they definitely come at a cost.

eloff 10y ago

Those are organizational concerns that you're conflating with microservices vs monolith. They're tangential. I see no reason why you can't assign team responsibility to individual modules vs microservices. You can collect metrics for both modules and microservices and publish them in a dashboard. Alarms and monitoring are probably unnecessary at the module level in most cases - you'd just do it once for the whole monolith.

sreque 10y ago
Good point, but I don't think it's necessarily incorrect to conflate organizational concerns with architectural concerns. I am reminded specifically of Conway's law: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law It may be possible to deploy a monolith without having monolithic processes and organizations in place, but does anyone have experience successfully doing so in practice? And how easy is it compared to doing so with smaller services?