[deleted]
Monolith First (2015)
31–40 of 82 posts
Re: Monolith First (2015)
#32[deleted]
Re: Monolith First (2015)
#33Just see things like Redpanda, Cloudflare, etc.
These complex systems are made easier by being built as a single binary
Re: Monolith First (2015)
#34I like to follow a pattern I call monomicro. Basically I develop separate programs for different functionality, but make them embeddable so they can be composed and run in the same memory space for small deployments. The code that runs https://lastlogin.net is a good example. For LastLogin it runs as a globally distributed cluster on fly.io, but it's also fully embeddable in any Golang program to act as an auth layer.
Re: Monolith First (2015)
#35Earlier quoted context omitted.
Kind of side steps the fundamental scaling issue though. In a banking app there will be more requests for the account balance than there are logins, but logins will likely take longer. Your argument is more around who is allowed to touch which and who is responsible when it breaks, but not around one of the core reasons to choose microservices.
You scale the whole thing. There's no issue at all.
To what end? To support that 1:10000 transaction that takes the most time and needs the most scaling? Just burn a wad of $20s, that will be easier.
Re: Monolith First (2015)
#36Earlier quoted context omitted.
A monolith is not a single microservice.
Any arguments to support this claim? What's the difference then? If there is three communicating servces: first has 90% of the business logic, second has 7%, and the last one has 3%. Should we call the first one a monolith? And if they don't communicate?
> Any arguments to support this claim? What's the difference then?
The "micro" in "microservice".
Microservices are meant to do one "micro" thing well, whether it's image hosting or credit card transactions or supplying the content of a tweet or whatever.
A monolith does all the things, or most of the things. It's not "micro".
You don't need arguments to support it, these are just the definitions of the terms. It's semantics.
A monolith can't be a single microservice because it's not micro.
Re: Monolith First (2015)
#37I firmly believe that monolith vs microservice is much more a company organization problem than a tech problem. Organize your code boundaries similar to your team boundaries, so that individuals and teams can move fast in appropriate isolation from each other, but with understandable, agreeable contracts/boundaries where they need to interact. Monoliths are simpler to understand, easier to run, and harder to break -…
Yep. Conway's law [1]:
Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
— Melvin E. Conway, How Do Committees Invent?
Re: Monolith First (2015)
#38I firmly believe that monolith vs microservice is much more a company organization problem than a tech problem. Organize your code boundaries similar to your team boundaries, so that individuals and teams can move fast in appropriate isolation from each other, but with understandable, agreeable contracts/boundaries where they need to interact. Monoliths are simpler to understand, easier to run, and harder to break -…
Kind of side steps the fundamental scaling issue though. In a banking app there will be more requests for the account balance than there are logins, but logins will likely take longer. Your argument is more around who is allowed to touch which and who is responsible when it breaks, but not around one of the core reasons to choose microservices.
Can you be more specific? Because if you mean scale... meh.
For the most part, scaling a system is fungible across features. In particular, in a monolithic system, if I had to add another server due to logins, I just add another server. A side benefit is if logins are down but account balance checks are up, that extra server can pull that duty too. I don't need to say "these computing resources are only for this feature."
Isolating failures is way more important.
Re: Monolith First (2015)
#39Earlier quoted context omitted.
You scale the whole thing. There's no issue at all.
To what end? To support that 1:10000 transaction that takes the most time and needs the most scaling? Just burn a wad of $20s, that will be easier.
Yes. It's better than burning £100ks by over complicating things and wasting your developer's time.
Most startups fail. You need to cover as much ground as possible while you have runway, not cock about with microservices.
Re: Monolith First (2015)
#40Earlier quoted context omitted.
Any arguments to support this claim? What's the difference then? If there is three communicating servces: first has 90% of the business logic, second has 7%, and the last one has 3%. Should we call the first one a monolith? And if they don't communicate?
You can have a single codebase, deployed in multiple kind of configurations One code, multiple roles
I mostly use statically linked monorepos with microservices. The services use the common utils from the repo. What's the difference except for not having dead code and unused dependencies in the artifacts in my case?