You must log in or register to comment.
Dude just start with a monolith and part it out as you scale. Of course microservices are a waste of time if you build them right off the bat.
It’s just not worth it until your monolith reaches a certain size and complexity. Micro services always require more maintenance, devops, tooling, artifact registries, version syncing, etc. Monoliths eventually reach a point where they are so complicated that it becomes worth it to split it up and are worth the extra overhead of micro services, but that takes a while to get there, and a company will be pretty successful by the time they reach that scale.
The main reason monoliths get a bad rap is because a lot of those projects are just poorly structured and designed. Following the micro service pattern doesn’t guarantee a cleaner project across the entire stack and IMO a poorly designed micro service architecture is harder to maintain than a poorly designed monolith because you have wildly out of sync projects that are all implemented slightly differently making bugs harder to find and fix and deployments harder to coordinate.
I still have to find a name for this disease, but it’s somewhat like “you’re neither Google nor Netflix”.
Everything has to be Scalable™ even if a raspberry pi could serve 200 times your highest load.
I’m currently involved with a “micro service system”, that has very clear, legal requirements, so we know exactly, how much load to expect. At most, a few thousand users, never more than 100 working at the same time on very simple business objects. Complex business logic, but technically almost trivial. But we have to use a super distributed architecture for scalability…
I’m guessing you already got an answer for that though when you asked about it.
Could be either “oh you’re right let’s not do that”, or “because we want to design for horizontal scalability rather than vertical in case the demand grows later”, or “the client has requested and it’s paying for this feature” and so on.
It’s because they think it’s what you’re doing for a large project. Simple as that. There’s no future demand, the client doesn’t care, and I’m not right because they said so.
Micro-services and monoliths sit at opposite extremes though. There are other takes in-between, like multiple services (not micro) for example.
What the fuck is a “lamba server less”, and why is my cloud bill so fucked? 🚒 🔥 💰 💸
😵😢😥🤯
I was looking up lambda functions for rust because i needed it for something and didn’t know how, what, etc. But searching anything lambda now only shows results for fucking amazon lambda bullshit! Really pisses me off… its fucked 😠
“You dont have to care about infrastructure…” is the bigest lie of those microservice hosting providers.
redundancy, rolling updates or byzantine fault tolerance in a monolith > naïve assumptions that one part of your system going down won’t mess up it’s overall usability by and large just because you’ve used microservices
Micro services alone aren’t enough. You have to have proper observability and automation to be able to gracefully handle the loss of some functionality. Microservice architecture isn’t a silver bullet, but one piece of the puzzle to reliable highly available applications that can handle faults well
As an operator, this who thread reads like a bunch of devs who don’t understand networking and refuse to learn.
Sure, for smaller applications or small dev teams it doesn’t make sense. But for so many other things it does.
The problem is that all projects start small, and frankly most of them die small. Aiming for microservices architecture right away is a surefire way to get the project killed before anyone would benefit off of the microservices.
I always lump microservices architecture as premature optimization, one that should be used when you’re maxed out of resources or everything is too spaghetti.
I love the idea. And I even pitched it for a specific project. But I had to eat humble pie when the devops nerds threw more servers at the problem and it worked better than I expected.
Most software developers have no concept of real world limitations and issues like tolerances, failure, probability, latency, hysteresis, ramp-up etc. because they’re not engineers.
Normally they’d be expected to at least account for software-specific aspects like ACID or CAP or some vague awareness of the fact that when you’re dealing with multiple systems the data may not always arrive as you expect it, when you expect it. But even that is a crapshoot.
It’s a tool like any other, appropriate under some circumstances and inappropriate in others.
Blindly rejecting it without considering whether it’s appropriate in the context is honestly just as bad as choosing it without considering whether it’s appropriate in the context, fwiw.
One of our customers recently had tasked us with building a microservices thing. And I already thought that was kind of bullshit, because they had only vague plans for actually scaling it, but you know, let’s just start the project, figure out what the requirements really are and then recommend a more fitting architecture.
Well, that was 3 months ago. We were working on it with 2 people. Then at the end of last month, they suddenly asked us to “pause” work, because their budget situation was dire (I assume, they had to re-allocate budget to other things).
And like, fair enough, they’re free to waste their money as they want. But just why would you start a microservice project, if you can’t even secure funding for it for more than a few months?
Because some marketing asshole told them that they better be prepared to scale to a bazillion users.
In this case, the colleague who had talked to the customers told me, they wanted microservices, because they’d have different target systems which would need differing behavior in places.
So, I’m guessing, what they really needed is:
- a configuration file,
- maybe a plugin mechanism, and
- a software engineer to look at it and tell them the behavior is actually quite similar.
But why? Microservices do have some good advantages in some scenarios
Problem is that companies are using them for all scenarios. It’s often their entire tech stack now, with kubernetes.
It’s similar to the object oriented hype that came before it, where developers had to write all their programs in a way so they could be extended and prepared for any future changes.
Everything became complex and difficult to work with. And almost none of those programs were ever extended in any significant way where object oriented design made it easier. On the contrary, it made it far more difficult to understand the program since you had to know which method was called in which object due to polymorphism when you looked at the code. You had to jump around like crazy to see what code was actually running.
Now with kubernetes, it’s all about making the programs easier to scale and easier to develop for the developers, but it shifts the complexity to the infrastructure needed to support the networking requirements.
All these programs now need to talk over the network instead of simply communicating in the same process. And with that you have to think about failure scenarios, out of order communication, missing messages, separate databases and data storage for different services etc.
If object oriented design is fundamentally about components sending messages to each other, then microservices are a different route to OO design. If people are bad at OO design, then they’re likely bad at designing microservices, as well. The two aren’t so separate.
All these programs now need to talk over the network instead of simply communicating in the same process.
This is where things go really wrong. Separating components over the network can be useful, but needs careful consideration. The end result can easily be noticeably slower than the original, and I’m surprised anybody thought otherwise.
It’s absolutely slower. There is no way to make a network request faster than a function call. It’s slower by probably thousands of times.
There is no way to make a network request faster than a function call.
Apologies in advance if this it too pedantic, but this isn’t necessarily true. If you’re talking about an operation call that takes ~seconds to run, then the network overhead is negligible. And if you need specialized hardware for it, then it definitely could be delegate it out to a separate machine over the network. Examples could include requiring a GPU, more RAM, or even a faster CPU if your main application is running on more power-efficient CPUs.
I’m not saying that this is true in every case - they are definitely niche cases. But I definitely wouldn’t say that network requests are never faster than local function calls.
Well put. And this is a generic pattern; for example, GPUs are only faster than CPUs if the cost of preparing the GPU and retrieving the result is faster than directly evaluating the algorithm on the CPU. This also applies to main memory! Anything outside of the CPU can incur a latency/throughput/scaling tradeoff.
You can have the best tool in the world and still find people just hitting their own face with it.
I don’t think people have a choice. If you join a company where they use kubernetes, you have to use that technology for everything. You can’t escape the complexity even if you just want to make a simple program. It still needs to run in kubernetes.
if you just want to make a simple program. It still needs to run in kubernetes.
“hello OPS-team. Here is my simple program. Have fun running it on your kubernetes”
Who at what company is having the conversation “let’s do (generic pattern)” without facing some kind of problem or inherent design need that can be solved by (generic pattern). Do these companies need software developers or did they just notice that all of the other companies have them? Surely some sort of inherent needs are driving their software.
Edited to make the generic pattern clearer
- Cloud providers have financial incentive to push microservice architectures
- Cloud providers give corporate consultants statistics like “microservice architectures are proven to be X% more likely to succeed than monolithic architectures”
- Cloud providers offer subscription-based tools and seminars to help companies transition to microservice architectures
- Companies invest in these tools and seminars and mandate that all new projects adopt microservice architectures
This is how it went down with Agile at my company 10 years ago, and some process certifications and database technologies before that. Based on what I’m hearing from upper management microservice are probably next.
