Live data from Hacker News

You want microservices, but do you need them?

docker.com

111–120 of 151 posts

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

#111

Earlier quoted context omitted.

The definitional size I've read and heard is that you team could (with the benefit of hindsight) be able to reimplement a microservice in 2 weeks. That sounds fairly extreme but a month seems within reason to me. The other key difference between microservices and other architectures is that each microservice should do its primary function (temporarily) without hard dependencies, which basically means having a copy of…

That's a pretty extreme definition in my opinion. Google played a role in popularizing the microservice approach. When I was at Google, a microservice would often be worked on with teams of 10-30 people and take a few years to implement. A small team of 4-5 people could get a service started, but it would often take additional headcount to productionize the service and go to market. I have a feeling people overestima…

That's the good old two pizza team service oriented architecture that Amazon is known for. Microservices are much smaller than that. At current job I think we have slightly more microservices than engineers on the team.

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

#112

I don't want or need microservices. What I want is for people to stop putting TCP roundtrips in between what would otherwise be simple function calls in a sane universe. I don't want to have to take a graduate-level course on the CAP theorem to clock in and work on whatever "Uber for dogs" nonsense is paying my rent. You almost certainly don't have a scaling problem that necessitates a distributed system, I guarantee…

I won't say that Kubernetes is great at scheduling, access control, and others, but mainstream OSes aren't superb either. General-purpose OSes are decent for many disparate groups of users but rarely satisfy any one.

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

#113

Earlier quoted context omitted.

That's the most nonsensical reason to adopt microservices imo. Consider this: every API call (or function call) in your application has different scaling requirements. Every LOC in your application has different scaling requirements. What difference does it make whether you scale it all "together" as a monolith or separately? One step further, I'd argue it's better to scale everything together because the total breat…

At this point, I'm convinced that too many people simply haven't built software in a way that isn't super Kubernetes-ified, so they don't know that it's possible. This is the field where developers think 32 GB of RAM isn't enough in their laptop, when we went to the moon with like... 4K. There is no historical or cultural memory in software anymore, so people graduate not understanding that you can actually handle 10…

[deleted]

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

#114
While not a complete rebuttal, allow me the following. I manage a team of 4 scrum masters each with 5-6 engineers. We provide services via a user interface we'll call the console, as would be fairly familiar to any B2B or B2C service provider. The backends of this portal are split up by functional area, so we have a compute management service providing CRUD apis for dealing with our compute offerings, a storage service for CRUD on our storage offerings, a network service for interacting with networks etc. all sharing a single, albeit sharded, underlying data store.

My teams pick up a piece of work, check out the code, run the equivalent of docker compose up, and build their feature. They commit to git, merge to dev, then to main, and it runs through a pipeline to deploy. We do this multiple times a day. Doing that with a large monolith that combines all these endpoints into one app wouldn't be hard, but it adds no benefits, and the overhead that now we have 4 teams frequently working on the same code and needing to rebase and pull in change, rather than driving simple atomic changes. Each service gets packaged as a container and deployed to ECS fargate, on a couple of EC2 instances that are realistically a bit oversubscribed if all the containers suddenly got hammered, but 90% of the time they don't, so its incredibly cost effective.

When I see the frequent discussions around microservices, I always want to comment that if you have a disfunctional org, no architecture will save you, and if you have a functional org, basically any architecture is fine, but for my cases, I find that miniservices if you will, domain driven and sharing a persistence layer, is often a good way to go for a couple of small teams.

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

#115
post #111

Earlier quoted context omitted.

That's a pretty extreme definition in my opinion. Google played a role in popularizing the microservice approach. When I was at Google, a microservice would often be worked on with teams of 10-30 people and take a few years to implement. A small team of 4-5 people could get a service started, but it would often take additional headcount to productionize the service and go to market. I have a feeling people overestima…

That's the good old two pizza team service oriented architecture that Amazon is known for. Microservices are much smaller than that. At current job I think we have slightly more microservices than engineers on the team.

> At current job I think we have slightly more microservices than engineers on the team.

You are free to do that, but that's a very specific take on microservices that is at odds with the wider industry. As I said above, what I was describing is what Google referred to internally as microservices. Microservices are not smaller than that as a matter of definition, but you can choose to make them extra tiny if you wish to.

If you look at what others say about microservices, it's consistent with what I'm saying.

For example, Wikipedia gives as a dichotomy: "Service-oriented architecture can be implemented with web services or Microservices." By that definition every service based architecture that isn't built on web services is built on microservices.

Google Cloud lists some examples:

> Many e-commerce platforms use microservices to manage different aspects of their operations, such as product catalog, shopping cart, order processing, and customer accounts.

Each of these microservices is a heavy lift. It takes a full team to implement a shopping cart correctly, or customer accounts. In fact each of these has multiple businesses offering SaaS solutions for that particular problem. What I hear you saying is that if your team were, for example, working on a shopping cart, they might break the shopping cart into smaller services. That's okay, but that's not in any way required by the definition of microservices.

Azure says https://learn.microsoft.com/en-us/azure/architecture/guide/a...

> Model services around the business domain. Use DDD to identify bounded contexts and define clear service boundaries. Avoid creating overly granular services, which can increase complexity and reduce performance.

Azure also has a guide for determining microservice boundary where again you'd need a full team to build microservices of this size https://learn.microsoft.com/en-us/azure/architecture/microse...

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

#116
The problem I see with microservices is that many realworld problems won't have the clear domain boundaries one would wish for. And the more your problem is one, where every part of the program needs any piece of information occasionally the less it makes sense to split them up into many services.

That does not mean it never makes sense to split up things. It just means there may be differing definitions of what "micro" means and there are problems where the service domains are neatly seperable and others where they are not (or you won't win anything if you separate them).

Turning a thing into a service is just like turning a thing into a module or it's own function. It can be a good idea or a bad idea depending on circumstances.

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

#117

Earlier quoted context omitted.

Erlang seems like a joy to use. I feel a slight pang of regret that I haven't (yet) gotten to use it in my career. (I don't quite have the time or energy to play with it during my off hours, but it is on my list for someday.)

This is kind of why I've never bothered to look at it - everyone /says/ it's a wonderful thing, but... nobody uses it in production, or hobbies (apart from the diehard fans) It might see the light of day at some point in the future, but if the past is anything to go by...

Well the canonical example is WhatsApp, but there are loads of other success stories if you care to look.

Small teams, big results is a characteristic that I’m very interested in, in our post-ZIRP reality.

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

#118

Earlier quoted context omitted.

I love the idea that I can compile all my functionality including HTML templates, javascript, and CSS into a single albeit huge Golang binary. I have never done this yet. But I love the idea of it.

You can already do this with Deno Compile https://deno.com/blog/deno-compile-executable-programs

But that uses Javascript and Typescript, and I don't know those.

I guess I need to learn Javascript at some point.

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

#119
I was once working on a project where we had a gRPC server that inserted data into the DB for another service.

This split was probably a mistake, as the interface we exposed resulted in us making twice as many DB calls as we actually needed to.

One of the stored procs needed a magic number as a parameter, which we looked up via another DB query.

One of the other Devs on the team tried to convince me to write a separate gRPC server to run this (trivial) query.

"We're doing microservices, so we need to make everything as small as possible. Looking up this value is a separate responsibility from inserting data."

Luckily our tech lead was sane and agreed with me.

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

#120
post #59
post #14

in my opinion "you need microservices" peaked around 2018-2019 ... does nowadays someone think that, apart from when you reach certain limits and specific contexts, they are a good idea?

Half of the jobs I'm applying to have microservices in the description, much more often than, say, REST or Boot, so somebody definitely thinks they're a general solution to something.

I went through some interviews where they put microservices in the job description but when asked it turned out to be a kind of monolith for core + a set of other services for other stuff (authentication, logging, analytics).
Post reply on HN