Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Starting with microservices

arnoldgalovics.com

Post reply on HN
Print view View original

121–130 of 139 posts

Re: Starting with microservices

#121

Post by darkwater »

aflag wrote: post #33
JamesSwift wrote: post #25

Earlier quoted context omitted.

It seems over time some nuance has been lost in translation on this. Microservices weren't 'more scalable' than monoliths, they were 'more appropriately scalable'. In other words, you could scale parts independently and shape your infrastructure more effectively for your workload. e.g. If your bottleneck is logins, you scale the LoginService and don't need extra copies of the AppointmentService running to keep up.

Sure, but I think the point is that it's unlikely the bottleneck will be in the web server, but in whatever database you're using for your logins. Just because you have a single program, it doesn't mean it is required to use a single database. But even if the webserver is the problem, it feels unlikely that you'll end up saving much in infrastructure cost by scaling just the login service rather than just deploying m…

> Just because you have a single program, it doesn't mean it is required to use a single database.

I would challenge that. Obviously a well written "monolith" with well insulated modules, separation of concerns etc can use different databases but I heard too many times when I ask "why can't we shard the database" the answer "the data model is one and it's way easier to develop on one single data model that on N models inside the monolith".

Re: Starting with microservices

#122

Post by _pdp_ »

wackget wrote: post #119
_pdp_ wrote: post #114

I have a different view of what microserves are and how they can be used without the overhead everyone is right to point out and hate. In my project we do utilise microserve architecture through the serverless paradigm (i.e. bunch of lambdas) but those services are exposed directly to the client via API gateways (many of them). In essence there is very little service-to-service communication. Each service has its own…

> The reason I believe this is a good approach for pretty much any problem is because each component is 100% swapable In reality, how often will a client actually want to perform a straight swap like this, though? And that's assuming there is such a thing as a straight swap, which there almost never is. It's a nice idea in theory but in practice it's worth very, very little.

You might want to swap different versions of the same component or you might want to swap by implementing it in a different programming language, etc.

These ideas work for me in practice so I don't know.

Re: Starting with microservices

#123

Post by scottious »

monocasa wrote: post #32

I've come to the conclusion that microservices as usually implemented are simply a Conway's law concern. We haven't had a great track record defining the semantics of component boundaries, but http is both simple enough that it constricts code flow in a particular way leaving a lot of misunderstandings and bike shedding discussions off of the table, and is the ligua franca for external services owned by other orgs so…

There are plenty of monoliths that scale in terms of number of contributors and organizational changes. For example, the Linux kernel. I've worked on massive monoliths that were 20 years old and changed hands and org structures tons of times and nobody ever thought "this needs to be microservices!"

Microservices are not the only way to modularize code.

Also, there is TONS of bike-shedding with regard to HTTP. Which HTTP method do you use? How do you structure your paths? What does the body of the request look like? How to we translate failures into the various HTTP error codes? Do you send a 200 or a 201 status for this particular request? I could go on and on... Even among well established HTTP APIs, there are differences.

> Letting [technology choices] drift on a per team basis is kind of nice to allow experimentation with different technologies without having to get the whole org onboard.

This is very much a double edged sword. I've seen this happen and people just tend to avoid services in languages/frameworks that they don't know. And even if they don't avoid them, they are less productive in them. We have a critical services written in Rust and one guy at the company knows Rust. We have 2 services written in a particular Java reactive framework which only a few people know how to use. Any newcomers to these services have to spend a lot of time learning a new thing.

Re: Starting with microservices

#124

Post by Nextgrid »

jiggawatts wrote: post #41

Architecture astronauts love microservices. I'm watching a government customer take simple, cohesive systems developed by a small team (4-5 people) and split it up into tiny little pieces scattered across different hosting platforms and even clouds. Why? Because it's "fun" for the architects and pads out their resume. Just now, I'm watching a "digital interactions" project that will have dozens of components across t…

This reflects my opinion on the current state of the software industry.

The seemingly-infinite VC money being thrown around around means you can create a startup, raise some money and provide a comfortable salary & industry experience for yourself and your friends for a few years, regardless of whether the company "makes it" in the end or whether the business problem is even solvable.

At this point solving the business problem is no longer the primary objective. The longer you can drag out the process of "solving" this problem the longer you & your employees can enjoy the salary and build "experience". So instead of a simple solution that needs a team of 5, you end up with an engineering playground that needs 50 people (and associated managers, scrum masters, etc) spread across many teams just to keep the lights on. The outcome becomes endless busywork, self-inflicted problems to brag about solving on your engineering blog (every startup has got to have one obviously) and next AWS conference to attract more employees looking for this kind of environment and make yourself look "serious" in the eyes of VCs that keep bankrolling the disaster.

The business problem, if it gets solved at all, is a secondary concern since the VCs happily keep throwing more money into the dumpster fire and some bigger idiot might even buy out the company regardless of its inefficiency.

Re: Starting with microservices

#125

Post by kitd »

jiggawatts wrote: post #41

Architecture astronauts love microservices. I'm watching a government customer take simple, cohesive systems developed by a small team (4-5 people) and split it up into tiny little pieces scattered across different hosting platforms and even clouds. Why? Because it's "fun" for the architects and pads out their resume. Just now, I'm watching a "digital interactions" project that will have dozens of components across t…

I'm watching a government customer take simple, cohesive systems developed by a small team (4-5 people) and split it up into tiny little pieces scattered across different hosting platforms and even clouds.

Governments are generally driven by a set of requirements that most of us have no inkling of. Distributed deployments are often not just for performance or resilience, but also politics and/or playing the vendors off against each other. It seems daft to us mere minions but there's often N-level chess shenanigans going on near the top.

Re: Starting with microservices

#126

Post by twic »

darkwater wrote: post #118
twic wrote: post #109

Earlier quoted context omitted.

I have done this several times, with various small variations, and find it works well. I don't have a good name for it. I think it's a variety of cookie-cutter scaling: https://paulhammant.com/2011/11/29/cookie-cutter-scaling/ But there's nothing in that about using different entrypoints or routing. FWIW, variations on the theme: 1. A single binary with a single entrypoint, which can play multiple roles simultaneousl…

Isn't 5 just... microservices in a monorepo?

Yes!

Re: Starting with microservices

#127

Post by brightstep »

beefsack wrote: post #76
rapind wrote: post #53

Earlier quoted context omitted.

Pretty sure microservices will be remembered as a horribly convoluted stop gap once we have better language modularization. They encourage modular patterns which is usually good, but all that plumbing will eventually become unnecessary. I can’t help but remember building 6 versions of each class in the old ejb days whenever I hear microservices hype.

Even with language modularisation you lose the ability to provision modules independently if they are bundled together in a single service. Microservices and monoliths are opposing extremes on a scale. There is a range somewhere in the middle which is entirely sensible. I feel like I've found my greatest success with my service abstractions by separating things out based on resource and availability needs of the func…

If you maintain the same interface (same classes, methods, types, etc) it seems to me a module ought to be hot-reloadable within the same process. This is already possible with a loosely-coupled plugin architecture and I could see it being an integrated part of a language.

Re: Starting with microservices

#128

Post by Tehnix »

Nextgrid wrote: post #14
marcosdumay wrote: post #7

Do you know what kind of software has an absurd level of horizontal scalability by default? Web servers. The idea of splitting your web servers into multi-tiered web servers for scalability is, well, weird. Yet, somehow it's the main reason people keep pushing it. Even this article repeats this. There's nothing on microservices that adds scalability. They make it convenient to deal with data partitioning, but it's an…

I never got the “scalability” argument of microservices. You can trivially deploy multiple instances of your monolithic web application - chances are you’re already doing so by running multiple workers/threads in your application server. Spreading that to other machines is trivial. The real issue is in scaling the data store. Microservices typically work around that problem by each having their own separate database,…

It's in fact exactly in Horizontal scalability that it becomes important to have control over exactly what resources you need to scale :)

Let's take a typical monolith. You'll be serving endpoints that: - Are CPU intensive - Are memory intensive - Are I/O intensive

They are almost always heavy on some part, but not all. And definitely they are not uniformly all relying on the same amount of resources.

Now, you scale out horizontally, adding instances of the same size because each of these monolithic instances need to be capable of serving the entire domain without impacting tail latencies. Some part of your application becoming more resource intensive? You'll be bumping up the sizes of the entire monolith because you are essentially needing to do the equivalent of provisioning for peak load.

Contrast this with microservices (which I'm not arguing are a silver bullet), you can run your memory intensive part of memory optimized instances, and run your compute intensive parts on compute optimized instances.

That's the part about scalability.

Now, the more interesting part (for me, personally) is reliability. You are decreasing your blast radius of a bad component/thread/process taking down your entire monolith service, and instead compartmentalizing it into limited subparts of your entire API or application.

Finally, as you mentioned, microservices do help guide you towards better choices when it comes to structuring your data. You can do this with monoliths as well (and should), but it doesn't come naturally, and having a single data store is the main reason I see teams run into scalability issues :)

---

Addition: Some thing I don't see many people talk about is the ability to address tech-debt in Microservices. My experience has been that it is an enormous benefit to have made you domain smaller for when it comes to making changes that require sweeping across the whole codebase. Examples include upgrading language versions (e.g. Scala 2 -> 3, Haskell 8.10 -> 9.2), upgrading frameworks, introducing stricter compilation checks (e.g. TypeScript and strict: true).

These easily end up being either insurmountable or year-long projects in a monolith, where it's very hard to incrementally benefit from the work because they are often by nature all or nothing changes.

Re: Starting with microservices

#129

Post by JamesSwift »

twic wrote: post #112
JamesSwift wrote: post #25

Earlier quoted context omitted.

It seems over time some nuance has been lost in translation on this. Microservices weren't 'more scalable' than monoliths, they were 'more appropriately scalable'. In other words, you could scale parts independently and shape your infrastructure more effectively for your workload. e.g. If your bottleneck is logins, you scale the LoginService and don't need extra copies of the AppointmentService running to keep up.

Even this premise is fundamentally mistaken. If you have a monolith, and the LoginModule is overloaded, you add more hardware, and it's the LoginModule which makes use of the additional resources. The AppointmentModule isn't going to suddenly start using more resources just because they're available.

Not really, the load gets spread out across your nodes so if you go from 1 -> 2 then the new AppointmentModule is handing 50% of the previous load. Thats just CPU. RAM tends to be stickier and you can easily cost yourself a lot more than "needed" to overprovision in this manner.

Re: Starting with microservices

#130

Post by marcosdumay »

pas wrote: post #90
marcosdumay wrote: post #52

Earlier quoted context omitted.

Building, ok, but for testing or debugging microservices aren't really an alternative. Just like scalability, they add no new capability here. The most they can do is adapt better to some set of procedures than a monolith. For deploying they are nothing but a very large hindrance.

Is it not better to debug one microservice than the whole monolith? Easy to run locally, easy to reproduce errors, etc. (My last two weeks was working in such an environment hunting a production bug. Debugging it was a pleasure. Clear interfaces, etc. Of course when a small feature requires changing 3-4 microservices the pleasure is definitely less :D) It's much easier to test them in separation also. Deployments are…

> Is it not better to debug one microservice than the whole monolith?

As long as your bug is well behaved and decided to keep itself into a single microservice... and you somehow know what microservice it is, then yes, it's much easier.

Post reply on HN