@yatish_me Since this is such a well known phenomenon, how is this allowed to happen by product and business counterparts / leadership?

@ankitjain How will you get promoted?

@yatish_me Many stories such as this. Plus, adding third-party authentication, search/etc services to the mix to make it "composable", "best of breed", etc. In the end, making everything super complex and slow to develop :)

@damianlegawiec I will never get "third-party authentication"

@yatish_me I work for Amazon. Maintain 2 internal Rails tools myself. They built a team around me to build a third tool. React front end + lambda. It is so unnecessarily complicated I want to cry every time I work on it.

@yatish_me Cargo culting + farming resume lines

@yatish_me Must be a very good business, for they'd been in that situation for 5 years, navigating the system complexity, and borne the headcount cost.

@yatish_me Why is every company's leadership ex-amazon ? Have seen this pattern a lot.

@yatish_me "my team failed to refactor to a standard software paradigm" is not a flex

@yatish_me That's not a FAANG thing. The whole microservices movement, i think was kicked off by Thoughtworks' Martin Fowler, got picked up by edgy consultancies; and touted as a silver bullet; because microservice architectures were supposed to be more modular and testable blah blah.

@yatish_me How do you stop people from quitting when they inevitably realize they made an useless mess?

@yatish_me Ive seen this exact pattern but in a slightly different manner. Seed stage startup with handful of customers decides to bring in similar folk of “caliber” but never worked in a startup before and refused to learn the stack. Their solution was to gut everything out and rebuild

@yatish_me Pathological cargo culting.

@yatish_me Started a consulting work, first thing I did was to take the micro service architect and moved it to a monolith. Significant cost and complexity decrease 👍🏻

@yatish_me @levelsio Classic case of over-engineering for complexity that didn’t exist. 🛠️ Sometimes the simplest solution sticking with the monolith and improving domain modeling is way more effective than chasing “enterprise-scale microservices” for their own sake.

@yatish_me Microservices are typically complicated, slow to build, resistant to change(!), expensive to run and non performant. But hey, they’re much more fancy than single service.

@yatish_me Tale as old as time. A nightmare to test as well, no doubt

@yatish_me Isn't this easily avoided by declaring that the monolith code can't be broken apart until there is evidence that there are 10,000 sustain simultaneous users on the app? Most corporate apps never have more than 8 simultaneous users.

@yatish_me The usual story of Aws-microservices hammer. Is there a graphql in it somewhere?

@yatish_me Kind of describes a popular stock circulating.

@yatish_me What percentage of developers voted against this change? How many embraced the new toys? It's easy to blame solely the head and principal in hindsight.

@yatish_me A new hire saying "You're doing wrong!" should be a fireable offence.

@yatish_me @levelsio Been there as well. I’ve learned that we should just make incremental changes to the “monolith” and break it down if possible but keep the same tech stack and architecture. Develop green field applications with a newer tech stack (if needed) with better designs and

@yatish_me don't fix it if it ain't broke

@yatish_me I see similar architectures all the time during pre-LOI due diligence. The dev teams always seem to be paralyzed by the overly complicated messes they’ve created.

@yatish_me Another reminder that hiring people from companies like Amazon might not be a good fit, unless your company looks a bit like Amazon.

@yatish_me interesting! it is counterintuitive to think that how can bad code live longer than someone’s intentions of making good code, but maybe, most people just don’t want to fix the bad parts and think that fresh rewrites are the answer. incremental improvements and working on the

@yatish_me "The thing that got you here and brought you to our attention must be the problem because we didn't build it" is so common it probably needs an acronym.

@yatish_me Great now just have AI finish the migration

@yatish_me How many engineers worked before this change to microservices happen? How was the workflow?

@yatish_me Imagine those salaries + time spent on that project. Insane price per hour. And for what? A worse off application…

@yatish_me A classic technical masturbation project. In a quest to show off ones ”technical genious”. Trying to fix something not broken…

@yatish_me Have seen this exact playbook play out in the same exact manner. Funnily enough, they were also from Amazon. Number of services went from <30 to 100+ while team size initially remained the same. Then the team size went down by 80%. One can imagine how hard the maintenance became.

@yatish_me Microservices and meshes solve organizational problems and cause technical problems. Almost never the right thing to do

@yatish_me Were you at Opendoor?