Live data from Hacker News

The costs of microservices (2020)

robertovitillo.com

301–310 of 410 posts

Re: The costs of microservices (2020)

#301
post #76

Earlier quoted context omitted.

Because of dependency issues like he mentioned. If I am using Library A which depends on version 1 of Library C and I need to start using Library B which depends on version 2 of Library C then I have a clear problem because most popular programming languages don't support referencing multiple different versions of the same library.

OSGi and Java Modules would like a word. Too few developers use the facilities available for that kind of in-process isolation, even when it is possible. (Don't tell me Java isn't popular... It may be the new COBOL, but it's still mainstream.)

> OSGi and Java Modules would like a word.

OSGi is the one that's deprecated and Java Modules is the one that can't actually provide that functionality yet, right? Or is it the other way round? Either way you get the point.

Re: The costs of microservices (2020)

#302
As a contractor, having worked with a lot of teams, I get the feeling that the kubernetes and microservices hype a few years ago resulted in a lot of unnecessary refactors. It can make sense, of course, but often doesn't, and running a monolith on k8s is perfectly fine.

Re: The costs of microservices (2020)

#303

Earlier quoted context omitted.

If the monolithic application is written in a language with sufficient encapsulation and good tooling around multi-module projects, then you can indeed have well known and encapsulated interfaces within the monolith. Within the monolith itself you can create a DAG of enforced interfaces and dependencies that is logically identical to a set of services from different codebases. There are well known design issues in mo…

With microservices, you can also version them independently. In a monolith you can't roll back "a part" of the app to the latest version if you pushed multiple unrelated features at once.

You can do the same with the approach I described. If you set up the modular DAG as I mentioned above, you can now set up service boundaries between the leaves of the DAG. E.g. parts of the code call other parts of the code as a service. You then version and deploy the same codebase separately.

Say you have Libraries A, B, and C, where B and C depend on A and not one another. You can have B call into C via a service, just as you would in a microservice. Now B and C can be versioned and deployed independency. You can also deploy updates to Library A incrementally, tying it to the B and C deployments.

If you are literally pushing different features that are in fact unrelated, you don't even need to worry about B calling into C, you can just partition your app into different modules, deploy them separately, and use a load balancer with routing rules to arbitrate between the deployments.

I like having this type of environment because you can make fairly quick and easily-resersible decisions about whether or not different parts of the codebase are deployed differently: sometimes it's compute and hardware requirements, sometimes it's because you want parts to be stable and other parts more experimental and volatile.

The microservice argument isn't addressing this type of deployment scenario: it's suggesting a shared-nothing or shared-little architecture across services.

Re: The costs of microservices (2020)

#304

Earlier quoted context omitted.

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.

Interesting term and I am curious to learn a few examples on overshooting here! My experience is that the new data available when postponing decisions can be very very valuable.

We're moving out of business context and to more general one, as I have more experience there - I learned the idea of postponing decisions from software design, and mistakenly started to apply it to my life in general :).

It's absolutely true that postponing a decision lets you take advantage of more data and experience. But making a decision now also generates new data - and often does it better and faster: you're directly observing how your choice plays out in the real world. For cheaply reversible decisions it means that, when things go bad, you can go back and make a new decision, this time informed by knowledge of what went wrong with your previous choice. If you squint, it almost looks like time travel :).

Not every decision is going to be like that, but e.g. in software design, I would often delay deciding between several possible approaches to seek out more information (and/or wait for it to come from customer side), only to later realize that in that time, I could've prototyped most or all of the options, or I could've picked one and made progress and undo it fast when more information came - and that either of those two approaches would've let me to gain the missing data faster, while also keeping forward momentum.

There's a reason many programmers (myself included) need to repeatedly hear the mantra that goes: "make it work, then make it right, then make it fast". In my case, postponing decisions is often a kind of analysis paralysis, and I'm slowly learning that in many cases, it's better to just pick any option, "make it work" in the dumbest, most straightforward way possible, and then reevaluate.

But as I said, I am learning this slowly. My mind knows better, but my heart still wants to delay by default :).

Re: The costs of microservices (2020)

#305

> 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…

> Wouldn't it be a hell of a lot easier if it was all in one place where each commit is globally consistent? I always find this sentence to be a bit of a laugh. It's so commonly said (by either group of people with a dog in this fight) but seemingly so uncommonly thought of from the other group's perspective. People that prefer microservices say it's easier to change/rewrite code in a microservice because you have a…

If an organization can't figure out how to factor out clearly-defined contracts within a single codebase and maintain that over time, adding a network hop and multiple codebases into that will not make it any easier.

Re: The costs of microservices (2020)

#306

Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug https://grugbrain.dev/#grug-on-microservices

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…

Or how about "we want to update a 3rd party library due to a critical security issue, but we can't because that library is used in 500 different parts of the code and no way in hell can we stop development across the entire org for multiple weeks".

With microservices, you deploy the updates to public facing services first, write any learnings down, pass it along to the next most vulnerable tier.

Heck on multiple occasions I've been part of projects where just updating the build system for a monolithic codebase was a year+ long effort involving dozens of engineers trying to work around commits from everyone else.

Compare this to a microservice model where you just declare all new services get the new build tools. If the new tools come with a large enough carrot (e.g. new version of typescript) teams may very well update their own build tooling to the latest stuff without anyone even asking them to!

Re: The costs of microservices (2020)

#307

> 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…

[deleted]

Re: The costs of microservices (2020)

#308

Earlier quoted context omitted.

You have no idea what my attitude towards code-review is.

Well, partly that was a mistaken impression because I thought that your comment was also from vrosas. But I think there's enough in there to assess your attitude toward code-review at least a _bit_: > They have 12 people and no customers, they can almost certainly adopt a very aggressive developer cycle that optimizes almost exclusively for happy-path velocity. You'd never do that at 50+ engineers with customers but…

[deleted]

Re: The costs of microservices (2020)

#309

Earlier quoted context omitted.

Without getting tied up in the whole "every language except assembly, Python and possibly JavaScript already solved this problem by forcing people to adhere to module-level APIs" argument, I think the crux of the issue is that the article just defines microservice architecture as any architecture consisting of multiple services, and explicitly states "there doesn’t have to be anything micro about the services". Which…

I think we should start calling this Pendulum Blindness. We just go from 'one' to 'too many' as equally unworkable solutions to all of our problems, and each side (and each person currently subscribed to that 'side') knows the other side is wrong. The assumption is that this means their side is right instead of reality, which is nobody is right. The moderates are right, but their answers are wiggly and they're too bu…

I've been looking for a concise soundbite (ironically) for this exact issue and Pendulum Blindness definitely fits what I've been trying to summarize.

Going to definitely yoink it for next time I have this discussion. It applies to so many things!

Re: The costs of microservices (2020)

#310

Earlier quoted context omitted.

Not so much a ball of yarn but more like the cabling coming out of a network cabinet. It can be bad and a big mess if you let it, but most professionals can organize things in such a way that maintenance isn’t that hard.

Well, the point I was making was that the same can easily be true of microservice architectures. If you have people that don't know what they're doing architecting your microservices, you'll have a difficult time maintaining them without clear and strict service contracts. It's not clear to me that we're ever comparing apples to apples in these discussions. It would seem to me that everyone arguing left a job where t…

Functionally its the same stuff.

Both have boxes of stuff and the stuff talks to other stuff.

Logistically its a bit easier to scale the one where the boxes are married to closer to the hardware abstraction (microservices on instances) versus the one where boxes are married to the software abstraction (threads with memory), for the same reason one (monolith) is a lot faster (dev/process/latency) (at small scales) than the other (microservice).

You can scale both, really its mostly about fights about the tooling, process, and where your sec-ops decided to screw you over the most (did they lock down your environments or did they make it impossible to debug ports/get logs).

Practically, AWS is expensive, and they're bloated. Cluster environments that let you merge 1000 computers into 1 big supercomputer and have 1 million cores/terabytes of ram, come with different technical challenges that not as many people know how to overcome, or expensive hardware bills.

So I'd say if someone tells you it "has to be" one or the other they are blowing smoke. Micro-services were recently the hip-new-thing so it makes sense some really really bad nonsense has been written in them so people are rediscovering monoliths (and realizing the microservice people were snake-oil salesmen). In 10 years we'll realize again that some monoliths are really badly written and some people without a clue will re-write them as microservices...

Post reply on HN