[ilovecaching]

The vast, vast, vast majority of organizations don't need micro services, don't need half of the products they bought and now have to integrate into their stack, and are simply looking to shave their yak to meet the bullet list of "best practices" for year 202X. Service oriented architectures and micro services solve a particular problem for companies that are operating on a massive scale and can invest (read waste money) on teams devoted to tooling. What most companies should do is build a monolith that makes money, but hire good software engineers that can write packages/modules whatever with high levels of cohesion and loose coupling, so that one day when you become the next Google, it will be less of a pain to break it into services. But in the end it really doesn't matter if it's painful anyway, because you'll have the money to hire an army of people to do it while the original engineers take their stock and head off to early retirement.

[danielvaughn]

I'd never worked with micro-services before this latest freelance project. I start working with this platform that is basically "note taking but with a bit of AI/ML". So okay, a bit of complexity with the ML stuff, but otherwise a standard CRUD app.

The application itself is a total of 3 pages, encompassing maybe 20 endpoints at the most, with about 100 daily active users. For the backend, some genius decided to build a massive kubernetes stack with 74 unique services, which has been costing said company over $1K/month just in infra costs. It took me literally weeks to get comfortable working on the backend, and so much stuff has broken that I have no idea how to fix.

Not only that, but the company has never had more than 1 engineer working on it at a time (they're very small even though they've been around a bit). If there were such a thing as developer malpractice, I'd sue whoever built it.

[midrus]

This is so common, sadly. I've seen this happen a lot. And those geniuses advocating for these insane infrastructure usually leave the company after they scratched their itch with kubernetes or whatever they were interested in playing with I'm s strong believer that your first few engineers are very very, very important and you need to hire very experienced people.

In the cases I've seen this, honestly I think the ones to blame where the stakeholders, for hiring very young people, for the cheapest rate they could and giving them full responsibility and the Senior Architecure Something Something title when those people don't have more than a couple years experience and are just building what they read in a blog two weeks ago.

[DerArzt]

> 3 pages .... 74 unique services

Just, wat.

Sounds like the architect was doing some resume driven development cause damn.

[danielvaughn]

In all honesty I'm very angry about it. It was built a while ago, and the dev is no longer here, but I almost want to track him down and make him help fix it. This founder isn't technical, so he's been leaning on developers for guidance, and this guy basically built him a skyscraper when what he really needed was a shed. It hurts to think about all the time and money that he's poured into just maintaining it. Crazy.

[nivethan]

Bit late, but is it worth cutting up? Sunk cost I imagine will sting but simplifying might get rid of a lot of the fear.

[Calamitous]

Heh, that beats the ratio at my current job: 7 pages and ~45 unique services.

[ammanley]

_74_ services on a k8 stack for 3 pages and 100 active daily users?????

This has to be a crime.

[danielvaughn]

Ok I feel very validated now - I'm not used to microservices so didn't know what was typical. It felt crazy, so good to know based on this comment's responses that it is indeed crazy.

For example, in order to sign up a user...the client hits the /signup endpoint, which first lands on the server-gateway service. Then that is passed along to an account-service which creates the user. Then the accounts-service hits a NATS messaging service twice - one message to send a verification email, and another to create a subscription. The messaging service passes the first message along to the verification-service, which sends out a sendgrid email. Then the second message gets passed along to a subscription-service-worker. The subscription-service-worker adds a job to a queue, which when it gets processed, hits the actual subscription-service, which sends along a request to Stripe to create the customer record and trial subscription.

6 services in order to sign up a user, in what could have been done with about 100-300 lines of Node.

[Beltalowda]

Even the most fanatical microservices proponent will tell you that's just bonkers.

At my very first programming job many years ago I was given a bunch of code written by a string of "previous guys" (mostly interns) over a period of 10 years or more and was told "good luck with it". I was the only developer, with no real technical oversight. It was my first "real" programming job, but I had been programming for many years already (mostly stuff for myself, open source stuff, etc, but never "real" production stuff).

In hindsight, I did some things that were clearly overcomplicated. I had plenty of time, could work on what I wanted, and it was fun to see if I could get the response speed of the webpage down from 100ms to 50ms, so I added a bunch of caching and such that really wasn't needed. Varnish had just been released and I was eager to try it, so I added that too. It was nowhere near the craziness you're describing though, and considering the state of the system when I took things over things were still massively improved, but I'd definitely do things different now because none of that was really needed.

Maybe if it had been today instead of 15 years ago I would have gone full microservice, too.

[danielvaughn]

Ha, yeah I created my fair share of complex stuff when I first started.

For some reason, even today, my personal projects tend to get very complex. But I think that’s just because I’m working on hard problems since they’re passion projects.