3 ms·

In general I agree, but I think microservices applied in the right context can be useful. For example, say you have a system that manages bookings for a really

In general I agree, but I think microservices applied in the right context can be useful. For example, say you have a system that manages bookings for a really popular musical act and frequently crashes with load when tickets go on sale. In that case it could be helpful to have the frontend service that deals with the booking requests isolated so it doesn't bring down the rest of the system. The problem is microservices for the sake of microservices, which seems to be the majority. When a design pattern is applied just because somebody is familiar with it and not because it's the best fit to the problem at hand - that's when things get messy.

andrewstuart2 6y ago
Maybe I'm just not up on the startup or smaller company scene, but isn't it still pretty important to acquire those customers before you worry about whether or not they'll take your systems down? I'd expect that to give you plenty of time to build the monolith, figure out if it's too brittle, too unscaleable, etc, and maybe ground-up rewrite at low cost before you solidify too much by breaking things up Even so, let's say you need to scale very very quickly right away, it's so much easier to profile and optimize a single process. I've been successful in optimizing e.g. a Go library from 100 KB/s to 700MB/s, with about two weeks of work (`pprof` and `go bench` are amazing tools), which then handled 20k tps in an application, and could have scaled out but didn't actually need to. I've also gotten millions of rows in a postgres database to be full-text searchable in under 10ms, also with maybe only a week of work. I can't readily think of a time (and I've had plenty of opportunity these days) where I've successfully diagnosed and optimized underperforming distributed systems, despite having spent months discussing and attempting to measure performance issues and trying various "yeah maybe that could work" fixes. Granted, It's almost certainly always been the case of microservices for the sake of microservices, but I always come back to the lack of tooling (no compiler to tell you that you broke some contract), the siren call of polyglot microservices that makes it a lot harder to build common tooling, and the temptation to prematurely send microservices to different teams (further adding to the lack of agility), as really solid reasons to stay smaller as long as possible.
- jordwest 6y ago
  Yeah I'd agree that for most startups a monolith makes more sense. It's usually easier to add microservices later if they're needed than to go the other way. Your point about the Go binary reminds me of a related problem. We so often come up with solutions (like microservices) to performance problems that just add more complexity, when often the performance problems can be solved by reducing complexity. Then as you say it becomes so complex that it's more difficult to fix later problems.
  - csharptwdec19 6y ago
    Dangerous statement... Is it because the 'problem solvers' in question don't in fact know how to solve the complexity in code?
    - jordwest 6y ago
      Possibly somewhat, but I think more often its that reducing complexity isn’t valued in many organisations. It’s usually faster to apply a patch over solution than to go and reduce complexity in the existing system. Also the larger the system, the less willingness there is to risk changing something that already exists - technically and politically. As an example, imagine that you have a very slow service. You could dig in and find the bottlenecks, and rewrite the service to remove those bottlenecks. Or you could just add a caching layer on top. The cache layer likely solves the problem quickly, but it adds more complexity to the system overall.
twic 6y ago
You don't need microservices to do this. Build a monolith which does everything. Deploy multiple instances. Route booking requests to a subset of the instances. Route other requests to the other instances. We did this at an old job. We had a data-intensive app which had a web UI for users, an admin UI, and an API for data export. They all had lots of common code for persistence, querying, aggregation, etc. Because of the common code, the simplest way to implement the three interfaces was in a single codebase. But because API requests could sometimes crash the app (we didn't do a great job here!), we segregated the API into its own pool of instances. We didn't segregate the admin UI, but could have done that if necessary. As well as simplicity, another advantage of this approach is that the decision about how to split up traffic is very dynamic: you can change it just by adding or removing instances and changing load balancer config, without having to make any code changes. if you split the traffic up into separate microservices, you have to make that decision upfront, and changing it is a lot of work.
- deleted 6y ago
  [deleted]
- amf12 6y ago
  > Build a monolith which does everything. Deploy multiple instances. Route booking requests to a subset of the instances. Route other requests to the other instances. Don't you now have "microservices" bundled together in a single binary - and deployed together? If each of your component exposes different APIs and each instance only handles certain endpoints, then you kind of have microservices - not literally, but it seems the idea is the same. Simplicity being a benefit, I don't really see how the dynamic traffic routing is a huge benefit vs microservices - you can dynamically scale up/down microservices too. I am not saying this is a bad approach, by the way, but just that it isn't much different from microservices.
  - tmd83 6y ago
    I think you can use such an architecture without almost zero or minimal code change. You don't have to split the shared endpoints using some remote API calls since they are all available inside your monolith.

andrewstuart2 6y ago

Maybe I'm just not up on the startup or smaller company scene, but isn't it still pretty important to acquire those customers before you worry about whether or not they'll take your systems down? I'd expect that to give you plenty of time to build the monolith, figure out if it's too brittle, too unscaleable, etc, and maybe ground-up rewrite at low cost before you solidify too much by breaking things up Even so, let's say you need to scale very very quickly right away, it's so much easier to profile and optimize a single process. I've been successful in optimizing e.g. a Go library from 100 KB/s to 700MB/s, with about two weeks of work (`pprof` and `go bench` are amazing tools), which then handled 20k tps in an application, and could have scaled out but didn't actually need to. I've also gotten millions of rows in a postgres database to be full-text searchable in under 10ms, also with maybe only a week of work. I can't readily think of a time (and I've had plenty of opportunity these days) where I've successfully diagnosed and optimized underperforming distributed systems, despite having spent months discussing and attempting to measure performance issues and trying various "yeah maybe that could work" fixes. Granted, It's almost certainly always been the case of microservices for the sake of microservices, but I always come back to the lack of tooling (no compiler to tell you that you broke some contract), the siren call of polyglot microservices that makes it a lot harder to build common tooling, and the temptation to prematurely send microservices to different teams (further adding to the lack of agility), as really solid reasons to stay smaller as long as possible.

jordwest 6y ago
Yeah I'd agree that for most startups a monolith makes more sense. It's usually easier to add microservices later if they're needed than to go the other way. Your point about the Go binary reminds me of a related problem. We so often come up with solutions (like microservices) to performance problems that just add more complexity, when often the performance problems can be solved by reducing complexity. Then as you say it becomes so complex that it's more difficult to fix later problems.
- csharptwdec19 6y ago
  Dangerous statement... Is it because the 'problem solvers' in question don't in fact know how to solve the complexity in code?
  - jordwest 6y ago
    Possibly somewhat, but I think more often its that reducing complexity isn’t valued in many organisations. It’s usually faster to apply a patch over solution than to go and reduce complexity in the existing system. Also the larger the system, the less willingness there is to risk changing something that already exists - technically and politically. As an example, imagine that you have a very slow service. You could dig in and find the bottlenecks, and rewrite the service to remove those bottlenecks. Or you could just add a caching layer on top. The cache layer likely solves the problem quickly, but it adds more complexity to the system overall.

twic 6y ago

You don't need microservices to do this. Build a monolith which does everything. Deploy multiple instances. Route booking requests to a subset of the instances. Route other requests to the other instances. We did this at an old job. We had a data-intensive app which had a web UI for users, an admin UI, and an API for data export. They all had lots of common code for persistence, querying, aggregation, etc. Because of the common code, the simplest way to implement the three interfaces was in a single codebase. But because API requests could sometimes crash the app (we didn't do a great job here!), we segregated the API into its own pool of instances. We didn't segregate the admin UI, but could have done that if necessary. As well as simplicity, another advantage of this approach is that the decision about how to split up traffic is very dynamic: you can change it just by adding or removing instances and changing load balancer config, without having to make any code changes. if you split the traffic up into separate microservices, you have to make that decision upfront, and changing it is a lot of work.

deleted 6y ago
[deleted]
amf12 6y ago
> Build a monolith which does everything. Deploy multiple instances. Route booking requests to a subset of the instances. Route other requests to the other instances. Don't you now have "microservices" bundled together in a single binary - and deployed together? If each of your component exposes different APIs and each instance only handles certain endpoints, then you kind of have microservices - not literally, but it seems the idea is the same. Simplicity being a benefit, I don't really see how the dynamic traffic routing is a huge benefit vs microservices - you can dynamically scale up/down microservices too. I am not saying this is a bad approach, by the way, but just that it isn't much different from microservices.
- tmd83 6y ago
  I think you can use such an architecture without almost zero or minimal code change. You don't have to split the shared endpoints using some remote API calls since they are all available inside your monolith.