They're doing microservices because they can't make a good monolithic codebase. For some reason, CTOs are very happy to start doing microservices with high level of documentation and rigorous interfaces but completely unwilling to have a well documented and rigorously defined monolith.

I don't fucking get it. It's like one layer of abstraction on top of folders. Instead of breaking up ownership by folders or whatever bullshit - they decide to breakup ownership by github repo.

I'd love to be sold on it otherwise but that's what I've been told directly as the reason for the move to microservices by many companies and what I've seen at my own. Can't do a good job because your business practices suck? Fuck it - microservices, baby!

I think a big reason is that microservice architecture forces teams to establish clear boundaries rather than leave it to team diligence.

For less centralized organizations, I think it can be a useful forcing function.

Clear boundaries on multiple levels as well. I believe a _very_ big part of why people feel they need microservices is because of poor architecture and a lack of boundaries in a monolith. Every single monolith I've come across has had issues with circular dependencies and no real contracts between "apps" (as they are called in Django).

I believe people see ORMs such as Django's as a way to perform one big query as opposed to many small queries. The big query spans 3 apps and 8 models. You have these things sprinkled throughout the codebase and you end up with a big ball of mud.

But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)?

This situation is a necessary conceptual step before decoupled micro services and far far easier (because it introduces none of the ops problems of microservices).

But that never seems to happen. I think it’s because codebase discipline rules are harder for management to ‘see’ than API rules.

> But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)?

1. One person or group needs to decide on what the rule should be, what the boundaries are and how to enforce those boundaries. This is usually not an easy process, ymmv.

2. After a decision is made, you'll have to decide on how to put the rule in place. Are you going to stop everything and make sure all code paths are working according to the new rule? Are you going to do it incrementally? New features = new rule, old features = common sense? Another variation?

3. You then start running your new rule and maybe you enforce it with some custom static checks, and when that fails you hope your code reviewers will always catch this every time.

4. You still need that one person or group to make sure this actually gets done and to assess if it actually has a positive impact on velocity and reliability.

Or you can put in an implicit "rule" that new code happens in a separate repository, where you don't need to care. A developer that has to do an API call because they simply cannot "import" another module or "query" someone else's data has no choice but to do the right thing - though many opportunities to do a lot of other wrong things too, this is not a panacea. But when we're talking about more than ~5-6 teams, the coordination effort of making sure everyone is aligned on a monolith can be much tougher than to go to multiple services (hopefully not micro).

I think your points are about lacking solid engineering leaders at an organisation that could provide guidance and manage execution of the "modular monolith" approach. If a company does not have leaders who can ensure consistency and discipline across a few team within a monolith, I am afraid of the mess they will run into with multiple services.

None of these problems are solved by microservices. Now instead of undocumented unstructured interactions between modules, you have undocumented unstructured interactions between standalone applications. None of your problems are solved, except now you have a much bigger cloud hosting bill.

That’s not been my experience working with microservices for the past 5+ years. It’s in a team’s own interest to document their APIs and design them well, because if they don’t then it’s their own time sink when other teams integrate.

Microservices have problems but the way they’re often portrayed doesn’t match my experience.

I agree with the sibling commenter who said that a microservices architecture exchanges an organizational expense for a technical expense. For certain organizations, it can be the right call.

I agree though I'd have to think a bit more about the exact way for apps to speak to each other. My guess would be each app could have an api file with a bunch of functions. I wonder how that would work in a situation where you have 3 apps, each with a single model, and the dependencies are A -> B -> C. You could still run into situations where B isn't supposed to know anything about A yet nothing stops B from importing A's api.

It’s still possible to have circular dependencies in microservices. There is normally nothing stopping service A calling B and B calling A except common sense and discipline.

In fact I would say it’s MORE difficult to prevent circular microservice dependency programmatically than in code (where you can hook into module level imports).

The corollary being that the technical problem of a microservice architecture is easier to solve than the management problem of leading a single large team.

Probably some truth to that.

Well said. I think a microservices architecture exchanges an organizational expense for a technical expense. For certain organizations, it can be the right call.

Something to consider: when you then realize that the boundary isn’t the correct one or the environment evolved enough that it isn’t meaningful anymore, that’s really painful and expensive to change.

Microservices and monorepos are unrelated to each other.

You can have 100 micro services from a single repo, and the services are just different folders.

Microservices help people have bounded context when they are develop and they leak their abstractions less into the next one. Monoliths (admittedly I've only seen them in Python, Ruby and .Net) start reaching into each others pieces and adding to tech debt in subtle ways.

You are of course right, discipline is required in both architectures, but there are different emphasis in both.

1 year into my startup and I'm super happy to have kept everything a well-organized monolith. Every once in a while a thing pops up where some voice in my brain (remnants from previous jobs) says "just break it into its own service" but I've thus far resisted. Our deployments are trivial. Our local dev setup is trivial. Maybe some day we'll have a few small services broken off, but today is not that day.

I haven't found many articles from respected sources that will convince management that microservices are a bad idea. There's https://martinfowler.com/bliki/MicroservicePrerequisites.htm... , but this won't convince them.

Here is my non complete list:

- Who’s at the Helm? [0] - Microservices, hard as 1, 2, 3 - You can move it but complexity is still here [1] - Microservices — architecture nihilism in minimalism's clothes [2] - Do I Really Need Kubernetes? [3] - Your team might not need Kubernetes [4]

I doubt that any of those articles could convince higher management. I don't know what a "respected source" actually means. I general I believe that advice from consulting agency and cloud providers should be taken with a grain of salt.

If you drew the same conclusion from the "Who’s at the Helm?" article than I, there is only one way out which is a curated container catalog. VMware's Tanzu Application Catalog [5] is the only product in that space I'm aware of. I have quoted the price tag on HN, I think it was removed since that, so I won't repeat it here again. In any way it was magnitudes higher than the EKS base price which already seen as a showstopper by many small shops. Bottom line is: it is really hard and really expensive to operate containers in a secure manner. Probably too hard and too expensive that it would be a good idea to start with it before you actually need it.

0: https://dlorenc.medium.com/whos-at-the-helm-1101c37bf0f1 1: https://medium.com/@danielpetisme/microservices-hard-as-1-2-... 2: https://vlfig.me/posts/microservices 3: https://thenewstack.io/do-i-really-need-kubernetes/ 4: https://medium.com/faun/your-team-might-not-need-kubernetes-... 5: https://tanzu.vmware.com/application-catalog

What I really don't get about microservices is the performance aspect. Like cache << memory << disk << network in terms of time needed to read/write, and it seems to me that microservices are particularly prone to this by often using HTTP calls.

Sure, you can run them on the same box, but it's very easy not to, and I imagine that this will absolutely crater performance (at least in the DS/ML stuff I do).

Disk is often slower than the network now. You do need to keep an eye on this. However, using tools like gRPC instead of wasteful JSON REST calls makes a huge difference and brings other benefits too.

Typically speaking you're adding submillisecond latency per external call, or you've done something wrong.

Something wrong can include incorrectly organizing your system. Two separate services that constantly chat with one another should probably be considered as candidates to merge into one, for example.

Deployment matters a lot. I see people mocking systems like Kubernetes and tools like service meshes, probably because they don't understand this critical and hugely beneficial capability they bring which is to organize communication on the bases of (amongst other things) locality and system topology automatically.

In the end, most people seem to totally miss the real reason that "micro" services (the "micro" part should really be ignored today) are beneficial. Hint: it's not a technical problem being solved. It's a people problem. Service oriented architectures give very clear boundaries around which a development organization can structure in a way that allows parallel delivery.

The biggest problem any growing organization will face is: they don't pay attention is contention (yes like as in concurrency/locks/etc.) across the development team(s).

I have personally witnessed and worked with a 400+ person monolithic development organization. This was essentially a "unicorn" and an exception that proves the rule. The one and only reason this organization was successful was because they had top to bottom extreme coordination managed by a very small group that worked effectively together. Without that tight central orchestration it would've been a nightmare.

Most organizations can't orchestrate a 7 person team effectively, good luck getting 200 to share a monolith well. So you break up the org and the architecture follows, see: Conway's Law. It goes both ways, too. You break up the architecture and the org can follow.

With that in mind, it's extremely important to get your boundaries right and for the love of all that is sane in a daily job, don't break it up too much. So many organizations would triple or quadruple their productivity breaking a monolith into literally 2 parts. If you can do 3-5 that's cool, amazing! Just because you can see the dotted lines between 25 different potential services doesn't mean your organization will tolerate that.

Anyway that was a diatribe.

TL;DR: "micro" services solve PEOPLE problems, moreso than technical ones, and the price you pay is additional architectural and delivery challenges which you must balance well and plan for

As both an IC and Manager, I've now been on a lot of teams using monoliths and teams using microservices, and I would always choose microservices going forward.

Let's be straight, both have pros and cons, but I value the following pros of microservices a lot more than any of the cons:

- Enforces separations that are important for: - Maximum parallelization of work. - Scalability of each service. Never share database. - Reusability of the service from other services.

The trick is to learn how to cut microservices though. Establish an interface that it exposes, like GraphQL or RPC. Don't try to split too fine-grained, but find a balance that works for you.

I promise you, when it comes to scalability, you'll be glad you don't have to scale one massive database just because one part of your application is seeing more activity.

This also allows you to pivot quicker to a different database suddenly, or a different programming language, if requirements change. E.g. Node.js -> Rust if your service is found to be on the hotpath of everything, and you need correctness and performance.

I fundamentally view the difference the same way I would choose Rust over Clojure:

- Monoliths: Rely on discipline of the team to do it right (like Clojure won't catch your dynamic mistakes) - Microservices: The most important parts you need are built-in and enforced by the concept itself (like the Rust compiler guides you towards the correct approach).

While I agree with you on unreasonable rush for microservices in many cases, I do not think a company must be on the FAANG-level scaling to justify microservices infrastructure.

Modularisation is an efficient tool to address growing complexity of software. The code is organised in closed subsystems - modules - that work together via communication with each other over defined interfaces: functions, REST endpoints, messaging system.

Modules can be done in monolith by enforcing boundaries and policies: namespaces, packages, agreements on communicating only via "service" classes, isolating database entities, no foreign keys between entities belonging to different modules, etc. It is so called "modular monolith", and I believe it's an efficient way to progress for organisations before jumping on microservices train.

Microservices are the next step of modularisation and isolation. By introducing independent deployment of the modules and isolated runtime for each module (different machine, VM, containers) they enable independent CI/CD for the teams that helps to scale up the organisation and they help with isolating different pieces of software that have different technical requirements (traditional Web API with database calls, stream and batch data processing, etc.), different stability and change frequency.

While bringing a lot of additional concerns, requiring education and discipline, microservices are critical enablers for many companies to further grow their products and scale up the technical department.