Earlier quoted context omitted.
Microservices is a newer term than SOA.
They are not the same thing! Microservices is a discount version of SOA with a new coat of paint.
Clearly. But it’s also SOA taken to the extreme!
The costs of microservices (2020)
261–270 of 410 posts
Re: The costs of microservices (2020)
#262> And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging. This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g…
> God forbid you find yourself with a need to rewrite one of these shitpiles. Actually, this is much easier with micro services as you have a clear interface you need to support and the code is not woven into the rest of the monolith like a French plat. The best code is the easiest to throw away and rewrite, because let's face it, the older the code is, the more hands it's been through, the worse it is, but more impo…
I disagree. The older the code is, the more hands it's been through, which generally means it's stronger, hardened code. Each `if` statement added to the method is an if statement to catch a specific bug or esoteric business requirement. If a rewrite happens, all that context is lost and the software is generally worse for it.
That being said, I agree that maintaining legacy systems is far from fun.
Re: The costs of microservices (2020)
#263Earlier quoted context omitted.
grug not experience large teams stepping on each other's domains and data models, locking in a given implementation and requiring large, organizational efforts to to get features out at the team level. Team velocity is empowered via microservices and controlling their own data stores. "We want to modernize how we access our FOO_TABLE for SCALE_REASONS by moving it to DynamoDB out of MySQL - unfortunately, 32 of our 5…
Found the author of CISCO / Java Spring documentation. I honestly expected people used passive-aggressive corpo-slang only for work / ironically. But this reads intentionally obfuscated. But, to answer to the substance: you for some reason assumed that whoever designed first solution was an idiot and whoever designed the second was, at least clairvoyant. The problem you describe isn't a result of inevitable design de…
I think I view the situation in a similar fashion as you. There's absolutely nothing preventing a well architected modular monolith from establishing domain/module-specific persistence that is accessible only through APIs and connectable only through the owning domain/module. To accomplish that requires a decent application designer/architect, and yes, it needs to be considered ahead of time, but it's 100% doable and scalable across teams if needed.
There are definitely reasons why a microservice architecture could make sense for an organization, but "we don't have good application engineers/architects" should not be one of them. Going to a distributed microservice model because your teams aren't good enough to manage a modular monolith sounds like a recipe for disaster.
Re: The costs of microservices (2020)
#264Earlier quoted context omitted.
"The last responsible moment (LRM) is the strategy of delaying a decision until the moment when the cost of not making the decision is greater than the cost of making it." Quoted from: https://www.oreilly.com/library/view/software-architects-han...
Still trying to unlearn that one. Turns out, most decisions are cheap to revert or backtrack on, while delaying them until Last Responsible Moment often ends in shooting past that moment.
I don't think you need to unlearn it, but update your cost function.
Re: The costs of microservices (2020)
#265Microservices don't cost as much if you deploy them everywhere so you get both vertical and horizontal scaling without lookup cost.
Of course then you need the same stack which allows multiple apps deployed everywhere.
Re: The costs of microservices (2020)
#266Similarly with frontend devs thinking a "modern web-app" can only be built with frontend frameworks/libs like React/Vue/Svelte, etc, lately I feel there's an idea floating around that "monolith" equals running that scary big black ball of tar as a single instance and therefore "it doesn't scale", which is insane. Another observation is the overall amount of code is much bigger and most of these services are ~20% busi…
While I agree with you that a lot of websites overuse javascript and frameworks. Can you tell me what else I'm supposed to use if I'm going to build a desktop class web app without it becoming a huge mess or I having to end up up inventing the same concepts already existing in these frameworks?
"desktop class web app" is a subset of "modern web-app". If you need frameworks, use them.
Re: The costs of microservices (2020)
#267Microservices are necessary and the best way to architect something new that is going to be used at scale. In my experience working with monolithic architecture with 20+ teams at a large Tech company, I have found it takes multiple years to convert to microservices. Rebuilding generally is possible in half as much and gives you the opportunity to hire good talent, motivate existing employees and use the latest tech. thoughts?
Re: The costs of microservices (2020)
#268Earlier quoted context omitted.
Absolutely. This is how we operated when we were at the peak of our tech showmanship phase. We had ~12 different services, all .NET 4.x the exact same way. This sounds like it could work, but then you start to wonder about how you'd get common code into those 12 services. Our answer at the time was nugets, but we operate in a sensitive domain with proprietary code, so public nuget services were a no go. So, we stood…
Can't you share them via shared libraries in .NET?
YMMV but I think you can only do that if you have a monorepo with the shared library and all the microservices
Re: The costs of microservices (2020)
#269Earlier quoted context omitted.
While I agree with you that a lot of websites overuse javascript and frameworks. Can you tell me what else I'm supposed to use if I'm going to build a desktop class web app without it becoming a huge mess or I having to end up up inventing the same concepts already existing in these frameworks?
"desktop class web app" is a subset of "modern web-app". If you need frameworks, use them.
The meaning behind these is pretty blurry between whats considered a website vs an app, it's a spectrum. I consider a web app something that has a similar UI experience to a desktop app, as the word "application" came derived from the desktop.
Re: The costs of microservices (2020)
#270> And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging. This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g…
I think this is a false dichotomy. Most places I've worked with microservices had 2 or 3 approved languages for this reason (and others) and exceptions could be made by leadership if a team could show they had no other options. Microservices doesn't need to mean it's the wild west and every team can act without considering the larger org. There can and should be rules to keep a certain level of consistency across tea…
> Most places I've worked with microservices had 2 or 3 approved languages for this reason (and others) and exceptions could be made by leadership if a team could show they had no other options.
This works well if you have knowledge redundancy in your organization, i.e., multiple teams that are experienced in each programming language. This way, if one or more developers experienced in language 'A' quit, you can easily replace them by rearranging developers from other teams.
In small companies, this flexibility of allowing multiple languages can result in a situation in which developers moving to other jobs or companies will leave a significant gap that can only be filled with recruiting (then onboarding), which takes much more time and will significantly impact the product development plan.
More often than not, the choice between Microservices and Monoliths is more of a business decision than a technical one to make.