How about just stop making microservices and go back to monoliths? Then you don’t have to shoehorn two things at the same time!
Make microservices look like monoliths
11–20 of 106 posts
Re: Make microservices look like monoliths
#12It makes no sense. Why not just create modular monolith?
On a large/quickly growing team the risk is folks begin to not respect the modularity and you end up with just a regular monolith
Perhaps formalized abstractions around these barriers is a good idea? At the very least better than the 60 kubernetes services at my 100eng headcount team? :-)
Re: Make microservices look like monoliths
#13It makes no sense. Why not just create modular monolith?
Because all these idiots who pitched microservices super hard need to undo the mess they've created while self promoting themselves into new thought leadership roles.
Yeah, I was just talking to the CEO of a startup that I built the tech for, and still have a small equity stake in.
They formed a partnership with some dev shop that's going to rebuild everything that I made (that's working great and scales well).
I asked her why, and she said "because they say that doing microsevices on Azure is better architecture".
There goes that bit of equity, I guess.
/shrug
Re: Make microservices look like monoliths
#14I wonder what the rationale behind AGPL is? Prevents it from being used for commercial SaaS
Re: Make microservices look like monoliths
#15How about just stop making microservices and go back to monoliths? Then you don’t have to shoehorn two things at the same time!
I spent a decade at Amazon (SOA all the things!) and then a year and a half at Shopify (single Rails monolith for all the things!).
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.
Re: Make microservices look like monoliths
#16I’d rather compose my systems with widely understood and commonly used components that make hiring and maintaining over time more of a puzzle problem than a, “learn a new framework” problem. This feels like we make our jobs harder than they have to be, sometimes…
I’m working a short term job (while they find a FTE hire) for a friends startup since their last SDE quit unexpectedly. The last employee tried every framework and architecture pattern under the sun. This company has more micro services than employees and customers combined. Each one is like ~200LOC, uses a different framework, etc.
I’ve spent the last month just deleting shit and simplifying shit. You don’t need a caching layer for customer data when your entire SQL database is 100 rows in a single table. You don’t need service discovery when everything runs on one node.
My point is that this entire system was designed around their last engineer’s bookmarks of interesting things, not designed to be maintainable or easy to iterate upon.
Re: Make microservices look like monoliths
#17It makes no sense. Why not just create modular monolith?
Because all these idiots who pitched microservices super hard need to undo the mess they've created while self promoting themselves into new thought leadership roles.
Is it the fault of the thought leader, or the loads of juniors asked to implement the architecture but don't really understand it? If everyone had better system design knowledge, it wouldn't be so bad. 90% of the engineers in my organization don't understand the function of an API Gateway, for example. So the thought leader does propose a reasonable solution, but then it doesn't work because the organization doesn't have the hard skills necessary to deliver. I'm sure there's other reasons microservice-based architecture fails, but in my experience, this is a primary reason.
Re: Make microservices look like monoliths
#18How about just stop making microservices and go back to monoliths? Then you don’t have to shoehorn two things at the same time!
Microservices: Software complexity solutions to human organisation problems.
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.
Re: Make microservices look like monoliths
#19I’d rather compose my systems with widely understood and commonly used components that make hiring and maintaining over time more of a puzzle problem than a, “learn a new framework” problem. This feels like we make our jobs harder than they have to be, sometimes…
I’m working a short term job (while they find a FTE hire) for a friends startup since their last SDE quit unexpectedly. The last employee tried every framework and architecture pattern under the sun. This company has more micro services than employees and customers combined. Each one is like ~200LOC, uses a different framework, etc. I’ve spent the last month just deleting shit and simplifying shit. You don’t need a c…
Blame a few things:
1. The developer, of course.
2. The person who let them do it.
3. The eight thousand devtool companies that pitch their solutions to developers.
4. The hiring managers for whom 'resume driven development' is effective.
5. The VCs who wrote the playbook for how all these companies (and the dev tool companies) have to grow.
6. The Fed for so much ZIRP that VCs are in power.
7. The government for uncontrolled spending that needs low interest rates to sustain.
8. The electorate for electing the government.
9. The media for influencing the electorate.
10. The human brain for being susceptible to influence.
Re: Make microservices look like monoliths
#20It makes no sense. Why not just create modular monolith?
Most devs, even senior, have no clear idea what a modular monolith is, let alone implementing one