Orchestral manoeuvres in the Docker: A noob's guide to microservices Given the hype around microservices, it's tempting to question whether the task of managing microservices has also been oversold. Isn't it just just like managing a traditional piece of software? Well, no. Here's why. In the case of our trusted monolithic applications, you'll more often than not find yourself dealing with a …
All that sounds lovely. But do we know of any large commercial customers using microservices "in anger"?
I just get the feeling that changing the mindset of large customer support services is like turning an oil tanker - and we have only just sent the "hard about" command.
But I could be wrong (and I'ld love to be proved wrong),
Alan
Not really a new way of thinking about how to develop applications. Its how I was taught to do distributed systems many years ago at uni. It's how I have been trying to get developers in our company to try and develop our internal software for years to but to no avail because its too much work. Now docker is the in thing, its not too much work anymore.
"Each microservice is isolated and consists of a single unit of functionality. This means a change to a service is a very small deployment and greatly reduces what can go wrong."
...but you do get microservices providing data to other microservices. When those go wrong the result is just as catastrophic and sometimes harder to debug and recover from than in monolithic applications.
That's not a reason to avoid microservices of course, its a reason to approach designing distributed applications differently because microservices help improve uptime and more importantly the golden 'time to market' for changes that your business sponsors want.
So this can auto scale applications so things like cascading failures across micro services due to massive inter dependencies, horribly written SQL that can take out database servers/clusters easily(and hey the developers don't even know what SQL is being used because they abstracted it away), locking within applications due to external dependencies, and removes the need for performance testing as well because "auto scale", right?
right.
bad code is still bad code, micro services or "monolithic". Micro services can make the effects of bad code even worse than monolithic because developers end up cutting more and more corners for their services to get the data that they need.
Meanwhile you've massively increased your failure potential by having a half dozen more services, all of which are critical points of failure(with maybe a dozen or more others that are not critical), before if one service went down your app went down, now you have six times the probability of your app going down because you have six times the failure points, any one of which takes the app down.
"Meanwhile you've massively increased your failure potential by having a half dozen more services, all of which are critical points of failure"
Depends on how you designed you services. You have 2 modes of failure, provide no service or provide stale data. The latter should really be the only failure mode a microservice should do unless it's crucial to have accurate info. Each service should have a cache of required data, the services should be event driven and be notified by each service it subscribes to for updates on info. This will remove hard dependencies. There are multiple was to implement this, it has also been taught years ago, well was for me at the Uni. i went to, but doesn't appear to be done as the easy route isn't to do this. It means you have to take in to account that info may have been incorrect and what you have to do about it.
This post has been deleted by its author
"Supports the main cloud providers such as AWS and GCP" ... Gee, what about Azure or even IBM as they both have offerings as well as many other "non-major" cloud providers, plus there are on-prem solutions. A little, and I mean a little, research goes a long way past personal preferences, so, here is a doc page that gives the real info on choices for running Kubernetes .. https://kubernetes.io/docs/setup/pick-right-solution/
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
