Monolith First (2015) • Hacker News Board

Re: Monolith First (2015)

#11

Post by eropple » Sat, Jul 15, 2017, 9:25 PM UTC

olingern wrote: post #9

> Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. I wholeheartedly disagree with this point. I've found that if I build monolith first, it becomes harder to draw the line of how to separate endpoints, services, and code within the system(s). If I design in a "microservice first," or just a service oriented design -- I find tha…

I don't mean to pick on you, but your post is a litany of "doctor, it hurts when I do this!". There's nothing that should be preventing your monolithic application from handling significant load. You add more instances of your monolithic application. If you're encountering problems where horizontally scaling your monolithic application is falling down, you have much more severe problems that introducing network boundaries don't solve.

Monolithic applications don't encourage naive approaches; your conscious and unconscious choices around desired development rigorousness do. If those choices are causing you problems, there are much easier ways to prevent yourself from doing it than introducing network boundaries.

Re: Monolith First (2015)

#12

Post by phaed » Sat, Jul 15, 2017, 9:28 PM UTC

olingern wrote: post #9

> Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. I wholeheartedly disagree with this point. I've found that if I build monolith first, it becomes harder to draw the line of how to separate endpoints, services, and code within the system(s). If I design in a "microservice first," or just a service oriented design -- I find tha…

> I find that the microservice first approach makes me consider future optimizations, such as caching policies, whereas, in a monolith, I would proceed in a naive, "I'll figure it out later" approach.

This goes to his point, the time spent considering these points is time gained in delivering an MVP to market.

> "Hey, we just built this great MVP for you. It probably won't handle significant load, so we're going to go off in a corner and make it do that now. Oh yeah, we won't have time to develop new features because we'll be too busy migrating tests and writing the ones we didn't write in the beginning."

You don't need that level of scaling potential in an MVP, and you get to have something out -- in time. While if you had started with a microservices approach you would still be off in that corner trying to get something usable out. Now you have a product in the hands of users, and your refactoring can consider that feedback.

Re: Monolith First (2015)

#13

Post by taurath » Sat, Jul 15, 2017, 9:29 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…

Couldn't agree more - inheritance chains and heavily stateful instruction environments are the number one blocker to eventually decoupling a monolith. The "enterprise" code style is absolutely what you need to avoid in a startup.

Re: Monolith First (2015)

#14

Post by olingern » Sat, Jul 15, 2017, 9:35 PM UTC

eropple wrote: post #11

olingern wrote: post #9

> Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. I wholeheartedly disagree with this point. I've found that if I build monolith first, it becomes harder to draw the line of how to separate endpoints, services, and code within the system(s). If I design in a "microservice first," or just a service oriented design -- I find tha…

I don't mean to pick on you, but your post is a litany of "doctor, it hurts when I do this!". There's nothing that should be preventing your monolithic application from handling significant load. You add more instances of your monolithic application. If you're encountering problems where horizontally scaling your monolithic application is falling down, you have much more severe problems that introducing network bound…

> There's nothing that should be preventing your monolithic application from handling significant load.

I don't disagree at all. As with most things in life, throwing money at the problem will solve this. In a lot of positions I've been in, this cost becomes "the cost of doing business" that everyone assumes rather than, "we can do better, but for now this is our reality."

> Monolithic applications don't encourage naive approaches;

Perhaps, naive is a poor choice of words. Maybe, an example is better:

You develop a large system that's going to support an entire state's childrens meal plans. You can easily do this in a monolithic architecture, but is it worth investing time to save on peeling apart the obvious points of high use now?

Children / parents only have to sign up once, but they need access to their meal plans everyday. I see two services here in this simple example, and if I'm strapped for time -- I defer a user management service to some sort of SAAS / PAAS so I don't have to deal with that overhead.

I see a great deal of value to everyone in investing in the optimizations that have high return, but minding Knuth's rhetoric that "premature optimization is the root of all evil."

Re: Monolith First (2015)

#15

Post by olingern » Sat, Jul 15, 2017, 9:41 PM UTC

phaed wrote: post #12

olingern wrote: post #9

> Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. I wholeheartedly disagree with this point. I've found that if I build monolith first, it becomes harder to draw the line of how to separate endpoints, services, and code within the system(s). If I design in a "microservice first," or just a service oriented design -- I find tha…

> I find that the microservice first approach makes me consider future optimizations, such as caching policies, whereas, in a monolith, I would proceed in a naive, "I'll figure it out later" approach. This goes to his point, the time spent considering these points is time gained in delivering an MVP to market. > "Hey, we just built this great MVP for you. It probably won't handle significant load, so we're going to g…

> This goes to his point, the time spent considering these points is time gained in delivering an MVP to market.

In undiluted markets where you're entering 'new territory' -- sure. Get a product in user's hands and let it evolve how it should. There are different scenarios where companies already have a user base and you have to be able to respond to that load within your MVP.

Referring to what I said in my original comment, there are always trade-offs, and monoliths have their place. If you have the luxury of time and money, I would say that a monolith is less than ideal.

> You don't need that level of scaling potential in an MVP, and you get to have something out -- in time. While if you had started with a microservices approach you would still be off in that corner trying to get something usable out. Now you have a product in the hands of users, and your refactoring can consider that feedback.

Don't disagree with this at all. Context of your market probably dictates whether you'll be in a corner or still figuring out service boundaries.

Re: Monolith First (2015)

#16

Post by lmm » Sat, Jul 15, 2017, 9:43 PM UTC

a_imho wrote: post #6

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

Doesn't know what he doesn't know. There's some good advice among what he says, but he also generalises far beyond the limits of his experience.

Re: Monolith First (2015)

#17

Post by sbov » Sat, Jul 15, 2017, 9:43 PM UTC

olingern wrote: post #9

> Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. I wholeheartedly disagree with this point. I've found that if I build monolith first, it becomes harder to draw the line of how to separate endpoints, services, and code within the system(s). If I design in a "microservice first," or just a service oriented design -- I find tha…

> significant load

Please define significant load.

Re: Monolith First (2015)

#18

Post by y2hhcmxlcw » Sat, Jul 15, 2017, 9:43 PM UTC

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?

Re: Monolith First (2015)

#19

Post by olingern » Sat, Jul 15, 2017, 9:44 PM UTC

sbov wrote: post #17

olingern wrote: post #9

> Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. I wholeheartedly disagree with this point. I've found that if I build monolith first, it becomes harder to draw the line of how to separate endpoints, services, and code within the system(s). If I design in a "microservice first," or just a service oriented design -- I find tha…

> significant load Please define significant load.

30+ requests/sec

Some would consider it light, but I work alongside a company that is currently struggling to get beyond that mark.

Re: Monolith First (2015)

#20

Post by maxxxxx » Sat, Jul 15, 2017, 9:47 PM UTC

gluczywo wrote: post #4

even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning. By building a monolith first, you can figure out what the right boundaries are This line of thought reaches two decades ago and was expressed in a wonderful essay "Big Ball of Mud" http://www.laputan.org/mud/ EDIT: updated with the quote

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.