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

331–340 of 356 posts

Re: Monolith First (2015)

#331

Post by fendy3002 »

lmilcin wrote: post #291
measure2xcut1x wrote: post #120

Earlier quoted context omitted.

> There are actually ways to manage huge monolithic application that don't require each team to have their own repository, ci/cd, binary, etc. Would be interested to hear about some of these.

The basic technique is to use modular architecture. You divide your application into separate problems each represented by one or more modules. You create API for these modules to talk to each other. You also create some project-wide guidelines for application architecture, so that the modules coexist as good neighbors. You then have separate teams responsible for one or more modules. If your application is large eno…

Perfectly described! People forget or don't know that there are many different architecture across monolithic systems, or that there are something in between monolith and microservice.

Re: Monolith First (2015)

#332

Post by hackerfromthefu »

radicalbyte wrote: post #53
andy_ppp wrote: post #26

Earlier quoted context omitted.

This! Service boundaries are vital and almost intractable to design up front as you won’t be sure of your systems’ use cases. I’ve worked on numerous micro services systems and all of them were designed in such a way that data loss and unknown error states were mandatory. Micro services seem simpler, but are actually harder than my methodology “as few services as necessary” + bounded contexts within them. Using netwo…

This is why Domain Driven Design should be mandatory reading for all anyone making decisions on Software Architecture.

Unfortunately in actual practise I've encountered significant cargo culting about DDD. Attracts a lot of people with mid level experience who suddenly want to dictate architecture based on theoretical ideals rather than practicalities.

There's no substitute for experience, and specifics of adapting architecture to the context of the problem you're trying to solve.

In one case I wanted to use a technology that actually matches DDD very significantly - but the cargo cultish closedmindedness of the practitioners meant they couldn't even understand how an old idea/tech they hadn't liked or approved was, was actually an implementation of DDD.

The problem there is not DDD, the problem is the people who get closed minded and stuck to their one true way (often without really broad experience to make that judgement call effectively). I've learned that pattern of language of absolutes such as 'should be, mandatory, all' do XXX is often a sign of that kind of cargo cultish thinking.

Re: Monolith First (2015)

#333

Post by mlthoughts2018 »

k__ wrote: post #275
mlthoughts2018 wrote: post #270

Earlier quoted context omitted.

That wouldn’t make sense, given that repo structure truly is unrelated in any way to the distinctions between monolith applications vs microservices.

But it is. If you have multiple services in one repo it's much easier to work on each of them.

No, it is not easier. Working on them across multiple repos is just as easy. In either case you write dev tools to apply changes across units. If the units are repos, it adds no additional complexity.

Re: Monolith First (2015)

#334

Post by andrewflnr »

playing_colours wrote: post #322
throwaway894345 wrote: post #292

Earlier quoted context omitted.

> replicate the whole fault tolerant culture and ecosystem I think the idea is to move the general SaaS industry from the local monolith optimum to the better global distributed optimum that Erlang currently inhabits. Or rather, beyond the Erlang optimum insofar as we want the benefits of the Erlang operation model without restricting ourselves to the Erlang developer/package ecosystem. So yeah, the broader "micro se…

Can you please elaborate on specific principles behind Erlang operation model that other platforms can embrace?

Not exactly sure what bits GP is referring to, but IMO this is a good summary of what makes Erlang work: https://ferd.ca/the-zen-of-erlang.html

Re: Monolith First (2015)

#335

Post by woutr_be »

ecmascript wrote: post #293
woutr_be wrote: post #62

Earlier quoted context omitted.

Was the rewrite to microservices really the problem here? I’ve worked on a few such projects too, where we decided to rewrite the application, but it never ended up replacing the old existing one. Technology was never the issue in all these.

Most likely not, the new guys were phd-types that was ultra smart but did nothing except have meetings. I think they were over-engineering it completely which made it impossible to deliver something of value. However, I think that is often the case of a microservices architecture.

> Most likely not, the new guys were phd-types that was ultra smart but did nothing except have meetings.

There's your problem, regardless of architecture, it would most likely have been over-engineered anyway.

Re: Monolith First (2015)

#336

Post by sriku »

A bit of a shameless plug, but really looking for feedback .. I've been experimenting with Inai [1][2], a framework that can help build modular microservice-like software with similar Dev team independence properties but can independently be built and deployed as a monolith or as separate services operationally. So far, I've had fun building an internal project at much higher speed than I've managed any similar project and had more fun doing it. I feel the idea (which is still nascent) has some merit, but would like to know what folks think.

[1] source - https://github.com/Imaginea/Inai

[2] blog post describing Inai - https://labs.imaginea.com/inai-rest-in-the-small/

PS: I've had some difficulty characterising Inai (as you can tell).

Re: Monolith First (2015)

#337

Post by morelisp »

luhn wrote: post #257
bernawil wrote: post #203

But how monolithic were our monoliths anyway? Take your bog-standard ecommerce solution, built with a LAMP stack. Okay, we've got a php process. Let's put our business logic there. Okay, I need a database. With current cloud practices, that's probably going to be deployed in a different machine. We've got our business logic service and our datastore separated by a network bound from the get go. Okay this is not very…

Yeah, that's a terrible idea, so don't do something like that. You don't need to break up your monolith to run cronjobs. My setup: I have async worker running alongside my application. Same codebase, same environment, same monolith, just instead of accepting HTTP requests it pops tasks off a queue. The framework handles retrying/reprocessing/failure. To run cron tasks, I have CloudWatch Events -> SNS -> HTTP endpoint…

Now you need to upgrade. Your HTTP request handling takes like maybe 2s at most bring up a new instance and drain the old one. But you have one daily cron job that takes eight hours, and another that only takes 1s but needs to run hourly.

Now you need to upgrade to a new version, which requires an incompatible DB migration affecting the request handling and the hourly job. The long job started at 2PM. How do you do the upgrade, without someone needing to stay late?

(If it's e.g. PHP this gets even worse due to lazy package loading, you don't need a DB migration just a changed import path.)

I'm not a fan of microservices, especially the ridiculous factoring I see in lambda-style approaches today. But one of our biggest PITAs was a "horizontally scalable monolith" that after 7 years has accrued so so many responsibilities it's either impossible to find a time slot for an upgrade with zero/low downtime, or we have to plan & develop dealing with shared storage where half may upgrade one day and half the next - all the operational overhead of SOA without the benefits.

Re: Monolith First (2015)

#338

Post by pjmlp »

jblwps wrote: post #267
wiremine wrote: post #206

Earlier quoted context omitted.

> So in theory yes you could have a well modularized monolith. I've often wondered if this is a pattern sitting underneath our noses. I.e., Starting with a monolith with strong boundaries, and giving architects/developers a way to more gracefully break apart the monolith. Today it feels very manual, but it doesn't need to be. What if we had frameworks that more gracefully scaled from monoliths to distributed systems?…

Aren't you just describing traditional RPC calls? Many tools for this: DBus on Linux, Microsoft RCP on Windows, and more that I'm not aware of. If you've only got a basic IPC system (say, Unix domain sockets), then you could stream a standard seriaization format across them (MessagePack, Protobuf, etc.). To your idea of gracefully moving to network-distributed system: If nothing else, couldn't you just actually start…

You are missing the network.

When you start with gRPC and connect to localhost, usually the worst that can happen with a RPC call is that the process crashes, and your RPC call eventually times out.

But other than that everything else seems to work as a local function call.

Now when you move the server into another computer, maybe it didn't crash, it was just a network hiccup and now you are getting a message back that the calling process is no longer waiting, or you do two asynchronous calls, but due to the network latency and packet distribution, they get processed out of order.

Or eventually one server is not enough for the load, and you decide to add another one, so you get some kind of load mechanism in place, but also need to take care for unprocessed messages that one of the nodes took responsibility over, and so forth.

There is a reason why there are so many CS books and papers on distributed systems.

Using them as mitigation for teams that don't understand how to write modular code, only escalates the problem, you move from spaghetti calls in process, to spaghetti RPC calls and having to handle network failures in the process.

Re: Monolith First (2015)

#339

Post by pjmlp »

ChiefOBrien wrote: post #233
wiremine wrote: post #206

Earlier quoted context omitted.

> So in theory yes you could have a well modularized monolith. I've often wondered if this is a pattern sitting underneath our noses. I.e., Starting with a monolith with strong boundaries, and giving architects/developers a way to more gracefully break apart the monolith. Today it feels very manual, but it doesn't need to be. What if we had frameworks that more gracefully scaled from monoliths to distributed systems?…

If you develop with COM in mind, then it doesn't matter whether the object is in-process or somewhere on the network.

That is the selling theme of DCOM and MTS, CORBA and many other IPC mechanisms, until there is a network failure of some sort that the runtime alone cannot mitigate.

Re: Monolith First (2015)

#340

Post by mark_l_watson »

Thank you Martin. I have argued against micro services for writing systems (until you really need them) for a while and get real pushback.

For me, the issue is that a monolith based on, for example, Apache Tomcat using background work threads let’s me also handle background tasks in one JVM. I have not used this pattern in a long time, but when I did it served me well.

I think Java and the JVM are more suitable for this than Python and a web framework. I tried this approach with JRuby one time using background worker threads but I wouldn’t use CRuby.

Post reply on HN