Pretty sure I saw someone say this in the past, but microservices might as well have been a psyop pushed out by larger, successful startups onto smaller, earlier-stage companies and projects. I say "might as well" because I don't think there's any evidence for it, but the number of companies and projects that have glommed onto the microservices idea, only to find their development velocity grind to a halt, has to be in the hundreds at least (thousands?). Whether the consequences were intended or not, microservices have been a gift on the competitive landscape for the startups that pushed microservices in the first place.
Microservices are a tax your startup probably can't afford
91–100 of 272 posts
Re: Microservices are a tax your startup probably can't afford
#92Micro services show their benefits in a large organization. It’s a tool to solve people issues. They can remove bureaucratic hurdles and allow devs to somewhat be autonomous again. In a small startup, you really don’t gain much from them. Unless if the domain really necessitates them, eg. the company uses Elixir but all of the AI toolings are written in Python/Go.
One of those teams need to go.
Re: Microservices are a tax your startup probably can't afford
#93Micro services show their benefits in a large organization. It’s a tool to solve people issues. They can remove bureaucratic hurdles and allow devs to somewhat be autonomous again. In a small startup, you really don’t gain much from them. Unless if the domain really necessitates them, eg. the company uses Elixir but all of the AI toolings are written in Python/Go.
microservices can also cause organizational dependencies and coordination that wouldn't otherwise be necessary. i've seen it create at least as many people issues as solve them. one seemingly innocuous example is the policy of 'everybody just uses whatever services they want', which can hugely increase the ongoing maintenance requirements and seems to require that everyone learn everything in order to be functional. which never happens, which means you're always chasing people down.
Re: Microservices are a tax your startup probably can't afford
#94Earlier quoted context omitted.
We solve the problem of 50 devs working in a single monolith with folder and file structure, separation of concerns, basic stuff like this
This is really what it comes down to right here. The real challenge is Conway's Law. Both the software architecture and the org chart need to be designed with Conway's Law in mind. If that hasn't happened then deciding between microservices and monolith is ultimately just deciding how you will be punished for your mistake.
People misunderstanding Conway's Law is a big part of the problem for sure. The law says nothing about team boundaries: it talks about communication pathways.
The paranoid socialist in me thinks big companies like team-sized microservices because it lets them prevent workers from talking to each other without completely ruling out producing running software.
When companies instead encourage forums for communication across team boundaries, it unlocks completely different architectural patterns.
Re: Microservices are a tax your startup probably can't afford
#95I've found using Cloudflare Workers really productive, esp. their R2 and Durable Objects bindings. Are these technically "microservices" and should they be avoided if following trad software patterns?
Using them makes it easy to build endpoints for things like WhatsApp and other integrations
Re: Microservices are a tax your startup probably can't afford
#96The problem is the "micro" part. Service oriented architecture is generally the way to go, but the service boundaries should be defined by engineering constraints, not as arbitrarily small.
Where I work, they consider a service managed full-time by a team of 2-8 people a "microservice." Before that, they had a monolith shared by a dept of ~120.
Re: Microservices are a tax your startup probably can't afford
#97From my experience, microservices were great if there are more devs, organizational advantage over tech.
CI/CD - infra can be as code, shared across, K8s port-forward for local development, better resource utilization, multiple envs end so on, available tooling, if setup correctly, usually keeps working.
Not mentioned plus, usually smaller merge requests, feature can be split and better estimated, less conflicts during work or testing... possibility to share in packages.
Also if there are no tests, doesnt matter if its monorepo or MS, you can break easily or spend more time.
You should afford tests and documentation, keep working on tech debt.
Next common issue I see, too big tech stack cos something is popular.
Re: Microservices are a tax your startup probably can't afford
#98Earlier quoted context omitted.
We solve the problem of 50 devs working in a single monolith with folder and file structure, separation of concerns, basic stuff like this
Folder and file structure and separation of concerns doesn't change the fact that if you have one deployable artifact, it's all sharing the same runtime when deployed. Which means the underlying versions of Java/Go/Python/etc, or core shared libraries, all need to be updated at the same time. All the code is far more coupled than it first seems.
That is not really an issue I've had with Java, but I would absolutely agree that Python is wildly unsuited as a production backend language.
I don't think it's much better if you have to spend a year and a half updating 400+ different repos, though. It's much easier to use an operationalized language that knows backwards compatibility matters.
Re: Microservices are a tax your startup probably can't afford
#99microservices are a gigantic waste of time. like TDD. it takes skill and taste to use only enough of each. unfortunately a lot of VC $$$ has been spent by cloud companies and a whole generation or two of devs are permasoiled by the micro$ervice bug. don't do it gents. monolith, until you literally cannot go further, then potentially, maybe, reluctantly, spin out a separate service to relieve some pressure.
Ha! I always feel more than a little embarrassed when it happens, but I can't sit idly by while TDD is slandered, especially from so seemingly oblique an angle!
While I agree with you regarding microservices (eg language abstractions provide 80% of the encapsulation SOA provides for 20% of the overhead) and I readily acknowledge that 100% test coverage is a quixotic fantasy, I really can't imagine writing reliable software without debuggers, print-statements, or a REPL—all of which TDD replaces in my workflow.
How, I wonder, do you observe the behavior of the program if not through tests? By playing with it? Manually reproducing state? Or, do you simply wait until after the program is written to test its functionality?
I wonder what mental faculties I lack that facilitate your TDD-less approach. Can it be learned?
Re: Microservices are a tax your startup probably can't afford
#100I pretty much agree with everything in this article — it’s next to impossible service boundaries right in a startup environment.
Though, if you’re on a small team and really want to use micro services two places I have found it to be somewhat advantageous:
* wrapping particularly bad third party APIs or integrations — you’re already forced into having a network boundary, so adding a service at the boundary doesn’t increase complexity all that much. Basically this lets you isolate the big chunk of crappy code involved in integrating with the 3rd party, and giving it a nice API your monolith can interact with.
* wrapping particularly hairy dependencies — if you’ve got a dependency with a complex build process that slows down deployments or dev setup — or the dependency relies on something that conflicts with another dependency — wrapping it in its own service and giving it a nice API can be a good way to simplify things for the monolith.