Don't start with microservices – monoliths are your friend • Hacker News Board

Re: Don't start with microservices – monoliths are your friend

#151

Post by UglyToad » Thu, Dec 16, 2021, 1:00 PM UTC

bayesian_horse wrote: post #118

gmueckl wrote: post #52

Earlier quoted context omitted.

In some languages, you can enforce boundaries within a monolith nicely using the build system. The key is to break the build up into a hierarchically structured set of libraries somehow where each library only gets to use those libraries it is allowed to depend on architecturally. Independent bits of business logic would need to go into libraries that cannot "see" each other when they are compiled. Everything would s…

I think you didn't quite get the point of engineers of different levels of quality, talent and opinions working on the same monoliths. Eventually they tear down any boundary, even those in the build system. Developer discipline is something that eludes many companies for lack of enough high quality engineers and awareness for the problem in upper management. It's easier to quibble over formatting guidelines.

But the problem with this is it's a technical solution to a social problem.

If your developers are writing crap code in a monolith they're going to continue writing crap code in microservices but now you have new problems of deployment, observability, performance, debugging, etc etc.

As an aside I have a sneaking probably ahistorical suspicion microservices hype happened because people realised Ruby (or similar trendy dynamic languages) often ended up being a write only framework and rather than try and recover some codebase sanity people would rather abandon the code entirely and chase the new codebase high.

Re: Don't start with microservices – monoliths are your friend

#152

Post by [deleted] » Thu, Dec 16, 2021, 1:01 PM UTC

baash05 wrote: post #77

verinus wrote: post #29

Earlier quoted context omitted.

I wholeheartedly agree on most parts, with DevOps being the exception. Devs only focusing on developing/writing source code is certainly not the way to produce sustainable, high quality software- at least in my opinion...

I am 100% not interested in ops. Deploying is handled by other way more qualified than I. I never expect a JS expert to build elixir, I don't expect an elixir expert to write bash, and I don't expect a bash expert to know about switches and cabling. I don't understand where you draw the line.. Should the designer who also crafts the css do ops too? I think high quality comes from specialists. Sharp knives in the hand…

[deleted]

Re: Don't start with microservices – monoliths are your friend

#153

Post by bspammer » Thu, Dec 16, 2021, 1:01 PM UTC

goodoldneon wrote: post #136

bspammer wrote: post #93

Earlier quoted context omitted.

> no good reason How about deployment speed? If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule, it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith. It also allows for fine grained permissions: that service can only read from that specific queue and write to that specific bucket. People throw around “d…

Distributed monolith can mean different things. I worked at a place with ~10 services sharing the same DB. It was awful

Yeah that doesn’t sound fun at all

Re: Don't start with microservices – monoliths are your friend

#154

Post by nerdponx » Thu, Dec 16, 2021, 1:01 PM UTC

baash05 wrote: post #77

verinus wrote: post #29

Earlier quoted context omitted.

I wholeheartedly agree on most parts, with DevOps being the exception. Devs only focusing on developing/writing source code is certainly not the way to produce sustainable, high quality software- at least in my opinion...

I am 100% not interested in ops. Deploying is handled by other way more qualified than I. I never expect a JS expert to build elixir, I don't expect an elixir expert to write bash, and I don't expect a bash expert to know about switches and cabling. I don't understand where you draw the line.. Should the designer who also crafts the css do ops too? I think high quality comes from specialists. Sharp knives in the hand…

And this person is a DevOps person, in every org I've ever worked in.

Maybe "before my time" it was a webmaster or other admin. I think of "dev ops" as an umbrella term subsuming many specific titles and roles from the past, much like "data science".

Re: Don't start with microservices – monoliths are your friend

#155

Post by corpMaverick » Thu, Dec 16, 2021, 1:03 PM UTC

armanm wrote: post #31

Monolith and Micro-services at different times during the progression of a business can have their places. I have experienced the pains of having to work with both within the same company over 9+ years and here is what I think are forces that can pull you in either direction. A monolith makes developing initially a lot easier. Over 15 years though, you are bound to have developers of various calibre leave their mark…

> Over 15 years though,...

Correct. That is why the advice not to start with Microservices. Perhaps later may make sense; but not in the beginning.

Re: Don't start with microservices – monoliths are your friend

#156

Post by discreteevent » Thu, Dec 16, 2021, 1:03 PM UTC

Philip-J-Fry wrote: post #142

KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

Splitting code into modules has the same downsides as splitting it into microservices. You can still end up making the wrong splits and needing to back track on things you once thought were modular but no longer are. The logistics of microservices are rarely the hard part. It's the long term maintenance. Everyone who's ever maintained a "core" library knows the same pain, at some point you just end up making sacrific…

> Splitting code into modules has the same downsides as splitting it into microservices.

Not to be pedantic, but it has some of the same downsides. Microservices have other major downsides in that they bring in all the fallacies of network computing. Even if you manage to stabilize these in the end they just waste so much time in development and debugging.

Re: Don't start with microservices – monoliths are your friend

#157

Post by KronisLV » Thu, Dec 16, 2021, 1:04 PM UTC

rp1 wrote: post #145

KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

There is a more serious downside that you don’t mention: splitting things into modules takes time and involves making decisions you likely don’t know the answer to. When starting a new product, the most important thing is to get something up and running as quickly as possible so that people can try it and give you feedback. Based on the feedback you receive, you may realize that you need to build something quite diff…

> There is a more serious downside that you don’t mention: splitting things into modules takes time and involves making decisions you likely don’t know the answer to.

Partially agreed. Domain driven design can help with answering some of those questions, as can drilling down into what the actual requirements are, otherwise you're perhaps reaching for your code editor before even having an idea of what you're supposed to build.

As for the inevitable changing requirements, most of the refactoring tools nowadays are also pretty reasonable, so adding an interface, or getting rid of an interface, creating a new package, or even in-lining a bunch of code isn't too hard. You just need to know how to use your tools and set aside time for managing technical debt, which, if not done, will cause more problems down the road in other ways.

> Speed is often the most important factor.

If you're an entrepreneur or even just a business person who cares just about shipping the feature, sure. If you're an engineer who expects their system to work correctly and do so for the years to come, and, more importantly, remain easy to modify, scale and reason about, then no, speed is not the most important factor.

Some business frameworks like COBIT talk about the alignment between the tech and business, but in my experience their priorities will often be at odds. Thus, both sides will need to give up bits of what they're after and compromise.

If you lean too heavily into the pace of development direction, you'll write unmaintainable garbage which may or may not be your problem if you dip and go work for another company, but it will definitely be someone else's problem. Thus, i think that software engineering could use a bit more of actual engineering it.

Not necessarily 50 page requirement docs that don't conform to reality and that no one cares about or reads, but actually occasionally slowing down and thinking about the codebases that they're working on. Right now, i've been working on one of the codebases in a project on and off for about 4 years - it's not even a system component, but rather just some business software that's important to the clients. In my personal experience, focusing just on speed wouldn't have been sustainable past 1 year, since the codebase is now already hundreds of thousands of lines long.

For a contrast, consider how your OS would work if it were developed just while focusing on the speed of development.

Re: Don't start with microservices – monoliths are your friend

#158

Post by brightstep » Thu, Dec 16, 2021, 1:04 PM UTC

gmueckl wrote: post #132

bayesian_horse wrote: post #118

Earlier quoted context omitted.

I think you didn't quite get the point of engineers of different levels of quality, talent and opinions working on the same monoliths. Eventually they tear down any boundary, even those in the build system. Developer discipline is something that eludes many companies for lack of enough high quality engineers and awareness for the problem in upper management. It's easier to quibble over formatting guidelines.

Code review processes should catch the worst of that. If you don't have those and don't have incredibly disciplined developers, well, good luck...

Code review is usually a bad place to catch design flaws, unless it's done early. Usually a bad design means re-doing a lot of the work. That means either getting management buy in or not hitting expected velocity. If not communicated well it can also lead to bad feelings between the writer and reviewer.

Re: Don't start with microservices – monoliths are your friend

#159

Post by Philip-J-Fry » Thu, Dec 16, 2021, 1:06 PM UTC

dagss wrote: post #128

Philip-J-Fry wrote: post #121

Earlier quoted context omitted.

Yes, this sort of explains my situation. A requirement appears down the line that just completely breaks the service boundaries. An example being something like an online gun store, you have a perfect service that handles orders. It's completely isolated and works fine. But now, 2 years later some local government has asked you "whenever someone buys a gun, you need to call into our webservice the moment the order is…

I would say this is another problem. If an external call to a web service is involved, then you can NEVER have an atomic call in the first place. One always needs to just have a state machine to navigate these cases. Even with a monolith, what if you have a power-off at the wrong moment? What you are describing here is to me pretty much the job description of a backend programmer to me -- think through and prepare fo…

Well that's the thing isn't it. As soon as you move away from the atomicity of a relational database you can't guarantee anything. And then we, like you do to, resort to cleanup jobs everywhere trying to rectify problems.

I think that's one of the things people rarely think of when moving to microservices. Just how much effort needs to be made to rectify errors.

Re: Don't start with microservices – monoliths are your friend

#160

Post by playing_colours » Thu, Dec 16, 2021, 1:06 PM UTC

dlisboa wrote: post #135

KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

Have you seen this done well more than a few times? Honest question because it’s something I think everyone agrees with as being a good idea but it never gets actually done. It’s definitely not an industry practice that big monoliths eventually get split up in modules and quality increases. It’s something you have to fight for and actively pursue. I’ve been on projects with very good developers, who were very bought…

It is not a binary flip between monolith and modular monolith, it is on a gradual scale, and I saw teams moving toward modularity with a various degree of success. They may not even use the term of distributed monolith to name their approach. Sometimes, they do it to keep the monolith maintainable, sometimes as the first steps towards microservices - defining boundaries, simplifying dependencies certainly help against the antipattern of distributed monolith.

Ideally, the decision to build modular monolith should be made and implemented from the very start of the project. Some frameworks like Django help with keeping separation.

I found that fitness functions help with policies and contracts. You run then in your CI/CD and they raise alarm when they detect contract / access violation across the boundaries.