401–410 of 468 posts
I'm a bit confused on microservices vs monolith in the modern SPA context. If I have an application that's front end is React and back end is Go and the two communicate over REST/HTTP+RPC, do I have microservices or a monolith?
Of course this advice doesn't always make sense, but it makes sense more often than people want to admit. Not that this is an original claim, if anybody remembers the "majestic monolith." Simply put, the microservice path makes a lot more sense when your organization is so big that you don't really know what other teams are doing all the time and need a clear delineation of areas of responsibility, or maybe if you ha…
Oftentimes however with microservices it's the tail wagging the dog. Microservices architectures become such a burden that they strain the capacity of the existing team which leads to more hiring which thanks to Conway's law leads to more microservices being built which leads to more operational and architectural overhead which leads to more hiring...
There is a lot of talk about monoliths vs microservices lately.. I just want to throw into the ring that you can do both at the same time. easily. And noone is going to kill you for it either. maybe we are getting caught up in sematics because its christmas, but "monorepo/monolith/microservices/etc" is -just- the way you organize your code. Developing a montolith for years but now you have written a 15 line golang ht…
> There is a lot of talk about monoliths vs microservices lately. Actually it's been going on for years, and it's always the same argument. People think they're thought leaders for saying "Start with monoliths and only move to microservices if you absolutely need to!" It's a pretty obvious conclusion to anyone who has worked in both environments, or have had to migrate from one to the other, so it's not particularly…
It should be obvious, but apparently it's not. So many architecture astronauts drinking the kool-aid and making a mess. Premature microservices can easily kill a product.
Earlier quoted context omitted.
At the same time, you have to be at a pretty huge scale before resource over-provisioning really hurts the bottom line. You can buy a lot of compute for the price of a single engineer's salary, and it usually takes more than one engineer to support a microservice architecture. Most applications hit problems scaling the database vertically long before they exhaust resources at the application level.
Hmm I get what you’re saying of course but in certain domains (think B2B SaaS) you might be running some compute-intensive stuff enough to where the differential is an issue. Imagine 95% of your workload can run in 100 megs but 5% requires 1000 megs. You can overprovision of course but in a world of containers if you can isolate the 5% and route it you’re going to have a lot less in terms of operational headaches
The problem is when the lead dev has been huffing the architecture paint too hard and starts prematurely spinning up microservices because it feels good.
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…
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…
Compute, storage, and other services have gotten to the point where they are unlimited, they were originally designed for what was considered monolithic applications. Shared tenancy is not good in the age of multiple dependencies and in terms of security needs for mission-critical applications and data.
Cloud host providers got too eager in seeking to create new lines of business and pushed micro-service architectures far too early to maturity, and now we're just beginning to see it's faults, many which can't be fixed without major changes that will likely make them pretty much useless, or alternatively just similar to monolithic architectures anyway.
Profit and monopolistic goals shouldn't drive this type of IT innovation, solving critical problems should. We shouldn't just throw away all that we've engineered over the past decade and reinvent the wheel... Heck, many liars are still running FINTECH on COBOL.
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…
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…
Micro services make it hard.
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.
I know. Which is why I have architectural tests that scream if someone uses the wrong module from the wrong place (adds a dependency that isn't what we want). Of course, any dev could just remove the test, and by that tear down that boundary too. But that test being removed is much more obvious to the code reviewer who would not have noticed the dependency being snuck in. The architectural tests can also contain comm…
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.
Earlier quoted context omitted.
Ok, maybe a better way to say it is that having teams independently develop services is a good way to reduce the coordination tax if you have high coordination costs. If your environment doesn't have that problem I guess this doesn't apply. Coordination between engineers was a frequent activity everywhere I've been regardless of how well built the systems were. For example: a new requirement for the customers signing…
> Independent teams (each developing independent services and acting without top-down approval) is a different way to coordinate development that values productivity (keeping everyone unblocked) and innovation (finding better ways of doing things). I've had the opposite experience. In the monolith, anyone can make the necessary changes, because it's all one codebase that everyone is familiar with. At most, you might…
Earlier quoted context omitted.
This actually feels like a good example of the modularity that i talked about and feature flags. Of course, in some projects, it's not what one would call a new architecture (like in my blog post), but rather just careful usage of feature flags. > But all those data sources are connected to from the same runtime, right? Surely you could have multiple instances of your monolithic app: # Runs internally app_instance_1_…
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?
Microservices were a half baked solution to a non-problem, partly driven by corporate stupidity and charlotan 'security' experts - I'm sure big companies make it work at enough scale, but everything in a microservice architecture was achievable with configuration and hot-patching. Incidentally, you don't get rid of either with a MCS architecture, you just have more of it with more moving parts...absolute sphegetti mess nightmare.