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

261–270 of 356 posts

Re: Monolith First (2015)

#261

Post by typescriptfan1 »

ivanb wrote: post #33

Now that Fowler himself wrote about it I hope that the masses follow. Next I hope that the trend of going vertical-first comes back. Mr Fowler, could you please write an article on vertical-first scaling?

Lack of engineering talent + accessibility of the cloud + buzz words got us here. Looking forward to the end of this cycle.

This is somewhat reminiscent of the abuse of higher level languages and the mindset computers are so powerful there's no need to think too hard. However, the consequences are no longer limited to a slow and buggy program but many slow and buggy programs and a large AWS bill too!

Re: Monolith First (2015)

#262

Post by ngngngng »

technics256 wrote: post #153
ngngngng wrote: post #14

With this in mind, if I were to start a new project today (using Go, which is all I use anymore). I would segment my code inside of a monolith using interfaces. This would incur a very slight initial cost in the organization of the codebase prior to building. As your usage goes up and the need to scale parts of it increases, you could swap these interfaces out little by little by reimplementing the interface to conta…

As someone who is new to Go and learning actively, do you have an example of how this would look?

Sure. First you'll need to familiarize yourself with interfaces in go. This link explains them well.

https://gobyexample.com/interfaces

So a struct satisfies an interface if it implements all of the methods of the interface. The example you see in the above link is a monolithic design. Everything only exists in one place and will be deployed together.

So if the functions for circle were getting hit really hard and we wanted to split those out into their own microservice so that we could scale up and down based on traffic, it would look something like this. https://play.golang.org/p/WOp0RL-pVg3

There we have externalCircle which satisfies the interface the same way circle did, but externalCircle makes http calls to an external service. That code won't run because it's missing a thing or two, but it shows the concept.

Re: Monolith First (2015)

#263

Post by deckard1 »

staticassertion wrote: post #252
dimitrios1 wrote: post #198

Earlier quoted context omitted.

"microservices turn function calls into distributed computing problems" -- tenderlove

This isn't really true though. It's not like you're suddenly adding consensus problems or something, you don't need to reinvent RAFT every time you add a new service. Microservices put function calls behind a network call. This adds uncertainty to the call - but you could argue this is a good thing. In the actor model, as implemented in Erlang, actors are implemented almost as isolated processes over a network. You c…

> putting things behind a network can, counter intuitively, lead to more resilient systems

Erlang without a network and distribution is going to be more resilient than Erlang with a network.

If you're talking about the challenges of distributed computing impacting the design of Erlang, then I agree. Erlang has a wonderful design for certain use cases. I'm not sure Erlang can replace all uses of microservices, however, because from what I understand and recall, Erlang is a fully connected network. The communication overhead of Erlang will be much greater than that of a microservice architecture that has a more deliberate design.

Re: Monolith First (2015)

#264

Post by gqewogpdqa »

collyw wrote: post #163
a_imho wrote: post #129

Earlier quoted context omitted.

More generous take on the meta: people do understand (some of) the problems involved but are less worried about debugging scenarios than resume padding. The most useful property of microservices is architecturing CVs.

Yep. I am working on a Mongo system, started right about when Mongo was peak hype. This application should be using a relational database, but no resume padding for the original developer, and a ton of tech debt and a crappy database for me to work with.

What are the characteristics that make it more relational than non-relational?

Re: Monolith First (2015)

#266

Post by pjmlp »

jameshart wrote: post #250
pjmlp wrote: post #214

Earlier quoted context omitted.

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.

It is how a large majority of microservices gets implemented in practice.

What was originally a package, gets its own process and REST endpoint, sorry nowadays it should be gRPC, the network boilerplate gets wrapped in nice function calls, and gets used everywhere just like the original monolith code.

Just like almost no one does REST as it was originality intended, most microservices end up reflecting the monolith with an additional layer of unwanted complexity.

Re: Monolith First (2015)

#267

Post by jblwps »

wiremine wrote: post #206
fvdessen wrote: post #60

Earlier quoted context omitted.

It is much harder to enforce the discipline of those practices across modules boundaries than around network boundaries. So in theory yes you could have a well modularized monolith. In practice it is seldom the case. The other advantage of the network boundary is that you can use different languages / technologies for each of your modules / services.

> 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 with gRPC and connect to localhost?

Is there something I'm missing?

Re: Monolith First (2015)

#268

Post by brokencode »

A microservice architecture should mainly be used to solve runtime issues, such as to improve scalability or fault tolerance. Also, it can be useful in order to adopt new languages or frameworks.

It is not something that should be used simply to clean up your code. You can refactor your code in any way you see fit within a monolith. Adding a network later in between your modules does not make this task simpler.

Re: Monolith First (2015)

#270

Post by mlthoughts2018 »

k__ wrote: post #157
mlthoughts2018 wrote: post #154

Earlier quoted context omitted.

The article doesn’t have any connection to monorepo / polyrepo axis. You can use either repo structure for a monolith application, or use either repo structure for separated microservices. The article is just not related to repo structure in any way.

I'd say, that's the problem with that article.

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