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

Monolith First (2015)

martinfowler.com

Post reply on HN
Print view View original

241–250 of 356 posts

Re: Monolith First (2015)

#241

Post by tootie »

ser0 wrote: post #4

A more common scenario I see is that people start with a monolith that ends up inheriting all the conceptual debt that accumulates as a project evolves. All this debt builds up a great desire for change in the maintaining team. A champion will rise with a clean architecture and design in microservice form that addresses all high visibility pain points, attributing forecasted benefits to the perceived strengths of mic…

I'm living this right now. A big, fat python 2 monolith maintained for 10 years. Everyone hates it, but it actually works perfectly fine.

Re: Monolith First (2015)

#242

Post by acdha »

kevstev wrote: post #239
Mandatum wrote: post #79

Earlier quoted context omitted.

I think my biggest gripe with orgs that adopt microservices is they don't build out any of the testing, CI/CD, monitoring and debugging workflows to support it. It goes from shitty, slow monolithic application that super-pro can debug in a few minutes to.. Slow, shitty disparate services that are managed by different teams who don't share anything, suddenly you've got a Cuckoo's Egg situation where 1 guy needs to get…

So I actually find that microservices should actually help tremendously here? Service A starts throwing 500s. Service A has a bunch of well defined API calls it makes with known, and logged, requests and responses. These responses should be validated on the way in and produce 400s if they aren't well formed. Most 500s IMHO result from the validations not catching all corner cases, or not handling the downstream error…

> So I actually find that microservices should actually help tremendously here? Service A starts throwing 500s. Service A has a bunch of well defined API calls it makes with known, and logged, requests and responses.

This isn’t wrong - although there is a reasonable concern about expanding interconnection problems – but I think there’s commonly a misattribution problem in these discussions: a team which can produce clean microservices by definition has a good handle on architecture, ownership, quality, business understanding, etc. and would almost certainly bring those same traits to bear successfully for a more monolithic architecture, too. A specific case of this is when people successfully replace an old system with a new one and credit new languages, methodology, etc. more than better understanding of the problem, which is usually the biggest single factor.

Fundamentally, I like microservices (scaling & security boundaries) but I think anything trendy encounters the silver bullet problem where people love the idea that there’s this one weird trick they can do rather than invest in the harder problems of culture, training, managing features versus technical debt, etc. Adopting microservices doesn’t mean anyone has to acknowledge that the way they were managing projects wasn’t effective.

Re: Monolith First (2015)

#243

Post by anticristi »

I'm wondering if "microservices" hasn't lost it's initial meaning. To me, an application composed of the "core", a message queue and a database server already qualifies as "microservices". I know which parts are "delicate" and which parts are "kill-at-will". That is what I care about at a very high level, not having a separate codebase for every single HTTP route.

Re: Monolith First (2015)

#244

Post by haskellandchill »

hcarvalhoalves wrote: post #188

IMO this is an unnecessary dichotomy that we're currently forced to deal with, because we don't yet have a good solution for programming the "cloud" the same way you program a for a single computer, and that ends up leaking into all the consequent decisions of modularisation, performance, code management, deployment, team organisation, etc. (My holy grail would be programming for distributed environments as if you ha…

Have you seen Unison language? They are positioned as a solution to what you are describing.

Re: Monolith First (2015)

#246

Post by arwhatever »

nojvek wrote: post #210

Most common architecture for SAAS apps is a frontend served from cdn + frontends served by app stores, an api server behind app load balancer (e.g nginx), a database cluster, and a bunch of async long lived cron jobs + on demand jobs. In that architecture you don’t need that many Microservices. The api server is prolly the most important bit and can be served as a monolith. Many 10B+ companies use this architecture.…

I’ve seen Separation of Concerns used as a “killer argument” in many a planning meeting, but reminder it needs to be weighed against the cost of being (un)able to test and validate the entire system atomically.

Re: Monolith First (2015)

#247

Post by marcosdumay »

NationalPark wrote: post #197
marcosdumay wrote: post #185

Earlier quoted context omitted.

> But distributed systems is a well understood thing in the industry. Wait, what? Distributed systems are one of the most active areas on CS currently. That's the opposite of "well understood". It's true that most systems people create are required to be distributed. But they are coordinated by a single database layer that satisfies approximately all the requirements. What remains is an atomic facade that developers…

Distributed systems are well understood though. We have a lot of really useful theoretical primitives, and a bunch of examples of why implementing them is hard. It doesn't make the problems easier, but it's an area that as you say, has a ton of active research. Most engineers writing web applications aren't breaking new ground in distributed systems - they're using their judgement to choose among tradeoffs.

Well understood areas do not have a lot of active research. Research aims exactly to understand things better, and people always try to focus it on areas where there are many things to understand better.

Failure modes in distributed systems are understood reasonably well, but solving those failures is not, and the theoretical primitives are way far from universal at this point. (And yes, hard too, where "hard" means more "generalize badly" than hard to implement, as the later can be solved by reusing libraries.)

The problem is that once you distribute your data into microservices, the distance from well researched, solved ground and unexplored ground that even researchers don't dare go is extremely thin and many developers don't know how to tell the difference.

Re: Monolith First (2015)

#248

Post by treis »

jimbokun wrote: post #218
Mavvie wrote: post #212

Earlier quoted context omitted.

> different parts of the monolith's functionality need to scale independently, I hear this a lot. Can you give me an example? Can't I just add more pods and the "parts" that need more will now have more? Agreed on the other reasons (although ideally the entire monolith should be CI/CD so release cadence is irrelevant, but life isn't perfect)

So the alternative is to have a monolith deployed with different "identities" based on how it's configured. So you configure and scale out different groups of the monolith code independently, to satisfy different roles and scale up or down as needed. However, sometimes the resources needed to load at start up can be drastically different, leading to different memory requirements. Or different libraries that could con…

>For a large monolith, this can be significant.

If we are at this point we aren't really talking about microservices though. More like taking a gigantic monolith and breaking it up into a handful of macroservices.

Re: Monolith First (2015)

#249

Post by acdha »

bulleyashah wrote: post #200
pjc50 wrote: post #167

Earlier quoted context omitted.

> Monoliths are also distributed systems and will run on multiple hosts ... not necessarily. Although the big SPOF monolith has gone out of fashion, do not underestimate the throughput possible from one single very fast server.

Well, no matter how fast a single server is, it can't keep getting faster. You might shoot yourself in the foot by optimizing only for single servers because eventually you'll need horizontal scaling and it's better to think about it in the beginning of your architecture.

> eventually you'll need horizontal scaling

This is far from inevitable. There are tons of systems which never grow that much - not everyone works at a growth-oriented startup - or do so in ways which aren’t obvious when initially designing it. Given how easily you can get massive servers these days you can also buy yourself a lot of margin for one developer’s salary part time.

Re: Monolith First (2015)

#250

Post by jameshart »

pjmlp wrote: post #214
jameshart wrote: post #190

Earlier quoted context omitted.

It is possible that there are architectures other than ‘monolith’ and ‘microservices’. Component architectures are also a thing. If it doesn’t all deploy in one go, I don’t think it’s a monolith.

Certainly, the microservices cargo cult has ensured that everything that isn't a microservices, is now a monolith.

And apparently distributed RPC is ‘microservices’.

I think we can all agree that straw man architectures don’t work. Everyone should employ the true Scotsman architecture.

Post reply on HN