Earlier quoted context omitted.
Having worked in both, I'll never work on a true monolith again.
Why?
Because almost nobody has ever worked on a true monolith. It’s just “services abstractions people are comfortable with” and “everything else”.
Microservices are hard
131–140 of 356 posts
Re: Microservices are hard
#132Earlier quoted context omitted.
Yeah, it's crazy the hate microservices get. I happen to work on a product that needs to scale to handle millions of transactions distributed all over the world and the cloud microservice system is just flawless for this purpose. Is it harder to debug than a monolith? Sure. You need a team that has a good understanding about distributed systems (most coworkers have degrees and the ones without are really good at self…
I feel the same way about go-to statements. Crazy hate. Harder to debug, sure, but they make things so much easier.
[dead]
Re: Microservices are hard
#133Earlier quoted context omitted.
> Any time you lean on code in a random GitHub repository, where you never speak to the author and just use the API you're given, you're doing microservices. So a library is a microservice now?
In some sense it is. It has an interface that your program communicate through. It might be loaded separately in memory (or even shared between several programs). That’s kinda of a local microservice.
Also from an organizational point of view: it ceases to be maintained, or the developer disappears, as an independent unit.
Re: Microservices are hard
#134No, they aren't. The entire point of the big ball of mud is that there are no meaningful divisions in the code. Everything uses everything willy-nilly, at the smallest possible level of abstraction. There is, metaphorically if not always entirely literally, not a single line of code in the system that you can change without fear of bringing something else down that you may not have even known they existed. Microservi…
> It may be the sloppiest, crappiest definition every, with dynamic types
Funny you said that since a microservice API is always dynamically typed and its usage cannot be checked by compiler. And the more microservices you use the more dynamically typed the whole project gets overall.
While you can opt into a free for all everything importing everything, all languages do also support creating modules which define APIs for consumer and maintain compile time type checking.
Re: Microservices are hard
#135Microservices is a team organization technique, whereby disparate teams only communicate by well defined APIs. Any technology choices that come out of that are merely the result of Conway's Law. Any time you lean on code in a random GitHub repository, where you never speak to the author and just use the API you're given, you're doing microservices. This works well enough so long as the product does what you need of i…
No. That's not what microservices means. You're intentionally equating all services to microservices, which is not the case. This substitution is what is commonly known as a Strawman argument. You misrepresented an argument, to discredit it easier.
> That's not what microservices means. You're intentionally equating all services to microservices, which is not the case.
Eventually everyone provides a service to someone, I guess, but there is a clear division between those who serve end users and those who serve the servers. The service that places your food down on the table at the restaurant is not thought of in the same was as those who get to the food to the restaurant. The latter camp is often known as a supplier, but we in tech call them a microservice instead. There is no suggestion that all services are microservices.
Re: Microservices are hard
#136Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer. Why call a function when you can wrap that function in an entire application and call it via API? Why have a single database when we can silo our data across 200 mini databases? Why have a single repo when we can have 200 tiny repos?
I've seen quite a few people use the argument that their system wouldn't cope otherwise when they reach the size of Google. If you are one of those, then I have news for you. 1. You are not going to reach the size of Google. Certainly not if you are engineering for it in your 2 person startup. But in case you do, see number 2. 2. Reaching Google scale means you'll have funding to hire good people to scale your softwa…
If you plan your architecture carefully and modularize a lot, there is very little that will prevent you from branching out modules of a monolith into microservices when the time comes.
If you produce spaghetti code with tightly coupled components, well, then you are going to have a problem.
Re: Microservices are hard
#137Earlier quoted context omitted.
Weird flex to claim not to have learned anything new since the nineties though.
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…
If you don't have money for testing I hope you're saving up to afford to fix it twice.
Re: Microservices are hard
#138Earlier quoted context omitted.
Weird flex to claim not to have learned anything new since the nineties though.
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 simple concepts in a consistent way that makes scaling a breeze. Soin the long run we benefit from the hype, although I can hardly understand folks running k8s for a 3-container setup.
Re: Microservices are hard
#139Earlier quoted context omitted.
This happens a lot. Otoh, sometimes you come across cases where you wonder if you accidentally landed on a different planet. Mid sized project, 500 microservices, 800 repositories...
And sometimes when you’re driving you’ll pass a car upside down in a ditch and think ‘glad I’m not that guy’. But you know that can still happen to you, right? Even if you’re careful? The sales team promised a massive contract; the system design has to be able to hit x TPS to make it; we need to pull out the stops and build to scale for that and to allow for all this future expandability. Six months later, that sales…
> And sometimes when you’re driving you’ll pass a car upside down in a ditch and think ‘glad I’m not that guy’.
No, I'd stop and see if I can help.
Re: Microservices are hard
#140Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer. Why call a function when you can wrap that function in an entire application and call it via API? Why have a single database when we can silo our data across 200 mini databases? Why have a single repo when we can have 200 tiny repos?
I've seen quite a few people use the argument that their system wouldn't cope otherwise when they reach the size of Google. If you are one of those, then I have news for you. 1. You are not going to reach the size of Google. Certainly not if you are engineering for it in your 2 person startup. But in case you do, see number 2. 2. Reaching Google scale means you'll have funding to hire good people to scale your softwa…
[deleted]