The costs of microservices (2020) • Hacker News Board

Re: The costs of microservices (2020)

#311

Post by charcircuit » Tue, Oct 31, 2023, 1:41 AM UTC

LelouBil wrote: post #295

lemmsjid wrote: post #223

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.

> a monolith you can't roll back "a part" of the app to the latest version if you pushed multiple unrelated features at once.

git revert

Re: The costs of microservices (2020)

#312

Post by lmm » Tue, Oct 31, 2023, 1:42 AM UTC

TeMPOraL wrote: post #242

arzke wrote: post #14

Earlier 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.

Committing to a decision is costly, but implementing it one way or the other and seeing how that works is often the cheapest way to proceed.

Re: The costs of microservices (2020)

#313

Post by antonvs » Tue, Oct 31, 2023, 1:45 AM UTC

hinkley wrote: post #186

wongarsu wrote: post #156

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…

> There's no clever soundbite to parrot.

Introducing the Revolutionary "Ten Service Applications" – because Ten is the Magic Number!

Tired of the endless debates about how many services your applications should have? Frustrated with the constant struggle to find the "Goldilocks" number of services? Look no further! The future of software design is here, and it's as easy as 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10!

The "Ten Service Applications" model is here to rescue you from your software design woes. We're not messing around with random numbers like 7 or 12 services. No, we've cracked the code, and it's all about that perfect "ten." You don't need any more services, and you definitely don't need any less. Ten is the answer to all your architectural problems!

So, are you ready to embrace the simplicity, predictability, and coolness of the "Ten Service Applications" model? Join the revolution today and experience software development like never before!

Act now, and we'll even throw in a bonus "Top 10 Services" list to inspire your next project. But remember, you only get 10 services, no more, no less—because why mess with perfection?

Re: The costs of microservices (2020)

#314

Post by smaudet » Tue, Oct 31, 2023, 1:48 AM UTC

lmm wrote: post #300

bob1029 wrote: post #197

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

Does .net not have a way to run simple private repository like Nexus? Over in JVM-land that's a basic thing that you'd be doing anyway.

It's the difference between drag-dropping a reference between "projects" or whatnot in your monolith project, or coming up with a publish pipeline after which your merged code gets into the repo so that other people can use it, if you have three projects in three checkouts that all have to be coordinated and merged in order so that you don't accidentally break your environment and worry about security and and and....

One is much simpler than the other. Artifact management is surprisingly complex, it only looks like it works great while you aren't managing many versions and acting more like a monolith, just spread across repos/deploy points.

Re: The costs of microservices (2020)

#315

Post by marcus_holmes » Tue, Oct 31, 2023, 1:49 AM UTC

TeMPOraL wrote: post #304

jlundberg wrote: post #258

Earlier quoted context omitted.

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

Agree with all of that, and want to add a shoutout to the Cult of Done [0].

Very few things need to be perfect, or right first try. Waiting until the last possible moment is a version of perfectionism that is often counter-productive. Trying something out before it's needed gives room to experiment and discover new approaches.

[0] https://medium.com/@bre/the-cult-of-done-manifesto-724ca1c2f...

Re: The costs of microservices (2020)

#316

Post by smaudet » Tue, Oct 31, 2023, 1:55 AM UTC

tsss wrote: post #238

ljm wrote: post #230

Earlier quoted context omitted.

Ideally you would use the same language if it had distributed support. Use Erlang or Elixir for example and you have everything you need for IPC out of the box. Might take a little bit more effort if you're on Kubernetes. One of my problems with microservices isn't really the services themselves, but the insane amount of tooling that creeps in: GRPC, Kafka, custom JSON APIs, protobufs, etc. etc. and a lot of them exi…

If you do so much IPC that you have to design your language around it you're probably doing it wrong. I don't think that moving to a monolith would really cut down that much on other technologies. Maybe you can do without Kafka, but certainly you will need some other kind of persistent message queue. You will still need API docs and E2E integration tests.

"You will still need API docs"

Been free in my IDE since I compiled the code...

"E2E integration tests"

I can mostly run these on my machine, no need to stand up a cluster to get it running (bonus points if you virt multiple machines on one and still don't need the cluster for complex distributed scenarios).

"you will need some other kind of persistent message queue"

var queue = new Queue(); // then sometime later... queue.Save(); // or queue.EmplaceAndSave(); ... queue.Pop();

Trivial and didn't need a server to set it up.

Lots of tech stack stuff simply disappears without server boundaries and the like to get in the way. There is other tech you have to deal with, but at the small scales it mostly doesn't apply. Which, you as a dev are usually only working at small, testing scales, so you don't usually need to support it.

Re: The costs of microservices (2020)

#317

Post by paulddraper » Tue, Oct 31, 2023, 2:01 AM UTC

wholesomepotato wrote: post #235

paulddraper wrote: post #63

> The term micro can be misleading, though - there doesn’t have to be anything micro about the services. In fact, I would argue that if a service doesn’t do much, it just creates more operational toll than benefits. A more appropriate name for this architecture is service-oriented architecture, but unfortunately, that name comes with some old baggage as well. What baggage is that? Because in my experience 90% of the…

https://www.service-architecture.com/articles/web-services/s... After enough people retire that remember how big of a mess this was, we can probably re-use "Service Oriented".

You linked to Simple Object Access Protocol.

I don't follow the point.

Re: The costs of microservices (2020)

#318

Post by smaudet » Tue, Oct 31, 2023, 2:03 AM UTC

lemmsjid wrote: post #289

slowmovintarget wrote: post #221

Earlier quoted context omitted.

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.)

Good show for mentioning that. If it becomes commonplace for popular runtimes and languages to be able to load modules and their dependencies at that level, then a lot of arguments for service encapsulation go away. I think in these discussions, a lot of times people are taking past one another. If I start putting a JRE-targeted application together, I know I can eventually reach for isolated modules if I follow good…

AWS Lambdas and OSGI invocations are the same thing! (Except one costs you money and one doesn't, guess which one is easier to use).

Re: The costs of microservices (2020)

#319

Post by charcircuit » Tue, Oct 31, 2023, 2:06 AM UTC

wnolens wrote: post #246

hu3 wrote: post #189

Earlier quoted context omitted.

> Probably just the interface - function calls become RPC. Network calls introduce new failure modes and challenges which require more plumbing. Can I retry this RPC call safely? How about exponential backoff? Is my API load-balancer doing its thing correctly? We'll need to monitor it. How about tracing between microservices? Now we need OpenTelemetry or something like that. How harder is it to debug with breakpoints…

My first Q was re: monolith on one host to many services on one host. And yes, when going off-host, you'll have these issues. One should not employ network hops unnecessarily. Engineering is hard. Doesn't make it not worth doing.

Even on one host processes can crash at different times.

Re: The costs of microservices (2020)

#320

Post by smaudet » Tue, Oct 31, 2023, 2:07 AM UTC

slowmovintarget wrote: post #221

voxic11 wrote: 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.)

To be fair the problem is that its not baked into the language.

If you have to do X,Y,Z to get A done, then you'll do X,Y,Z.

If your language gives you a shortcut and now you can get away with X,Y then you'll drop Z.

And even if your language doesn't give you those shortcuts, if Cool Language lets you do just X or X,Y, you'll naturally want to use Cool Language. So, its a losing game...

KISS is great when applied correctly, but you have to be able to know the level of complexity you'll actually need for the problem at hand, and it is so so very easy to over or under engineer something...