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

What Even Are Microservices?

var0.xyz

Post reply on HN
Print view View original

61–70 of 87 posts

Re: What Even Are Microservices?

#61

Post by mrkeen »

inigyou wrote: post #39
mrkeen wrote: post #6

> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about…

Microservices still have global concerns. Is someone actually using that endpoint or can you remove it? How will you know? Ask everyone? How many HTTP calls are made during one user request and how long does it take? (This concern brought down one of the early microservice projects with a 10-minute page load time) What are the race conditions? User removes billing info at the same moment as making a payment - what ha…

At least read to the end

> Knowing whether public routes are still in use is still a problem, so you need a minimum level of metrics or logging before you can retire an endpoint.

> What are the race conditions?

Everywhere. Just fucking everywhere. I ran a workshop for my team (4-5 backenders) with a simple, pared down example with reads and writes within a 'transaction'. I then demonstrated that LINQ breaks its transactionality, and running in READ-COMMITTED (which everyone does) also breaks transactionality. Either of these conditions is enough. My team walked away understanding this.

But we left the idea there to die, because you cannot change these things politically. No monolith owner is going to even pretend to demonstrate thread safety.

The lines of defence are:

* He will assume it's thread safe

* He will argue against change "for code consistency"

* He will argue that it makes the code simpler and easier to understand

* He will introduce a change which he assumes will fix it, but clearly only makes the race condition harder to diagnose

* He will argue that it doesn't matter because race conditions are rare anyway.

It's all academic anyway - in a monolith you won't get past the first line of defence anyway.

Re: What Even Are Microservices?

#62

Post by mrkeen »

VulgarExigency wrote: post #19
mrkeen wrote: post #6

> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about…

> I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about it. Everyone's responsibility is no-one's responsibility, and the code stays as is. Then they can retrieve it from source control? Leaving dead code in the codebase because "someone else might want it" sounds like nonsense.

Then substitute 'dead code' for 'buggy code that someone else likes'

Re: What Even Are Microservices?

#63

Post by inigyou »

mrkeen wrote: post #55
inigyou wrote: post #46

Earlier quoted context omitted.

Why do you think different people can't work on different parts of a single deployment unit (which is what we mean by "monolith")?

* My last monolith job had 4 hour release windows. * You can't change anything of substance. The more people touching the same codebase as you statistically puts you way lower in the pecking order. Changes become political, not technical. Sometimes the forces of stupidity cancel each other out. It was a 10+ year-old C# monolith, and the top dog wanted to switch to Python because "AI works better with it". I didn't ha…

Why would a single deployment unit have to be written in exactly one language?

Re: What Even Are Microservices?

#64

Post by inigyou »

mrkeen wrote: post #61
inigyou wrote: post #39

Earlier quoted context omitted.

Microservices still have global concerns. Is someone actually using that endpoint or can you remove it? How will you know? Ask everyone? How many HTTP calls are made during one user request and how long does it take? (This concern brought down one of the early microservice projects with a 10-minute page load time) What are the race conditions? User removes billing info at the same moment as making a payment - what ha…

At least read to the end > Knowing whether public routes are still in use is still a problem, so you need a minimum level of metrics or logging before you can retire an endpoint. > What are the race conditions? Everywhere. Just fucking everywhere. I ran a workshop for my team (4-5 backenders) with a simple, pared down example with reads and writes within a 'transaction'. I then demonstrated that LINQ breaks its trans…

You seen to be equating "monolith" with "managed by a cranky guy" when it actually means "single unit of deployment"?

Re: What Even Are Microservices?

#65

Post by mrkeen »

inigyou wrote: post #64
mrkeen wrote: post #61

Earlier quoted context omitted.

At least read to the end > Knowing whether public routes are still in use is still a problem, so you need a minimum level of metrics or logging before you can retire an endpoint. > What are the race conditions? Everywhere. Just fucking everywhere. I ran a workshop for my team (4-5 backenders) with a simple, pared down example with reads and writes within a 'transaction'. I then demonstrated that LINQ breaks its trans…

You seen to be equating "monolith" with "managed by a cranky guy" when it actually means "single unit of deployment"?

Right, and I am also "the cranky guy" to the other guy.

But yes, I am equating those. Some people might take Conway's law as a warning to try to avoid; others might take it as a natural law description and therefore unavoidable. I'm in the second camp. Whichever way you swing, it is a political issue, and is therefore about cranky guys.

Re: What Even Are Microservices?

#67

Post by asimpletune »

regularfry wrote: post #53
asimpletune wrote: post #37

This is what people always say but it's not really the only case, and it's not even a particularly good case. You could achieve the same organizational thing through modules, for example. The real—and the one thing you can't replicate—is data isolation. Of course there are other benefits, but it's data isolation is the differentiator of micro-services and other types of architecture.

It's not just the modular organisation that you've got to get right though, although that's definitely a big thing. Deployment independence matters too: if I've got a perfectly modular monolith but I have to coordinate with everyone else who lives in that monolith to get my module into production, it's leaving half the gains on the table.

That's true too. So, the two things are data isolation and operational independence.

Re: What Even Are Microservices?

#68

Post by mrkeen »

sdfdfsfsdsdf wrote: post #42
mrkeen wrote: post #6

> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about…

It's called programming to an interface. type ThingDoer interface { DoTheThingIDontCareHow() (result, error) } func NewAmazingThingIMade(theThingINeedButIDontCareHowItDoesIt ThingDoer) { // You receive the superduper thing and dont care about it in any other way } func (a *Amazing) DoSomeThing() (result, error) { return a.DoTheThingIDontCareHow() } Nothing about "monoliths" prevents or hampers this development style.…

The pain of the network boundary pays for itself many times over compared to sharing a codebase with developers who don't program to the interface.

Re: What Even Are Microservices?

#69

Post by reactordev »

zero_shift wrote: post #58
reactordev wrote: post #43

Earlier quoted context omitted.

It is trivial when properly configured and used. I get why you think I might not have worked on large systems but to the contrary, I've built systems for Fortune 500s. All of them had this baked in and all of them had a place to go when things went wrong. Self-service, observable, documented, and supported by the very folks who wrote it.

Observability and operability are just not the same thing as being able to reason about the software. You need both You can't capture the full range of behaviours and edge cases unless you are willing to ingest billions of events without lossiness Metrics have limitations of cardinality. Logs need to be reduced or else you are in archive rehydration hell There will be code paths that have never been triggered that yo…

>”There are code paths that have never been triggered”

I don’t know where you learned engineering but where I work, we test our code. There are no “dark” paths.

98% code coverage over 50+ microservices.

Re: What Even Are Microservices?

#70

Post by mrkeen »

inigyou wrote: post #63
mrkeen wrote: post #55

Earlier quoted context omitted.

* My last monolith job had 4 hour release windows. * You can't change anything of substance. The more people touching the same codebase as you statistically puts you way lower in the pecking order. Changes become political, not technical. Sometimes the forces of stupidity cancel each other out. It was a 10+ year-old C# monolith, and the top dog wanted to switch to Python because "AI works better with it". I didn't ha…

Why would a single deployment unit have to be written in exactly one language?

OK, count me onboard!

Can we convince the 2-3 other stakeholders in our deployment unit to go with this crazy plan? Or are there 40-60 other stakeholders we need to convince?

Post reply on HN