My crazy advice: Build a monolith as microservices.<p>By which I mean focus on Domain Driven Development, focus strongly on modularity even when, and this is the key part, it's not required because it's in a monolith.<p>There are a great deal of advantages to microservices like teams being able to focus on a subset that can still be accomplished with a well designed monolith. While still avoiding the biggest headaches with microservices like managing a crazy network of deployments, across multiple environments where teams don't have the neccessary discipline to communicate.<p>If at a certain point scalability does become a big enough issue, then it's much more manageable to segment what's needed (and even transition back if needed). It still might take months, but the quality of the transition is much higher.
A lot of these programming fads seem to come and go over the years. I've witnessed the same cycle with OOP, then FP. What a lot of people don't seem to realise is that by trying to split up a system into more smaller pieces in an attempt to decrease complexity, it's often the case that you end up with even more complexity, just hidden in the interactions between the pieces.
There are many excellent problem solving techniques in software engineering. Taken as religion, to extremes, most of these will lead the zealot to destruction. Microservices have their place, as do monoliths.<p>The author's most valuable point is roughly 'don't believe the hype' - and that's timeless. On the specifics, they're certainly right on each point, but they missed the (imo main) one of 'by forcing a conceptual boundary between different pieces of the application, one can build true silos around competences and so scale their org more effectively'. Put simply, a 200 person monolith will usually feel like it has 200 people working on it. That same org split into 5 groups of 40 can be more nimble. In some cases this is due to infra ('we need to get off Java 8' is easier if the software can be run in 5 pieces). In some cases this is due to problem scope (less intertwining of concepts possible).
> Fallacy #5: Better for Scalability<p>> [The assumption: only by - ] .. packaging your services as discrete units .. [you can] via .. Docker .. [achieve] horizontal scalability.<p>> However, it’s incorrect ... [to assume it can] only .. [with a] microservice.<p>Interesting, how monolith can do the same?<p>> You can create logical clusters of your monolith<p>> which only handle a certain subset of your traffic.<p>Oh... so MS... but with extra steps. lol. not to mention we usually care about the DB scale also, which is harder to scale as a monolith with segmented traffic.
Sean Kelly (aka Stabby), is one of the most talented engineers I’ve ever worked with, and is someone who understands the challenges and pitfalls of architecture ahead of his time, as this article highlights so well. To this day, I try to channel Sean’s approaches to design, coding, and architecture, in my own work.<p>Sean is a treasure in the Boston and Golang community, and folks should seek out his wisdom and guidance.
I reacted to this headline quite negatively. Reading the article, it’s actually quite reasonable. It’s trying to cut through all the incorrect reasons microservices/service oriented architecture is adopted. Kudos to that!<p>IMO service oriented architectures should be adopted when your engineering organisation has gotten too large to manage a monolith.<p>The service interface generally can’t be modified after it’s available. You can do the same with a monolith but it’s harder to enforce.
This is part of the problem: people say "do" or "don't" or "considered harmful" and suddenly this becomes a fashion everybody seems to follow no matter what. I saw the same with OOP, at some point it was almost a heresy to say there are many cases when OO design is inefficient or problematic. You would be labelled as uneducated or ignorant. For the same reason I'd never use a goto at work even though I know it has some limited valid uses. Etc. etc.<p>One would think that by know everybody understood that each technology has its own advantages and limitations and it makes zero sense to follow current trends but rather to examine the project well and use the tech that fits best, regardless what current "evangelists" say.
The issue with these articles, is, they assumed, bad architect divided wrong domains into "wrong microservices", then concluded, "microservice" is bad strategy.<p>Step 1: Understand the domain first.<p>Step 2: Use microservice for each domain.<p>If you failed at step 1, step 2 is wrong.<p>Monothlich architecture just "skips" step 1, and use one big fat service for all.
I would recommend just using SAM or Chalice for MS on AWS and layering on Step Functions/Fargate/ECS Anywhere for hybrid setups if you are not using Kubernetes. The only difference is that you are coupled to AWS but if you are already have been using AWS for everything else, its very natural and easy to just learn a new product and integrate it to your existing infra setup on AWS.<p>CDK is also another interesting tool in that you can create classes that handles existing series of scaffolding and automation and it feels naturally code like but drift detection still requires improvement vs Terraform's.<p>If you work for a large company where they have mandated Kubernetes then obviously its gonna be difficult but I am seeing a trend where companies are starting to "hedge" their bets as K8 projects take far longer to get to market and requires more experts to keep it going so I'm half heartedly learning Kubernetes, especially on the back of my mind the existing AWS solutions offer far quicker time to market and accomplishes the same thing.
My advice: there is no universal services advice, therefore, don't adopt (or un-adopt) things just because someone wrote about it. At the same time: don't ignore pain, regardless if it's because you're too big, too small, too segregated or too monolithical.
I spent years reading on here about how microservices are bad, but I don't understand how you can avoid them when everything has to be in a container network to run. Airflow workers, containers that wrap GPL licensed code, little FastAPI interfaces to Bokeh functions, a customized Keycloak. Everything has its own dependencies and deploy process. We have like eight developers and seventeen git repos and I have no idea how to keep it from getting worse.
Interestingly, I think that almost all of the downsides listed in the article and in the comments go away if you use a good framework for creating microservices (example for this: [0]):<p>No internal glue code, no overhead by writing network interfaces, no slow HTTP calls (faster gRPC instead), no manual handling of asynchronous tasks.<p>[0]: <a href="https://github.com/jina-ai/jina" rel="nofollow">https://github.com/jina-ai/jina</a>
> Microservices – Please, Don’t<p>Sadly, most OSes, Linux included, are built as a bunch of microservices. Systemd is effectively a management system for microservices.
Moved from a monolith to a microservices project. The main and almost only benefit (and the reason I asked to move) is that startup time is now practically non-existent (from 8-10 minutes to 30-40 seconds). This allows for faster testing and iterative-programming approach, which is the type of programming I do.
Approaches like Polylith allow you to delay any decision on how or if to split up your services until you are ready.
In the meantime you can gradually stake out your boundaries by defining suitable interfaces.
Every time the monolith/microservices debate comes up, there's a git submodule fan out there (somewhere?) with a single tear rolling down their face.
I find the hackernews obsession with bashing micro services tiresome. We get it, your organization didn’t need the scale/had a relatively simple problem/couldn’t solve bad code by doing microservices.<p>Sometimes it’s the wrong call. Sometimes it’s the right one. It’s not a panacea, obviously. Can’t we just use our expertise and judgement to determine the correct architecture? There are always trade-offs. Our job is to rigorously evaluate them and make a good decision, not blindly follow or dismiss any particular implementation.