[outworlder]

> Friendly reminder that you shouldn't spend time fine tuning your horizontal autoscaler in k8s

Oh, but most companies need this!

The biggest feat of microservices (which require ways to manage them, like k8s) was to provide the ability for companies to ship their organizational chart to production.

If you don't need to ship your org chart and you can focus on designing a product, then you can go a long way without overly complicating your architecture.

[antonvs]

I think this org chart issue has been overstated.

If you have two services that are completely orthogonal, then combining them into a single application for deployment and operation purposes can be limiting. Developers of all people should understand the benefits of decoupling.

There are a lot of downsides that come with jamming a whole lot of unrelated functionality into the same deployment unit. It's similar to the problems created by global variables. Once you start to depend on your services operating in a monolith, you can easily create rigidity that can be difficult to roll back.

It's not that you can't design a monolith well, but microservices force you to consider important boundaries as opposed to simply violating them for the sake of convenience. It's another "human" issue, but it's unrelated to org charts.

This doesn't mean that everything should be a microservice, though. Good architecures address the requirements of the systems being developed.

[__jem]

I think the deployment benefits have been even more overstated.

This is an absolutely enormous trade-off between logical modularity and run time operational complexity.

If your devs aren't good enough to enforce modular design in a single application, what makes you think they're good enough to handle complex distributed systems?

[antonvs]

> If your devs aren't good enough to enforce modular design in a single application, what makes you think they're good enough to handle complex distributed systems?

That's a simplistic take on the reasons that monoliths tend towards breaking modularity.

What makes me think managing microservices is perfectly viable is that the last three companies I've been at have been able to do it successfully, with a typical mix of good and less good developers, including cheap offshore devs.

As for handling "complex distributed systems," in many cases all that's really needed is something like a managed container platform. Services like Fargate or Cloud Run, or managed Kubernetes, can do a good job of this. Developers can deploy and publish new services with minimal effort, and most of the operational complexity is managed by the platform.

You do ideally want someone paying attention to overall architecture to avoid obvious pitfalls, such as effectively doing distributed joins via REST calls, and so on. This isn't that hard to understand, though, and teams that don't do the necessary architecture upfront tend to figure it out once they run into those problems themselves.