Why Most Apps Should Start as Monoliths

[-]

RICHUNCLEPENNYBAGS@reddit

Well one problem is if you decide you don’t want a monolith anymore it’s harder than if you had thought about this upfront. So if you know you don’t want that structure in the long run it’s worth considering

[-]

centurijon@reddit

Yep. The decision to break a monolith into micro devices should usually be driven by team size rather than “because I heard it’s better”. Once your team(s) start getting frequent merge or deployment conflicts you want to break up your app so they can work features and bug fixes with less interruption

[-]

emotionalfescue@reddit

I think there's general agreement on his first two points, that 1) a brand new app with unproven customer acceptance probably should start as a monolith, and 2) a huge app with lots of disparate features probably should be developed and deployed as a monolith.

Regarding his conclusion, I haven't done a survey of apps out there so I can't say for sure, but 99 percent sounds really high. After a monolithic app reaches a certain point in size and takes on many disparate responsibilities, it becomes hard to reason about, and developing and deploying rather simple changes seems to take a lot longer than it should because of the risk of breaking things. Not to mention, you can't independently scale portions of that app.

[-]

goranlepuz@reddit

After a monolithic app reaches a certain point in size and takes on many disparate responsibilities, it becomes hard to reason about, and developing and deploying rather simple changes seems to take a lot longer than it should because of the risk of breaking things.

I find this naive. A complex application is hard to reason about regardless of microservices. If I deploy a new version of a microservice and it has a bug, all parts of the application that use it are affected.

This is where the conceptual modularity of the application is important. If it's not modular in concept, it doesn't matter much if it's a monolith or not.

What is missing, is this: using microservices gently judged people towards better modularity. It's harder to make a mess when components are in different processes and machines. It's still possible, though. But the discipline not to, is still needed.

Not to mention, you can't independently scale portions of that app.

By a long far, the most important reason to use microservices.

[-]

Willblinkformoney@reddit

If you deploy a new version of a microservice and it has a bug, it is easier and quicker to roll that back with less impact on other features that may have been deployed between the broken code and discovery of the bug.

[-]

kylanbac91@reddit

That bug now live inside other services how to rollback that?

[-]

Isogash@reddit

Independently scaling parts of an app is a total myth!

[-]

devsidev@reddit

premature scaling. I also agree that starting as a monolith makes sense. Most people aren't Netflix who absolutely need distributed services. My take is (in order of priority, maturity):

Monolith
Domain organized directories (keep your components isolated and not dependent on other components, a modular monolith if you will.)
Micro-services (only whats necessary and only when you need to see that scale)

Most companies likely don't ever need to get out of step 2, but every so often you a part of a system scales up fast and will need that extra step to micro-services to ensure easy and targeted resource allocation. If you platform needs high availability in an area that is suddenly getting 1000x the usual, a micro-service might be a good way to go. Start small, with something that isn't mission critical to learn the infra and the nuances, then expect a bumpy ride as you transition what you need.

[-]

erwan@reddit

Monolith vs micro services is a false dichotomy.

Once you reach a certain size, it's better to get to a distributed system with multiple services but they don't have to be "micro".

[-]

Awyls@reddit

I never understood why the main talking point about micro-services was and still is about horizontal scaling. At least to me, it should be about improving the development process once you reach a certain team size, the scaling is just the cherry on top.

[-]

No_Dot_4711@reddit

The horizontal scaling used to be true, but the hardware you can get on a single box these days is an order of magnitude more powerful than when they were first popularized

But the single biggest point of microservices is that it allows teams to develop and deploy independently of each other - it's a solution to a sociotechnical problem, not a technical one

[-]

kylanbac91@reddit

develop and deploy independently in theoretically only.

[-]

No_Dot_4711@reddit

yup, people tend to build a distributed monolith a lot of the time, with none of the benefits but all of the drawbacks

bonus points for using the same database

[-]

Isogash@reddit

That they scale any better is a total myth. You can build a monolith that horizontally scales.

[-]

The_Fresser@reddit

It scales better for larger teams though.

It allows teams to work independently, and also updating the services (think major bumps of framework/similar) is easier due to smaller and well-defined boundaries

[-]

kylanbac91@reddit

Until core services need to change.

[-]

syklemil@reddit

Though that can can be very optimistic.

Part of the multi-service strategy is that you can get a separation of concerns, including separate failure modes and scaling strategies. Now, you can put effort into building one monolith and be very strict about separation of concerns into modules that don't have to load, so you can … get to where you would be if you'd just let it be separate services. For the people used to microservices, that just sounds like a lot of extra work, including organisational work, for no particular benefit.

Sometimes the easier option is just to have separate tools, rather than insisting on merging everything into an extremely complex multitool, just because toolboxes sometimes get messy.

Like the actual guy on the podium says, microservices don't really make sense for startups, but they tend to show up in established businesses (especially the ones that have things they consider "legacy"), and at the extreme end of the spectrum they're always present.

As the unix philosophy says: Build small tools that do one thing well.

[-]

oneMoreTiredDev@reddit

I think initially (a decade ago? lol) the a big part of the discussion around microservices was around the tech for obvious reasons

now that tech is not an issue anymore, people got confused (I guess because of lack of experience) and some still think it's a tech decision rather than organizational

[-]

bwainfweeze@reddit

If you have built your monolith for horizontal scaling, you can start splitting it by just running the same code on multiple clusters and routing traffic to certain machines.

“facade” is one of the most misunderstood and misused design patterns. Instead of using it in a fear based manner to avoid committing to an interface or implementation in case you want to change your mind later, you can use it to wrap the old interface with the new way you want the system to behave, then go back and change the code to do just that.

You can do the same to carve out services. Extract modules, make new routes, replace the monolith with the new route + modules. The other team can move onto other things while you finish your extraction.

[-]

jmnemonik@reddit

What does "start as Monolith" mean in this case?

[-]

geckothegeek42@reddit

Man I wish there was a whole video expanding on the thesis presented in the title... Oh well I guess we'll just have to wildly speculate and assume what the presenter meant

[-]

jmnemonik@reddit

In the video he is continuing to say Monolith with no explanation of what that means.... A squeaky voice doesn't help.

[-]

P33sw33t@reddit

This is so dumb. Use the tool for the job. In such circumstances a monolith can be just as complicated with the build system, codegen and interfaces between languages

[-]

bwainfweeze@reddit

You don’t understand the job until it’s halfway done. So how do you presume to know the tools?

“The tools of the job” are: make a small successful system, then start swapping the tools for the ones that work better for medium successful systems, and then see if there is demand for a large successful system, and adjust the tools again.

“The tools for the job” is a 2 dimensional list with time as the second dimension.

[-]

HK-65@reddit

The program structure should follow team structure.

One team doing a small project? Monolith.

Many teams doing a big project? One service per team.

Startup expecting to scale a thousandfold next year? Have one team own multiple services which you each plan to hire for before you inevitably fail like most startups do.

[-]

popiazaza@reddit

This Video Should Have Been A Single Paragraph Of Text

[-]

bwainfweeze@reddit

Do you remember the SNL skit, “stop buying things you can’t afford”?

It’s like that.

[-]

Tintoverde@reddit

Fuck no

[-]

JungsLeftNut@reddit

Why do you think that? Do you think monolith architecture is bad in and of itself or do you think there's a greater percentage of projects which should be started with a microservices architecture in mind?

[-]

abofh@reddit

99% of applications is not 99% of revenue driving applications, and while Google and Microsoft didn't "communicate", they didn't invent engineers, they got them from the same source

If your service is dominated in any direction by a query pattern, break that off and optimize. Don't start by assuming you'll be successful day one, just don't be stupid day one.

I have a team of three+ a contractor managing a system clusters and accounts cross cut across another dozens of services - it scales because it's not a monolith, it hear presents as one.

[-]

grauenwolf@reddit

it scales because it's not a monolith, it just presents as one.

Stateless web servers are already trivial to scale up or out. You don't need microservices to make them scalable. You just need a load balancer.

The amount of ignorance required to believe that microservices are inherently scalable has always boggled my mine. There are many good reasons to use microservices such as separating different stateful processes. But scalability has never and will never be one of them.

[-]

dysfunctionz@reddit

A team of three managing a dozen clusters is fucking insane.

[-]

abofh@reddit

Dev, staging, prod, bonus, multi region and local optimizations as needed. Most clusters don't need individual attention, and when they do, it's attention they've all needed.

Low volume, high value. Missing a click and pissing off one customer can cost millions. We don't have the problem of a billion customers in a second, just one that mattered at the right time.

It gets scarier when I tell you, half that team is process and IT, only the other half really run the clusters. But the clusters are managed by professionals who have done it before, not people who are trying to check the next box on their resume

[-]