If you can't get your monolith right you probably won't get your microservices right. Microservices do come with additional overhead in terms of infrastructure, integrations, and so on. There's a concept of microservices readiness (e.g. https://learn.microsoft.com/en-us/azure/architecture/guide/t...). Many organisations aren't ready to embrace microservices, and if they get into microservices before they're ready, then it's a lot of pain. There's also this misconception that microservices must be nano-services. But that's not a problem with microservices architecture, it's a problem of using microservices anti-patterns. As with everything in technology, there's no universally unique solution to all problems - everything's context-specific.
Microservices are hard
341–350 of 356 posts
Re: Microservices are hard
#342Earlier quoted context omitted.
Although true to some extent, this is also a tooling issue. We use OpenAPI and generate clients. Strictly speaking the interoperability layer doesn't know the truth on the other side, but when generated correctly, the developer doesn't need to worry about it.
When you change function signature it doesn't compile until you fix all the call sites. Maybe after you see all the broken call sites you think that's too much work maybe there is some other way to do what I want. When you change anything about an endpoint, it compiles just fine no matter what clients there are or what they are doing. You proceed with the change without worry. Yes, you can have some self-discipline t…
If you use semantic versioning correctly, then you shouldn't need to worry about apiimplementation inconsistency. Or rather, when you need to, you know which parts you have to deal with.
I don't think there is a way to avoid this?
Re: Microservices are hard
#343Earlier quoted context omitted.
Don't you find it strange that YOU live in a world where everyone else but YOU thinks that everyone else around them is over engineering or under engineering things? You're not the guy who thinks everyone else is a maniac and is driving too fast or too slow. You're the guy who thinks everyone but you is under this delusion of thinking that everyone else is a maniac and you think you are an exception to the delusion b…
That's... a bit more metacognition than maybe my snarky reply warrants. I didn't claim to be the only person who is smart enough to spot that a lot of online architectural opinion-writers structure their opinion-pieces as strawman-takedowns of 'popular wisdom', and that this is another in that genre which appears to add nothing particularly further to the discussion. I never claimed that there is no such thing as obj…
Well that may be what you intended to say, but much of what you put, well pretty much all of what you put, is simply an attack on the poster's character. What I read from your post boils down to "the poster is clearly an elitist who thinks he is right and everyone else is wrong, so his opinion isn't worthy of recognition and is wrong".
Character attacks on the internet are self defeating and foolish in many ways. There are little to no stakes for the attacker if wrong (undermines the value of the attack). The attacker is being hostile to someone completely, or mostly, unknown/unfamiliar (foolish). The attack does nothing to address the actual argument/points being made (waste of time for readers).
Rather than oppose the messenger, perhaps lead with opposing the message itself. It is far less hostile and is more productive. You will get better at countering the argument/points if you actively practice doing it, and it is better for everyone involved (more focus on the issue rather than the winning a battle against someone "bad"). You also might spare yourself counter takedowns like you got here, this one being particularly spicy.
The article linked doesn't even seem to say that microservices are always bad. It simply says they are difficult to do, and the author sees them as over engineering. Overall a pretty common opinion.
Re: Microservices are hard
#344I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…
> enough pieces so that; 1. your engineers … are not afraid of doing changes. I don’t really understand that argument, and I don’t really feel safer making a change to a microservice inside a large system, as opposed to making a change to a monolith — the consequences of a mistake are equal in both cases (although harder to observe/debug in a microservice architecture) — am I missing something?
Thinking through the inter-service interface is costlier and more transparent than calling the function in the same monolyth. That said, interfaces between services are inherently better than function calls.
Also, making mistake in microservice is more easily isolated, fixed and redeployed.
Other than that, microservices are business entities, rather than just tech entities. They can be scoped, evaluated and managed on business level. After all, you can ask another team rewrite the specific microservice. You can't do that with monolyth.
And the problem wouldn't be just buried in tech details and opinions.
Re: Microservices are hard
#345The idea that an org that has hard time maintaining a properly structured monolith, will solve it's problems by shifting to building a distributed system was always strange to me.
Amazing way to put it actually. You summarized it in a great way.
Re: Microservices are hard
#346The idea that an org that has hard time maintaining a properly structured monolith, will solve it's problems by shifting to building a distributed system was always strange to me.
The distributed system has benefits that the monolith doesn't, like scalability and resilience to failures though it opens doors to new kinds of failures.
Monoliths can scale. My monolith doesn't crash if one endpoint is throwing errors :)
Re: Microservices are hard
#347Use the best tool for the job. It's stupid to think of monoliths vs microservices. You can use both if the problem requires it. For example I'm currently working on an audio hosting service. The main app is a monolith where 90% of the code resides but there are a couple of ancillary services. Audio encoding (which is heavily CPU bound) is a serverless microservice that can scale up and down as needed. Users don't upl…
I think your position is basically the same position that most people that advocate for monoliths (which btw is a bit of a strawman created by microservice architecture advocates in the first place) hold. People are objecting to service/network boundaries as a default domain decomposition tool and arguing that it should be used instead when there are clear and immediate technical advantages to do so.
Yeah. Agreed. For example I need to ocr things sometimes. I literally have a process running an ocr server. It's basically a microservice.
Re: Microservices are hard
#348Earlier quoted context omitted.
Monoliths can also scale horizontally and be restarted automatically when they fail. No need for microservices for that.
> Monoliths can also scale horizontally At a (potentially much) bigger cost.
Overhead is way worse with microservices once you talk about network latency, database cost, infra for logging and monitoring, labor to manage that, and developer cost. Way, way, way, more than spinning up ten more identical webapps.
Re: Microservices are hard
#349Earlier quoted context omitted.
What I learned since the 90ies, is that software engineers don't learn from previous years... let alone from previous decades. This "microservices are better" argument was made in the 90ies and top dog is still Linux kernel (the one that was on the monolith side of that debate). So yeah - microservice advocates haven't learned anything since the 90ies, or from the SOA era, etc... (but I suspect they were in secondary…
While I agree with you, the good part is that each generation is (slightly or significantly) better than the previous one. I remember using static generation in the 90s but the tools we have now are more powerful. Kubernetes is a great piece of software: it is well-designed, easy to work with (at least the managed versions that most companies use; administering the cluster is another thing), it applies a set of simpl…
K8s isn't so bad if you use a service like azure. I wouldn't run my own cluster. But k8s does make your life easier. It's basically supervisord on steroids with regards to features. Tho networking and storage is a nasty thing.
Re: Microservices are hard
#350Earlier quoted context omitted.
You should have a well curated DB regardless of whether one or many domain specific services sit in front of it. That is what would enable you to break a monolith up. Good code and architecture is the result of discipline. Your data is your most valuable asset. What you're describing is a mess. You mentioned RPC's. Your service interface has nothing to do with the data organization. But if you think microservices is…
> You mentioned RPC's. Your service interface has nothing to do with the data organization. I find data organization to be a direct consequence of service interface. If two things aren't talking over RPCs or pubsub, they're talking through the database. It's not just my org. Pretty common for monoliths to end up with an obscene reliance on a single DB and start looking for a huge machine to support it. There isn't a…
> I find data organization to be a direct consequence of service interface.
Then, you will not like microservices. Microservices make it harder, not easier, to organize data.
You have to worry about problems such as eventual consistency, and figure out how to join data across multiple data sources.
It compounds the problem significantly, and the only thing it gives you is that it forces you to silo data. That can be a good thing, but it doesn't solve the data organization problem.