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

121–130 of 356 posts

Re: Monolith First (2015)

#121

Post by runeks »

mstipetic wrote: post #17

I keep saying this every time this topic comes up, have a look at elixir/erlang. The OTP library gives some great reusable patterns (and elixir project is adding new ones[1]) out of the box. You're basically developing a single codebase microservice project which feels like a monolith. You can spread out on multiple machines easily if you need to, the introspection tooling is better than anything you can buy right no…

How does versioning work? Is it required that all VM instances run the same version?

Re: Monolith First (2015)

#123

Post by ramchip »

why_Mr_Anderson wrote: post #76
mstipetic wrote: post #17

I keep saying this every time this topic comes up, have a look at elixir/erlang. The OTP library gives some great reusable patterns (and elixir project is adding new ones[1]) out of the box. You're basically developing a single codebase microservice project which feels like a monolith. You can spread out on multiple machines easily if you need to, the introspection tooling is better than anything you can buy right no…

And Erlang runtime) is used in massive telephone switches, famously AXD301 which is claimed to have uptime percentage of 99.9999999% over 20 years.

It's unfortunate that this number stills gets thrown around: https://stackoverflow.com/a/26447543

Re: Monolith First (2015)

#126

Post by b-pixel »

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…

This is the way. Interfaces for modularity and leveraging nested packages within the monolith to keep code decoupled and organized.

Re: Monolith First (2015)

#128

Post by eerikkivistik »

foreigner wrote: post #3

I'm embarrassed to say that I recently built microservices first, and am now kicking myself as I merge them back in to a monolith.

The most amazing thing I saw with a microservices first approach was someone building a betting system with microservices. So if you made a bet, one microservice would make an http call to another to request your balance, make a decision based on that and then move the funds. No locks, no transactions, no nothing. I wasn't sure whether to laugh or cry. Fortunately I got there in time before this thing was launched...

Re: Monolith First (2015)

#129

Post by a_imho »

pjmlp wrote: post #31
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…

When the same practices used to sell microservices get applied to modules, packages and libraries, there is no need to put a network in the middle to do the linker's job. But too many are eager to jump into distributed computing without understanding what they are bring into their development workflow and debugging scenarios.

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.

Re: Monolith First (2015)

#130

Post by mcny »

npteljes wrote: post #114
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…

I think this nails it. It's not the concept's fault if the implementation is half-assed.

> It's not the concept's fault if the implementation is half-assed.

worse than that. Case in point: a major US national bank interview for a developer position. they talk about moving toward microservices. a simple question since they mention microservices: will someone be able to access and modify data data underneath my service without going through my service? the uneasy answer: yes, it does and will happen.

that's the end of the interview as far as I am concerned.

If you can access and modify the underlying data store from my micro service, not only it isn't a micro service, it isn't much of a service oriented architecture. this isn't me being a purist, just being practical. If we need to coordinate with five different teams to change the internal implementation of my "microservice", what is the point of doing service oriented architecture? all the downside with zero upside?

Post reply on HN