[flagged]
What Even Are Microservices?
31–40 of 87 posts
Re: What Even Are Microservices?
#32Microservices are service/s that are significantly smaller than the service you're comparing them to. That's an obvious and perhaps unhelpful definition, let's contrast it with ...
"Microservices" is[0] a tech industry fashion trend. It can be a real solution to a problem, too, but it's like how throwing out all your shit is the solution to depression now because a nice lady in a book said that you probably don't want all that stuff anyway. The solution is applied/suggested because it's trendy, not because it is necessarily the best fitting solution.
Like many buzzwords, 'microservice' is difficult to define. "You know it when you see it" is a euphemism for something devoid of meaning[1]: a null concept. This is a feature and not a bug. And where the term does have meaning, it's always relative -- so everyone can have microservices, and argue about who does.
[0] I do mean 'is', as opposed to 'are'
[1] it can also be the case that the speaker just doesn't know what they're talking about, and perhaps that they know it has meaning to others, social constructs, &c. To avoid spending the next three years working on this comment, I'm assuming that's not the case above.
[x] Conspiracy-theory rabbit-hole: buzzwords are like conspiracy theories in that they rely on vagueness or being undefinable. I guess my point is that concrete ideas aren't really suited to being buzzwords. Only the vague/relative/broad ones get selected (as in natural selection, not by the shady cabal of buzzword pickers), just like how only the best impossible contradictory stories tend to become popular conspiracy theories. ... actually, mostly I just thought "conspiracy-theory rabbit-hole" was a funny heading for a tangent about conspiracy theories.
Re: What Even Are Microservices?
#33In my experience, almost all the problems that microservices advertise solving can also be solved with a modular monolith plus some tooling to enforce certain rules (say, one module shouldn't be able to peek into another module's internals, bypassing an agreed-upon "clean" public interface; that alone solves most spaghetti-code problems)
There are two things monoliths can't easily offer:
* Using different frameworks, languages, etc. But in my experience, it's pretty rare for a team to use many programming languages at once. Usually, it's just a few highly performance-sensitive services that need to be written in another language (say, a proxy in Rust while the rest is in Python). For that, I prefer an architecture with one main monolith plus a few high-performance satellite services. No problem there.
* More optimized scaling in certain scenarios. Say I have a module that processes files and can use all available CPU. I might want to put it in a separate container on another node so that the processing doesn't destabilize the core web server. Technically, monoliths support this too, just run the monolith in a different mode (say, behind an `--image-process` flag of sorts), and you can schedule it on another node in the same way. The only downside is that it may use more RAM than necessary for the extra binaries or scripts that won't be used
What else am I missing?
Re: What Even Are Microservices?
#34Something people use to architect towards being the next Amazon, before they've even got their first 100 users. Also useful for CV padding. Genuinely useful method for abstraction, concern/dependency separation, scaling, and so forth, for teams & projects that genuinely need what they offer.
Or build core infrastructure right the first time, and not spend millions of dollars turd-polishing while your competition eats the market.
Davids talk makes some good arguments, but does not fully acknowledge low-maintenance infrastructure at scale. =3
"10 tips for failing at microservices" (David Schmitz)
Re: What Even Are Microservices?
#35> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about…
This is complete lack of experience on the authors part. No tracing, no observability, no knowledge of distributed systems design to allow them to see what they can clearly measure. Your take is the correct one. Microservices break up the monolith so that multiple teams can work on pieces of the solution/platform without stepping on each others toes. The rest of it is documentation/discovery.
Tracing and o11y are a poor sibling to static analysis.
> This is complete lack of experience on the authors part
Actually I'm going to turn the accusation back on yourself: if you think reasoning about a system's entire graph of behaviours from runtime traces is trivial, I don't believe you've worked on a truly complex system
The range of what a program can do is much larger than what a program does do in your two week Datadog aggregation window
Re: What Even Are Microservices?
#36This is basically Conway's Law in practice: microservices aren't created because of technical boundaries, but they emerge because organizations need team boundaries. https://en.wikipedia.org/wiki/Conway%27s_law
Microservices exist because of the limitations of a single human brain in being able to wrangle with that much logic at a time. It is perfectly conceivable that an alien species with different brain characteristics would draw their microservice boundaries at very different points, possibly varying by a whole order of magnitude in either direction. I don't agree that there are organizational causes even though that's…
Except microservices don't do that. You still have to wrangle other people's system parts.
Re: What Even Are Microservices?
#37This is what people always say but it's not really the only case, and it's not even a particularly good case. You could achieve the same organizational thing through modules, for example.
The real—and the one thing you can't replicate—is data isolation.
Of course there are other benefits, but it's data isolation is the differentiator of micro-services and other types of architecture.
Re: What Even Are Microservices?
#38I’ve been building a lot on cloudflare workers recently and I feel like microservice works pretty well there.
Sometimes you want to have some shared infra abstracted behind a single interface and a single auth model.
Having a service gives you that single isolated unit/abstraction.
In practice it’s always a scale. Some services will be bigger and some will naturally be split out.
I think also having the right server platform that makes it trivial to deploy/standup infra quickly makes this much easier.
Re: What Even Are Microservices?
#39> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about…
Microservices still have global concerns. Is someone actually using that endpoint or can you remove it? How will you know? Ask everyone?
How many HTTP calls are made during one user request and how long does it take? (This concern brought down one of the early microservice projects with a 10-minute page load time)
What are the race conditions? User removes billing info at the same moment as making a payment - what happens? Is the payment marked as successful but not actually billed?
Re: What Even Are Microservices?
#40In my experience, almost all the problems that microservices advertise solving can also be solved with a modular monolith plus some tooling to enforce certain rules (say, one module shouldn't be able to peek into another module's internals, bypassing an agreed-upon "clean" public interface; that alone solves most spaghetti-code problems) There are two things monoliths can't easily offer: * Using different frameworks,…
> But in my experience, it's pretty rare for a team to use many programming languages at once
Teams sure, but your whole org? Nothing wrong with all teams using same tools and language, nothing wrong with them choosing their poison. Of course your monolith can have multiple build systems.
But I think this is beside the main point of the article anyway, and it’s the part about how microservices help create boundaries that mirror organizational boundaries.