Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't start with microservices – monoliths are your friend

arnoldgalovics.com

Post reply on HN
Print view View original

161–170 of 468 posts

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

#161

Post by mrweasel »

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…

> I am 100% not interested in ops

I suspect you don't mean it like that, but developers have to care just a little about operations. There's the classic stuff about developers who build stuff, because they didn't realize that ops could do the same with a few lines in a web server config, so they waste weeks on trivial stuff. There's also the issue that if you expect databases, queues, disks and so on to just be available, while not thinking about how you use them, then you can get bad performance or cause downtime and crashes in the worst case.

The initial idea of DevOps also seems to have been twisted to having developers do operations, rather than having the two teams work in tandem. If we absolutely must combine the two roles, I'd be more comfortable having operations do development work, but that hardly ideal either.

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

#162

Post by cbetti »

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…

Patterns and automation supporting modularization hasn't received the attention that patterns and automation around services has over the past 10 years.

In practice, modularization raises uncomfortable questions about ownership which means many critical modules become somewhat abandoned and easily turn into Frankensteins. Can you really change the spec of that module without impacting the unknown use cases it supports? Tooling is not in a position to help you answer that question without high discipline across the team, and we all know what happens if we raise the question on Slack: crickets.

Because services offer clear ownership boundaries and effective tooling across SDLC, even though the overheads of maintenance are higher versus modules, the questions are easier and teams can move forward with their work with fewer stakeholders involved.

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

#163

Post by [deleted] »

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…

[deleted]

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

#164

Post by qaq »

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…

If a team is not disciplined/skilled enough to build a well structured monolith the chances they can build and support a microservices solution which is a distributed system with orders of magnitude more failure modes and requires an order of magnitude more tooling and testing is pretty much 0.

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

#165

Post by dathinab »

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…

I think anyone who speaks about monolith today assumes you do use modules appropriately.

I mean for "starting with a monolith and splitting out when necessary" you kind need property structures code (i.e code which uses modules and isn't too tightly coupler between them).

Through in my experience you should avoid modularizing code with the thought of maybe splitting it into parts later on. That's kinda defeats the point of starting with a monolith to some degree. Instead modularize it with the thought of making it easy to refactor and use domain logic as main criterium for deciding what goes where when possible ( instead of technical details).

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

#167

Post by francasso »

For the life of me, I never understood, nor will ever understand, why people think making RPCs is easier or leads to better design than making normal function calls ("split your code into microservices, it will make your code modular, smaller and easier to understand!").

There are legitimate reasons to put a network between one piece of code and another, but "modularity" is not one of them.

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

#169

Post by dathinab »

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…

> splitting things into modules takes time and involves making decisions you likely don’t know the answer to.

The first thought I had when I read this was the thought of being horrified about people not using modules to structure their code.

Then I realized that in some languages creating/changing modules is quite a bit of work and some organizations might have rules making it worse.

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

#170

Post by madsbuch »

KronisLV wrote: post #99
vbezhenar wrote: post #84

Earlier quoted context omitted.

Kek. Auth: nobody knows IP address of our server anyway, don't bother with that. And for extra security we have secret port number. Monitoring? Well, we have our clients for that. They'll call us if something happens. Deploy? Copy .war file and restart tomcat. Rollback? What's rollback? Outdated packages? We call those stable packages. I wish I would work in a miracle world you describe.

It's easy to be snarky and dismissive about these things, but i've stood in the offices of a governmental org and have looked at people who are unable to receive their healthcare services queueing up because some similarly neglected system refused to work. One that also had a lot of the basics left out. Figuring out what was wrong with it was hard, because the logging was inconsistent, all over the place in where it…

Not so much snarky as a commentary on the diligence.

Yes, if there is mission critical software that affects millions of people, do all that stuff.

If your pdf -> stardust service is more a convenience then don't spend hundreds of thousands on infrastructure.

Post reply on HN