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…
You want microservices, but do you need them?
111–120 of 151 posts
Re: You want microservices, but do you need them?
#112I 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…
Re: You want microservices, but do you need them?
#113Earlier 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…
Re: You want microservices, but do you need them?
#114My 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?
#115Earlier 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.
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?
#116That 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?
#117Earlier 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...
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?
#118Earlier 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
I guess I need to learn Javascript at some point.
Re: You want microservices, but do you need them?
#119This 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?
#120in 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.