I never get this desire for micro services. You IDE can help if there are 500 functions, but nothing would help you if you have 500 micro services. Almost no one fully understands such a system. Is is hard to argue who parts of code are unused. And large scale refactoring is impossible.
The upside seems to be some mythical infinite scalability which will collapse under such positive feedback loops.
The concepts here apply to any client-server networking setup. Monoliths could still have web clients, native apps, IOT sensors, third party APIs, databases, etc.
>The upside seems to be some mythical infinite scalability which will collapse under such positive feedback loops.
Unless I misunderstand something here, they say pretty early in the article that they didn't have autoscaling configured for the service in question and there is no indication they scaled up the number of replicas manually after the downtime to account for the accumulated backlog of requests. So, in my mind, of course there can be no infinite, or really any, scalability if the service isn't allowed to scale...
The point of microservices is not technical, it's so that the deployment- and repository ownership structure matches your organization structure, and that clear lines are drawn between responsibilities.
its also easier to find devs that have the skills to create and maintain thin services than a large complicated monolith, despite the difficulties found when having to debug a constellation of microservices during a crisis.
For the folks who downvoted this - why? I hire developers and this is the absolute truth of the matter.
You can get away with hiring devs able to only debug their little micro empire so long as you can retain some super senior rockstar level folks able to see the big picture when it inevitably breaks down in production under load. These skills are becoming rarer by the day, when they used to be nearly table stakes for a “senior” dev.
Microservices have their place, but many times you can see that it’s simply developers saying “not my problem” to the actual hard business case things.
I think the dream is that you can reason locally. I'm not convinced that it actually help any, but the dream is that having everything as services, complete with external boundaries and enforced constraints, you're able to more accurately reason about the orchestration of services. It's hard to reason about your order flow if half if it depends on some implicit procedure that's part of your shopping cart.
The business I'm part of isn't really after "scalable" technology, so that might color my opinion, but a lot of the arguments for microservices I hear from my colleagues are actually benefits of modular programs. Those two have just become synonyms in their minds.
> […] the dream is that having everything as services, […], you're able to more accurately reason about the orchestration of services.
Well.. I mean that’s an entirely circular point. Maybe you mean something else? That you can individually deploy and roll back different functionality that belong to a team? There’s some appeal for operations yeah.
> but a lot of the arguments for microservices I hear from my colleagues are actually benefits of modular programs
Yes I mean from a development perspective a library call is far, far superior to an http call. It is much more performant and orders of magnitude easier to reason about since the caller and callee are running the same version of the code. That means that breaking changes is a refactor and single commit, whereas with a service boundary you need a whole migration.
You can’t avoid services altogether, like say external services like a payment portal by a completely different company. But to deliberately create more of these expensive boundaries for no reason, within the same small org or team, is madness, imo.
JavaScript is very fast if you want/need it to be. Emscripten/asm.js approach is in the same category as native for example. Your simple code won't be too fast, but not all code needs to be.
Mostly because Linus won't accept anything other than C on his beloved kernel.
Sun had experimental support for Java drivers on Solaris, Android has support for writing drivers in Java, Android Things only allowed for Java written drivers.
Kotlin’s decision to make every exception runtime is the main reason I don’t use Kotlin. It’s especially baffling that they realized the issue with implicit nullability and got rid of it (though not with Java methods, which opens another can of worms), then went and intoduced implicit “exceptionality”.
The correct way to deal with Java’s checked exceptions would have been introducing a Result type, or, preferably, type algebra, like in TypeScript, so something like:
fun openFile(fileName: String): File | FileNotFoundException {…}
Then you could handle it similarly to null:
val content: String | FileNotFoundException = openFile(“myfile.txt”).?read()
…then you have to do a check before you use content as a String…
or
val content: String = openFile(“myfile.txt”)?.read() ?: “File not found”
(There could also be other possible ways of handling the exception, like return on exception, jump to a handling block, and so on.)
In fact, null should be treated as an exceptional value the same way all exceptions should be.
The ergonomics of checked exceptions may be debatable but compared to golangs explicit error handling at essentially each function call is definitely worse.
Yeah, I've got a lot of Java experience and a wee bit of Go language experience and I agree with you. I like Go in almost every way except for it's error handling. It's just wrong to have to check every goddam function one by one
I guess that's the reason why most Java programs I use cannot do proper user-facing error messages. Because it is so easy to just ignore error handling. The exception will be caught by the top-level, right? This is how almost every Java cli tool prints a stacktrace on even most trivial user errors like file not found.
Having to deal with errors and forcing the developer to do proper error handling is a good thing.
I don't mind Go's errors.
I do mind the complete lack of hierarchy in that.
Java's exceptions are hierarchical.
I can create an exception that specializes from `IOException` and that I feel is really powerful.
Go added this half-baked and much later.
So, most FOSS libraries don't support it yet.
Both Java checked and unchecked exceptions are inferior to signaling errors by return values like Go/Rust/Haskell do.
Exceptions are not composable, cannot be generic, and it is not visible in the source code which lines can throw, so every line is a potential branching point.
This isn't even a joke. Technology in software development has been progressing horizontally. Nothing is improving but abstractions and patterns are changing constantly.
Engineers need something to talk about in their OKRs. One strategy is to refactor things into microservices.
> Scale is measured in millions of instances: On 2022/12/21, the microservice topology contained 18,500 active services and over 12 million service instances.
They do go on to say that microservice as a concept is poorly defined. Are you suggesting that they mostly have 18500 of what we’d normally consider monoliths?
I thought Google at least was a bunch of micro services which is why they needed something like Borg and eventually open sourced a version of it called K8s.
Total BS.
Google has tons of services.
They are lots of them but they don't have a `fileRead` service and `fileWrite` service. Rather, they have a `gfs` service that can read/write/modify etc. everything related to files.
I’m not sure what’s your point? That JS shouldn’t have this library because other languages did it first a while ago? Should concepts only be implemented in one language because after that it’s rediscovering knowledge rather than being inventive?
I also really dislike the undertone of « other languages are better », which is naive at best.
This. Fixed-point decimal isn't even implemented in standard Rust– which I would deem a very mature language, because they want to keep the standard library quite small. If you want to use fixed-point decimal, there's a crate for that;
Rust standard library is very limited and IMO a huge downside of the language, especially as the third party libraries to replace it are not up to par and also often the community has not agreed on one single standard so writing higher level libraries forces you to pick one side of the ecosystem
I'm curious where you got this information from? How do you know the third-party libraries are not up to par? Is this personal or second-hand experience? Is it an assumption?
The upside seems to be some mythical infinite scalability which will collapse under such positive feedback loops.
reply