I'm curious, has anyone leveraged bazel's package visibility rules to improve isolation within a monolith? one of the things i don't like about monoliths is that tight coupling is often silent rather than noisy, whereas if someone is editing package visibility rules to make library internals A visible to package B i know exactly what's going on.
Don't start with microservices – monoliths are your friend
361–370 of 468 posts
Re: Don't start with microservices – monoliths are your friend
#362IMO, the big advantage of microservices over monoliths (if they're done right) is reducing iteration times. It's just a lot quicker to build/run/etc. I think monoliths are a fine starting point but once your iteration times get slow, that's when it's time to break it up.
It's a big tradeoff for maintenance complexity and cognitive load though, and people often don't realize how big that tradeoff is. Chasing bugs and maintaining the spiderweb of network connections between all your services can quickly become a nightmare. A distributed ball of mud instead of a monolithic ball of mud, but a ball of mud nonetheless. Personally I lean towards building a monolith first, then breaking out…
Yeah, I don't think there's really a best approach here. I know where I work right now, we have this giant java app that is just a nightmare to even get running. I've been working on the microservices, and they do have all the downsides you're talking about, but I can get that stack up and flying super fast, whereas this giant java app takes 3 minutes to even be (barely) functional, and has so many configuration options that out of this 1000 line config file it's hard to find the 3 things you might actually care about.
Re: Don't start with microservices – monoliths are your friend
#363Guy who hates micro services here (worked at a startup that tried to adopt them because the CTO's consulting friend who works in enterprise convinced him of how great it was). From what I can tell, micro services are primarily a solution to an organizational problem and not a technical one and I think people trip over this. If you have 600 developers working on the same back-end then you can benefit from micro servic…
> There are rare technical reasons to choose micro services
Is this just the difference between working in an infrastructure oriented space vs. product oriented? in infrastructure i find that it is often the case that most logical applications should be decomposed into multiple services given scaling and blast radius concerns where having everything in a single application would increase the impact of outages.
Re: Don't start with microservices – monoliths are your friend
#364Earlier quoted context omitted.
Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…
The interesting thing about microservices is not that it lets you split up your code on module boundaries. Obviously you can (and should!) do that inside any codebase. The thing about microservices is that it breaks up your data and deployment on module boundaries. Monoliths are monoliths not because they lack separation of concerns in code (something which lacks that is not a ‘monolith’, it is what’s called a ‘big b…
I'd like to challenge one part of your comment - that microservices break up data on module boundaries. Yes, they encapsulate the data. However, the issue that causes spaghettification (whether internal to some mega monolith, across modules, or between microservices), is the semantic coupling related to needing to understand data models. Dependency hell arises when we need to share an agreed understanding about something across boundaries. When that agreed understanding has to change - microservices won't necessarily make your life easier.
This is not a screed against microservices. Just calling out that within a "domain of understanding", semantic coupling is pretty a fact of life.
Re: Don't start with microservices – monoliths are your friend
#365I 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…
Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…
My theory is that microservices became vogue along with dynamically typed languages. Lack of static types means that code becomes unmanageable at a much lower level of complexity. So the complexity was "moved to the network", which looks like a clear win if you never look outside a single component.
Re: Don't start with microservices – monoliths are your friend
#366Earlier quoted context omitted.
Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…
My theory is that microservices became vogue along with dynamically typed languages. Lack of static types means that code becomes unmanageable at a much lower level of complexity. So the complexity was "moved to the network", which looks like a clear win if you never look outside a single component.
I've wondered if it's not a ploy by cloud vendors and the ecosystem around them to increase peoples' cloud bills. Not only do you end up using many times more CPU but you end up transferring a lot of data between availability zones, and many clouds bill for that.
A microservice architecture also tends to lock you into requiring things like Kubernetes, further increasing lock-in to the managed cloud paradigm if not to individual clouds.
Re: Don't start with microservices – monoliths are your friend
#367Earlier quoted context omitted.
You're talking about something very odd here... a monorepo, with a monolithic build output, but that... transforms into any of a number of different services at runtime based on configuration? Is this meant to be simpler than straight separate codebase microservices?
It’s not that odd. Databases, print servers, or web servers for example do something similar with multiple copies of the same software running on a network with different settings. Using a single build for almost identical services running on classified and unclassified networks is what jumps to mind.
To what end?
Code reuse?
Re: Don't start with microservices – monoliths are your friend
#368Earlier quoted context omitted.
Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…
My theory is that microservices became vogue along with dynamically typed languages. Lack of static types means that code becomes unmanageable at a much lower level of complexity. So the complexity was "moved to the network", which looks like a clear win if you never look outside a single component.
If you go with static languages you are pretty much stuck with Microsoft or Oracle, both which are ahole companies who cannot be trusted. There is no sufficiently common 3rd static option, at least not tied to Big Tech.
Re: Don't start with microservices – monoliths are your friend
#369Every time I open the site and it pops up some weird "subscribe to this and that awesome content" in my face, I immediately close it. Each time I really hope that owner has some analytics set up and they will learn that having this thing is not a good thing to do to your readers.
Same, I wonder why they keep doing it. Are they fine upsetting 50% of the users so that 5% subscribe? Or am I underestimating the sign-up rate?
Re: Don't start with microservices – monoliths are your friend
#370You have to sprinkle some fads in, or else nobody will touch because it doesn't have enough resume-able buzzwords.