How about just stop making microservices and go back to monoliths? Then you don’t have to shoehorn two things at the same time!
I think both strategies have pros and cons. But critically, you need a company culture that supports whichever choice you've made.
If you have a company where each team gets to totally decide how they want to implement their stuff, sharing a monolith between teams can create a mess. Ownership issues to be resolved, code quality/style issues, operational issues. Monoliths require alignment.
So do microservices.
My only thoughts to add is monoliths can be aligned as well as microservices, if not a bit easier depending on the team.
You have to align microservices to talk to each other anyways, and there's no reason you can't make those boundaries work in one codebase instead of many.
That said ownership is more important in a monolith, whether that be a single team of architects or architects responsible for a specific well defined part of the code base.
Having a solid process for only allowing well thought out code in is a cornerstone to keeping alignment.
(Under the hood, the service may in fact be distributed to a large pool of resources. But a microservice doesn't shout into a void "hey could someone please handle a LaunchInstanceInRegion class??" - it's like using a library, but over the network.)
Remember when microservices were pitched as 'allowing you to use the right language for the job'? What a wonderful life the person who thinks a balkanised tech stack is good must have had. They're one undisciplined developer away from having production prolog.
It's like we're advocating for the outcome of the Tower of Babel tale.
Micro services replace your unmaintainable bean injection XML abomination with 50 reimplementations of database access and a salary for the one guy who knows his to make your kubernetes setup work.
It's not a technology problem, it's a people problem. Micro services make it a distributed people problem.
I... I don't really understand this sentence.
Its not a quote of a quote, its an attempt at a mocking modification of an upthread comment that isn’t a quote, but the original doesn’t fix the incoherence of the mocking reply.
You'd probably notice that if you were to spend more time reading and less time writing.
I personally think that if microservice is doing something so complicated that the rewrite would take we-cannot-afford-that amount of time, then it should be split into multiple parts.
Interestingly, even a simple CRUD can be made in a complex way in Clojure which makes it difficult to understand for non-clojure devs.
Data migration path is also a huge issue (and the major reason it took so long).
I believe the original service took 6 months to develop (including all iterations of the design/spec), a "simple" 1:1 rewrite a double of that.
"You build it you run it", until the OCaml guy quits and now you need to support OCaml.
I politely explained my position on why that seemed suboptimal.
Yes, maybe the company you work at does not have a good reason to use microservices. But this doesn't mean the same goes for the rest of the industry. Being a nay-sayer and rejecting microservices in any circumstances is just as unreasonable as rejecting monoliths.
No. No no no no! Monoliths (modular or otherwise) are the default and if you have to ask, you don’t need microservices. Period. That’s not a lazy oversimplification, that’s hard earned experience.
In over 15 years I’ve seen microservices singlehandedly kill the engineering momentum at nearly half a dozen companies. They’ve got a worse track record than techbro management. Literally the only time I’ve seen the architecture work well was when I was working at Azure on cloud infrastructure with a dozen teams working on a single product. The vast majority of developers never work on a project of that size and yet try to cargo cult microservices into companies with less than a dozen devs, let alone teams.
Maybe your company is one of the few companies where microservices make sense (or you haven’t come to grips with the stockholm syndrome yet), but the hype around microservices have been a disaster for many more companies than they have helped in my career
But this is not what I am arguing. Yes, monoliths are the default, and unless you reached the point where you have thousands of engineers and teams working completely independently, you don't need microservices. I've also seen momentum being killed by microservices in smaller startups, and I've also seen large organizations operating with microservices wonderfully.
My beef with this kind of comment is that it kills any interesting discussion about architecture into a "don't use microservices" circlejerk, which is not helpful to people who actually want to dive into this kind of architecture. As you said yourself, microservices do work well for large companies, so why pretend it doesn't?
Same reason we don't teach people anything about driving an 18 wheeler when they apply for their regular driver's license. A small minority of drivers will ever even have to think about the topic and when they do, they'll seek out a specialized trucker school or their employer will guide them through the process using institutional knowledge. There is zero value to exposing people with learner's permits to the nuances of driving massive trucks.
Unlike the truckers, however, tech bloggers have hyped up the concept of microservices as a panacea to all developers, resulting in a disastrous cargo cult. There is no interesting conversation to be had about microservices in this context. That discussion is going to be had with all the other senior-most engineers in an organization because any org incapable of such an in-depth discussion internally should not be using microservices.
I agree 100%. However after spending 10 years doing microservices everyone wants me to do microservices, despite me telling them what you just said. It's a positive feedback loop.
This project is just an exploration of providing teams with a low (no?) cost way of doing microservices - I also kinda enjoy hacking on things like this. Still in progress though so use it at your own risk.