Live data from Hacker News

You want microservices, but do you need them?

docker.com

31–40 of 151 posts

Re: You want microservices, but do you need them?

#31
post #3

The one thing I would like to preserve from microservices is stuff about database table hygiene. Large, shared database tables have been a huge issue in the last few jobs that I have had, and they are incredibly labor intensive to fix.

In my experience basically everything being good in software is downstream of good data modelling.

It's partly why I've realised more over time that learning computer science fundamentals actually ends up being super valuable.

I'm not talking about anything particularly deep either, just the very fundamentals you might come across in year one or two of a degree.

It sort of hooks back in over time as you discover that these people decades ago really got it and all you're really doing as a software engineer is rediscovering these lessons yourself, basically by thinking there's a better way, trying it, seeing it's not better, but noticing the fundamentals that are either being encouraged or violated and pulling just those back out into a simpler model.

I feel like that's mostly what's happened with the swing over into microservices and the swing back into monoliths, pulling some of the fundamentals encouraged by microservices back into monolith land but discarding all the other complexities that don't add anything.

Re: You want microservices, but do you need them?

#32
post #3

The one thing I would like to preserve from microservices is stuff about database table hygiene. Large, shared database tables have been a huge issue in the last few jobs that I have had, and they are incredibly labor intensive to fix.

Why big orgs use microservices: makes teams focused on a clear problem domain

Why small orgs use microservices: makes it nearly physically impossible to do certain classes of dumb shit

Re: You want microservices, but do you need them?

#34
post #9

I don't want microservices! What I want is a lightweight infrastructure for macro-services. I want something to handle the user and machine-to-machine authentication (and maybe authorization). I don't WANT the usual K8s virtual network for that, just an easy-to-use module inside the service itself. You should be able to spin up everything localy in a docker-compose container.

> What I want is a lightweight infrastructure for macro-services. I want something to handle the user and machine-to-machine authentication (and maybe authorization). > I don't WANT the usual K8s virtual network for that, just an easy-to-use module inside the service itself. K8s makes sense if you have a dedicated team (or atleast engineer) and if you really need need the advanced stuff (blue/green deployments, scali…

I tried to use K8s several times, and I just can't make it work. It's fine as a deployment platform, but I just can't justify its complexity for local development.

We're using Docker/Podman with docker-compose for local development, and I can spin up our entire stack in seconds locally. I can attach a debugger to any component, or pull it out of the Docker and just run it inside my IDE. I even have an optional local Uptrace installation for OTEL observability testing.

My problem is that our deployment infrastructure is different. So I need to maintain two sets of descriptions of our services. I'd love a solution that would unify them, but so far nothing...

Re: You want microservices, but do you need them?

#35
post #25

I feel like this has been beaten to death and this article isn't saying much new. As usual the answer is somewhere in the middle (what the article calls "miniservices"). Ultimately 1. Full-on microservices, i.e. one independent lambda per request type, is a good idea pretty much never. It's a meme that caught on because a few engineers at Netflix did it as a joke that nobody else was in on 2. Full-on monolith, i.e. e…

Re 1: I like Matt Ranney's take on it, where he says microservices are a form of technical debt – they let you deploy faster and more independently in exchange for an overall more complex codebase.

This makes it clear when you might want microservices: you're going through a period of hypergrowth and deployment is a bigger bottleneck than code. This made sense for DoorDash during covid, but that's a very unusual circumstance

Re: You want microservices, but do you need them?

#36

You need multiple services whenever the scaling requirements of two components of your system are significantly different. That's pretty much it. These are often called micro services, but they don't have to actually be "micro"

I came here to say the same. If you’re arguing either for or against microservices you’re probably not thinking about the problem correctly. Running one big service may make sense if your resource needs are pretty uniform. Even if they’re not you need to weight the cost of adding complexity vs the cost of scaling some things prematurely or unnecessarily. Often this is an acceptable precursor to splitting up a process.

Re: You want microservices, but do you need them?

#37
I'm helping a company get out of legacy hell right now. And instead of saying we need microservices, let's start with just a service oriented architecture. That would be a huge step forward.

Most companies should be perfectly fine with a service oriented architecture. When you need microservices, you have made it. That's a sign of a very high level of activity from your users, it's a sign that your product has been successful.

Don't celebrate before you have cause to do so. Keep it simple, stupid.

Re: You want microservices, but do you need them?

#38
post #9

I don't want microservices! What I want is a lightweight infrastructure for macro-services. I want something to handle the user and machine-to-machine authentication (and maybe authorization). I don't WANT the usual K8s virtual network for that, just an easy-to-use module inside the service itself. You should be able to spin up everything localy in a docker-compose container.

Unless you need horizontal scalability or clustering, Compose + Terraform is all you need.

With Compose, you get proper n-tier application containerization with immutability. By adding an infrastructure-as-code tool such as Terraform to abstract your IT environment, you can deploy your application on-premises, in the cloud, or at a customer site with a single command.

For clustering needs, there’s Incus, and finally, Kubernetes for very fast scalability (Almost nobody truly needs the complexity of Kubernetes. The ROI simply isn’t there for the majority of use cases.

Post reply on HN