Don't start with microservices – monoliths are your friend

Someone please write an article, "Don't start with architecture some dude suggested because of their ego". There are cases when monolith is bad, and when microservice is the must. Take the healthy approach.

The article is garbage with no real understanding how real microservices works:

The deployment: Modern microservices are working using templates. You deploy it using that directly from you gitlab/github. You copy paste your artifact and it's there. The builds are taking 2 minutes to build, sometimes less, means you can quickly react on some issue as opposed to 30 minutes old school java monolith. Deployments are build in the same cluster you use for everything else. CI job runner is just another application in your cluster. So if your cluster is down, everything is down.

The culture part:

We use templates, where you have all the libraries , tracing in place. In fact when this request is coming we have some similar functionality written, so we reply to product, oh, this feature is very similar to feature X, we'll copy it, while we discuss some schedule thing our developer renamed similar project did commit and it's already deployed automatically to the dev cluster, the rest of the team joined to development. There is a bad pattern when you need to update your templates. This is tradeoff of approach, you don't libraries as a concept. Hence that you can have half services migrated, half services don't, that's a bonus. The cons is that you need scripts to push everything immediately.

Better Fault Isolation:

Yes, you might have settings down and core functionality working, means you have less SLA breaking events. Saves you money and customers. Same thing with error handling. If it's just tooling you copy paste a different set of tooling. If the error logging is not implemented in a proper way in the code... It's no different from monolith, it's just errors in code. But things like tracing are already part of the template so for basic evens handlers are traced from deploy #1.

> Service A could be written in Java, service B could be written in Go, service C could be written in Whitespace, if you’re brave enough.

I've always found this to be such a huge strawman. I've yet to encounter an organization that uses a variety of technologies. Usually it's one of the top most popular, sometimes two, rarely three different languages. Devs migrate between teams, hiring is done to match the skills already onboard. Coding styles (even if they differ slightly between teams) usually follow corp "best practices"

Even if it's a multitude of services, the culture of the codebase is usually very monolithic.

Anecdotally, I've seen the strawman become real. Usually it's not more than two different languages. But at my current job, we've got a split between Typescript, vanilla Node.js, and Scala on the backend. All the results of various migrations and refactors spearheaded by different people at different times but not completed. The current vision is to have a unified Scala backend someday, but I'm not holding my breath.

These days DevOps is used as a bludgeon to fire sysadmins and make devs pretend to manage infrastructure. The idea from the corporate viewpoint is to save money by not having anyone to handle systems stuff, just shove into "The CloudTM" as serverless microservices, then just restart it when it falls over instead of troubleshooting.

Yes, I'm cynical. Having to use javalike stuff to do what should be a simple shell script will do that to you.

It's a big tradeoff for maintenance complexity and cognitive load though, and people often don't realize how big that tradeoff is. Chasing bugs and maintaining the spiderweb of network connections between all your services can quickly become a nightmare. A distributed ball of mud instead of a monolithic ball of mud, but a ball of mud nonetheless.

Personally I lean towards building a monolith first, then breaking out features into separate services if you need it. But I've worked on teams that advocated for microservices needlessly, and it was 100% cargo cult behavior: "Netflix does it, so we should too."

Another anecdote: my current company, a startup, could've launched its product a year earlier than it did, but our engineering lead insisted on pre-engineering a Rube Goldberg machine of a microservices backend before we even had any prospective customers. Took months of engineering time and headaches to grok all of it, when in reality, one monolith and a basic database could've done the job for years before we'd ever have to scale past that.

But microservices architecture looks great on a resume, so /shrug