Monolith First (2015) • Hacker News Board

Re: Monolith First (2015)

#31

Post by staofbur » Sat, Jul 15, 2017, 10:05 PM UTC

eropple wrote: post #29

staofbur wrote: post #27

Earlier quoted context omitted.

I'd argue it's cheaper scaling out the monolith or introducing isolated functional silos and scaling them out than even bothering migrating everything to microservices. Also you certainly can't port a complex monolith to microservices; you have to start again. We're quite happily able to shift 15,000 requests/sec from over 2000 http endpoints with a monolith and our kit is at ~20% capacity. Need more? Slice up a silo…

> Also you certainly can't port a complex monolith to microservices Upvoted you, but I disagree with a little. "Microservices" tend to pathological cases, but you 100% can segment a monolithic apps into services . Each module in your application has an interface. Behind that interface, replace it with network calls that fulfill the interface's contracts. (If your monolith doesn't have sections that encapsulate work--…

You can, hence my comment about silos. The interface is rarely well defined enough to be able to abstract it over a network boundary from experience. One of the things I see in a lot of monoliths is leaky abstractions and they are really difficult to reign in.

We tend to go for throwing related web front and and API endpoints into the same ball of mud silo and back end that directly with the storage and cache services. We scale those silos up and partition across tenants too. I think a couple of the silos are around the 1 million LoC size now as well.

Re: Monolith First (2015)

#32

Post by eropple » Sat, Jul 15, 2017, 10:07 PM UTC

staofbur wrote: post #31

eropple wrote: post #29

Earlier quoted context omitted.

> Also you certainly can't port a complex monolith to microservices Upvoted you, but I disagree with a little. "Microservices" tend to pathological cases, but you 100% can segment a monolithic apps into services . Each module in your application has an interface. Behind that interface, replace it with network calls that fulfill the interface's contracts. (If your monolith doesn't have sections that encapsulate work--…

You can, hence my comment about silos. The interface is rarely well defined enough to be able to abstract it over a network boundary from experience. One of the things I see in a lot of monoliths is leaky abstractions and they are really difficult to reign in. We tend to go for throwing related web front and and API endpoints into the same ball of mud silo and back end that directly with the storage and cache service…

Fair enough. In places where I've had to deal with that, I was in the code review seat ahead of time and was generally able to go "no no no, let's not do that"--but I can see how stuff can decay.

Re: Monolith First (2015)

#33

Post by olingern » Sat, Jul 15, 2017, 10:08 PM UTC

eropple wrote: post #28

sbov wrote: post #23

Earlier quoted context omitted.

So it would probably surprise you to hear that companies I've worked for in the past have built monolithic applications serving pages that were per-user dynamic that can handle upwards of 20,000 requests per second? This is why I hate this subject. People use terms and don't define them. If you think microservices is the only way to scale past 30 requests per second you're extremely wrong.

I need to give you an internet fistbump for this. I mean...you know what you can even do instead of The Holy Microservice? You can take parts of your API, facade them behind a different load balancer, and call into different instances of your monolith that only handle user management or billing or whatever. Un-run code's cost is, in the general case, basically zero--act like it. You don't need to do something like th…

Not sure why the contempt with an opinion.

I get that microservices are trite, and most people think they need them long before necessary; however, they have uses beyond scale.

I'm sure that there are ways to mitigate every point I can make within monoliths.

My points are just opinions.

Re: Monolith First (2015)

#34

Post by fishnchips » Sat, Jul 15, 2017, 10:08 PM UTC

eropple wrote: post #29

staofbur wrote: post #27

Earlier quoted context omitted.

I'd argue it's cheaper scaling out the monolith or introducing isolated functional silos and scaling them out than even bothering migrating everything to microservices. Also you certainly can't port a complex monolith to microservices; you have to start again. We're quite happily able to shift 15,000 requests/sec from over 2000 http endpoints with a monolith and our kit is at ~20% capacity. Need more? Slice up a silo…

> Also you certainly can't port a complex monolith to microservices Upvoted you, but I disagree with a little. "Microservices" tend to pathological cases, but you 100% can segment a monolithic apps into services . Each module in your application has an interface. Behind that interface, replace it with network calls that fulfill the interface's contracts. (If your monolith doesn't have sections that encapsulate work--…

That. Most folks understand services as separate codebases, running as separate deployments. My take is that they are logical entities to a degree where their physical implementation is irrelevant to their clients.

Re: Monolith First (2015)

#35

Post by eropple » Sat, Jul 15, 2017, 10:14 PM UTC

olingern wrote: post #33

eropple wrote: post #28

Earlier quoted context omitted.

I need to give you an internet fistbump for this. I mean...you know what you can even do instead of The Holy Microservice? You can take parts of your API, facade them behind a different load balancer, and call into different instances of your monolith that only handle user management or billing or whatever. Un-run code's cost is, in the general case, basically zero--act like it. You don't need to do something like th…

Not sure why the contempt with an opinion. I get that microservices are trite, and most people think they need them long before necessary; however, they have uses beyond scale. I'm sure that there are ways to mitigate every point I can make within monoliths. My points are just opinions.

It's not contempt, it's frustration because you're making assertions that are not backed up by reality.

This is what I do for a living, and I am regularly but-but-microserviced by people who are equally ignorant of competent application design and who think that breaking it into HTTP-intermediated chunks will solve that they are choosing to write bad code. That segmentation doesn't--it does nothing. It isn't YAGNI, but YAHYBDI, and I'll get hot under the T-shirt occasionally 'cause people who read discussions like this will get the wrong idea and stick their hands into the saw, too.

I could get paid more by letting people mangle themselves, but it'd be mean.

Re: Monolith First (2015)

#36

Post by Animats » Sat, Jul 15, 2017, 10:16 PM UTC

eropple wrote: post #10

taurath wrote: post #3

If you don't have a product yet or the parameters could change quickly with new business insight, you need to be able to change it fast. With microservices you will be spending half your time figuring out orchestration, building data flows that people can understand, and doing ops. Last startup I was in delayed their launch date for >6 months because of their architecture. Way too many people think they need it, but…

I do devops. I consult for startups. And while it would make me a lot more money in the short term to fuel their microservice-first, sparkly-architecture aspirations, this is exactly the approach I take when I pour some water on that. Your Big Ugly Monolith will get you where you're trying to go if anything will. You don't need services, you don't need microservices, you don't need some bloggable-as-heck Kubernetes s…

Rule of thumb: if you have two "service" talking to the same set of data in the same general-purpose datastore (i.e., not pub-sub, not opposite ends of a job queue), they're the same service.

Why? The whole point of a general-purpose database is to allow multiple applications to use the same data. Consider an online ordering system for merchandise. There's an service for checking product availability. There's a service for building a shopping cart. There's checkout and payment, the only one that faces the outside world that needs high security. There's customer order tracking. On the back end, there are various services which deal with fulfillment, shipping, accounting, and reordering. There may also be customer-relationship systems which can read order data for marketing purposes. Each of those functions can be worked on independently.

Re: Monolith First (2015)

#37

Post by eropple » Sat, Jul 15, 2017, 10:16 PM UTC

acdha wrote: post #30

a_imho wrote: post #6

Might be OT, but what is the opinion on Martin Fowler in general?

He's smart and experienced. That doesn't mean he's always right but I would consider what he says and reason through disagreements. Most commonly, I find the right/wrong arguments are actually reflecting the fact that the underlying environments aren't as similar as they might seem at first glance. Someone giving advice based on working on an F500 team with 200 developers will have seemingly-bizarre priorities to a 5…

I agree with this. I used to be a lot more down on his work, but it wasn't his fault so much as all the wannabes who bought it uncritically. (Much the same as stuff like Kubernetes--you aren't Google, they have Google problems, you don't have Google problems, stop automatically adopting Google solutions to problems that are a-web-server problems.)

Re: Monolith First (2015)

#38

Post by staofbur » Sat, Jul 15, 2017, 10:17 PM UTC

eropple wrote: post #32

staofbur wrote: post #31

Earlier quoted context omitted.

You can, hence my comment about silos. The interface is rarely well defined enough to be able to abstract it over a network boundary from experience. One of the things I see in a lot of monoliths is leaky abstractions and they are really difficult to reign in. We tend to go for throwing related web front and and API endpoints into the same ball of mud silo and back end that directly with the storage and cache service…

Fair enough. In places where I've had to deal with that, I was in the code review seat ahead of time and was generally able to go "no no no, let's not do that"--but I can see how stuff can decay.

I'm always late to the party. I'm the cleanup team :)

Re: Monolith First (2015)

#39

Post by y2hhcmxlcw » Sat, Jul 15, 2017, 10:20 PM UTC

losteric wrote: post #26

y2hhcmxlcw wrote: post #18

At what point will corporations that still design massive systems as an unmaintanable monolith figure out they can architect things better and save a ton of developer dollars? At what point do they start taking good points from articles like this and either break those up into microservices or some other solution?

When they realize business managers don't know jack about computers, and delegate more authority to engineers and/or hire product/technical managers. Development processes and software architecture follow from business process and architecture... it's hard to be agile and develop services with clean separation of responsibilities when business insists on monolithic hairball project reqs with fixed deadlines. (aka Con…

I wonder at what point the financial pressure to stop designing bad software becomes so high that it overrides the political pressures that created the bad designs and practices? To a community like HN it's just normal every day thinking to design even at least a decent web application, but at some companies that's seen as either visionary and impossible or even immature. But at some point it seems there would be so much money on the line to trim the number of man hours going into maintenance nightmares they would fix it. I sometimes wonder if big companies will wake up to this across the country and there will be big lay offs becuase they adopt modern architecture and they don't need so many people? Does this seem feasible or will conways law hold even as financial pressure to do better starts to really go up? Or will the rewrites take even more people and therefore there won't be layoffs/pressure on job market?

Re: Monolith First (2015)

#40

Post by Terr_ » Sat, Jul 15, 2017, 10:21 PM UTC

eropple wrote: post #25

maxxxxx wrote: post #20

Earlier quoted context omitted.

A lot of people don't have the discipline to write decent libraries so they need the overhead of microservices to force them to structure their code reasonably. It seems to me you can have exactly the same boundaries between components that you get through microservices by just having a good compenent separation.

This is exactly true. And so is the reverse: competently written code can be segmented out into a SOA by replacing your internal procedure calls with a network call.

Caveat: If it's acceptable to have significant latency or the interaction is asynchronous.