3 ms·
I agree with the author to some extent. The main thing, however, is many people think that, by breaking up their monolith into services, that they now have mic
by outworlder 8y ago
I agree with the author to some extent.
The main thing, however, is many people think that, by breaking up their monolith into services, that they now have microservices. No, you don't. You have a distributed monolith.
Can you deploy services independently? No? You don't have microservices. Can you change one microservice data storage and deploy it just fine? If you are changing a table schema and you now have to deploy multiple services, they are not microservices.
So, you take a monolith, break it up, add a message broker, centralized logging, maybe deploy them on K8s, and then you achieve... nothing at all. At least, nothing that will help the business. Just more complexity and a lot more stuff that need to be managed and can go wrong.
And probably a much bigger footprint. Every stupid hello world app now wants 8GB of memory and its own DB for itself. So you added costs too. And accomplished nothing a CI/CD pipeline plus sane development and deployment practices wouldn't have achieved.
It is also sometimes used in lieu of team collaboration. Now everyone can code their own thing in their own language without talking to anyone else. Except collaboration is still needed, so you are accruing tech debt that you know nothing about. You can break interfaces and assumptions, where your monolith wouldn't even compile. And now no-one understands how the system works anymore.
Now, if you are designing a system using microservices properly, then it can be a dream to work on, and manage in production. But that requires good teamwork on each team and good collaboration between teams. You also need a different mindset.
- qaq 8y agoDo you have a recommended way of handling transaction boundaries that span multiple services. Everyone always likes to outline how happy path works and when it comes to real world it basically comes down to well now you have eventually consistent distributed system that there is no general valid way to unroll a change to multiple services if one of the calls fails.
- dudul 8y agohttps://microservices.io/patterns/data/saga.html https://microservices.io/patterns/data/saga.html
- qaq 8y ago"In order to be reliable, a service must atomically update its database and publish a message/event." so in other words to some transaction log so we just reinvented a distributed transactional database system with crapload of custom programming overhead. Whatever solution is described they all pretty much boil down to an equivalent of distributed eventually consistent database or distributed acid database but with a large number of database functionality pushed into the application.
- pojzon 8y agoSo distributed acid db... Noone till now (from what i have seen) came up with a better solution than guys 50 years ago..
- dustindiamond 8y agoWell, we’ve gotten this far...
- analyst74 8y agoIf several databases/services are so tied together that they need to be updated/rolled back at the same time, then they belong to the same service/database. There will be times when you trade data consistency for performance/scalability, i.e. in a scenario where you are breaking user actions away from the main user service, if a user is deleted but deleting from user actions failed, you don't roll back the user delete. Either just let the invalid data sit in user actions database, or do separate clean-ups periodically.
- shapiro92 8y agoYou can break up the monolith, use a message broker or even let the services communicate via http but you do not need K8s. Its pointless unless you want to orchestrate multiple vms/images and your infra scales to that of more than 10-15 servers/containers etc.