6 ms·
At the last company I was at, our search microservice was fast (average response was well under 100ms) and it didn't crash once while I was there. At a larger c
by brwr 10y ago
At the last company I was at, our search microservice was fast (average response was well under 100ms) and it didn't crash once while I was there. At a larger company, this may not be an accomplishment. At a startup, this is the bees knees.
Meanwhile, the rest of our codebase (a monolith) crashed every few days for one reason or another. We had an on-call rotation not because that's what you're supposed to do, but because we actually needed it.
Now I'm not saying that microservices make sense for everyone. In general, I agree that they are used incorrectly. Microservices are hot and software developers, generally speaking, like to use hot technologies. Yes, moving to a microservice was costly. We had to re-write a lot of code, we had to set up our own servers, and we had to get permission from the guardians that be to do all of this. But, for our use case, and I assume there are other use cases too, the benefits of detaching ourselves from the company's monolithic codebase far outweighed the costs for doing so.
TL;DR No argument is the end to every conversation. Few things are so black and white.
- cs02rm0 10y agoI tend to start with a monolithic service. Sooner or later you get a feel for which bits are becoming at least API stable and could run independently. That's when I split them out. Do it too soon and you end up choosing the wrong boundaries and tying yourself up in knots, do it too late and your monolith can become a mess that's difficult to detach the pieces of.
- brwr 10y agoTrue. There's another thread in here somewhere talking about premature generalization. I think that's what you're getting at with "Do it too soon and you end up choosing the wrong boundaries".
- api 10y agoI tend to try to write monolithic services in such a way that they could be broken up into microservices if that were ever desired. I don't go too far with this, just avoid things like shared static state and other anti-patterns.
- brwr 10y agoYou mean you follow good software development practices? Heresy!
- hosh 10y agoAnother option is to start with an umbrella app (Erlang/Elixir/OTP). It can run like a monolithic or ... nano-services (I suppose) within the same monolith. When it is time to split them out, it is easier. It does assume that you either start with devs familiar with OTP or you have generalist devs that can pick things up quickly.
- user5994461 10y agoAt the last place I was at. We had a micro serviced monolith. I can't even begin to describe that thing in common engineering terms. (note: it's better than it seems).
- scottmmjackson 10y agoTBH microservices do a good job of making you much more dependent on your tools, and selecting the wrong tool for the job won't become clear until you've used that tool for years.