Comment by karmakaze

Comment by karmakaze 3 days ago

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 the data that's needed. Service Oriented Architecture doesn't have this as one of its properties which is why I think of it as a mildly distributed monolith. "Distributed monolith" is the worst thing you could call a set of microservices--all the pain without the gains.

ants_everywhere 3 days ago

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 overestimate how small microservices are and underestimate how big monorepos are. About 9 times out of ten when I see something called a monorepo it's for a single project as opposed to a repo that spans multiple projects. I think the same is true of microservices. Many things that Amazon or Google considers microservices might be considered monoliths by the outside world.

Reply View 3 replies

hosh 2 days ago

Kubernetes is a good example of a microservice architecture. It was designed in a way where each microservice work with other microservices in a way where the dependencies are not so coupled together.
For example, the API server only reads and writes resources to etcd. A separate microservice called the scheduler does the actual assignment of pods to nodes by watching for changes in the resource store against available nodes. And yet a different microservice that lives on each node accepts the assignment and boots up (or shuts down) pods assigned to its node. It is called the kublet. The API server does none of that.
You can run the kublet all on its own, or even replace it to change part of the architecture. Someone was building a kublet that uses systemd instead of docker, and Fly.io (who seems to hate kubernetes) wrote a kublet that could stand things up using their edge infrastructure.
The API server also does some validations, but it also allows for other microservices to insert itself into the validation chain through pod admission webhooks.
Other examples: deployment controllers, replicaset controllers, horizontal pod autoscalers, and cluster autoscalers to work independently of each other yet coordinated together to respond to changing circumstances. Operators are microservices that manage a specific application component, such as redis, rabbitmq, Postgresql, tailscale, etc.
One of the big benefits of this is that Kubernetes become very extensible. Third-party vendors can write custom microservices to work with their platform (for example, storage interfaces for GCP, AWS, Azure, or Ceph, etc). An organization implementing Kubernetes can tailor it to fit their needs, whether it is something minimal or something operating in highly regulated markets.
Ironically, Kubernetes is typically seen and understood by many to be a monolith. Kubernetes, and the domain it was designed to solve is complex, but incorrectly understanding Kubernetes as a monolith creates a lot of confusion for people working with it.

Reply View | 0 replies
treis 3 days ago

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.

Reply View | 1 reply
- ants_everywhere 3 days ago
  
  > 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...
  
  Reply View | 0 replies