From a technical point of view, we're on the same page. But then there is the reality of modern software development.

A few years ago, the new CTO of a Union Square Ventures' investment tapped me as technical advisor to review this startups efforts to expand their software to new verticals. He came in as part of a reshuffle. He had brought his Director of Engineering from his previous (well known) company, and there was even a Star CEO (which is the reason I signed up!) with a monumentally impressive CV. As compensation, I was billing lawyer hourly rates.

After two months of reviewing their existing architecture, and picking the brains of the dev, support, and sales team the new verticals, I came with an architectural solution to their immediate and long-term needs. I gave them exactly what they said they wanted.

What then happened is that, for one, the Star CEO turned out to be an echo chamber of "growth growth growth" and entirely disappointing as a leader of a software company. And this was a SV veteran from both HW and SW side of SV. Huge disappointment.

The CTO, who was entirely clueless, apparently gave in to back channel efforts of his DoE to disregard my work product. A few days later I walk into an all hands meeting where the "next generation" was announced to be "a ball of mud" of "microservices". This same CTO later took me aside and basically offered to give me hush money ("will you be my personal advisor?") to keep quiet, while getting the same (insanely high) hourly rate for the remainder of my contract.

So this is the reality of modern software development. Architecture is simply not valued at extremities of tech orgnizations: the bottom ranks are young developers who simply don't know enough to appreciate thoughtful design. And the management is facing incentives that simply do NOT align with thoughtful design and development.

I read an article recently basically decrying how junior devs (and some not so) are holding tech leaders to ransom unless they adopt the architecture of their choice - microservices being the current hot paradigm, and so they are capitulating in order to keep them, despite the fact that probably 99% of these devs are demanding something they will have zero experience with.

I definitely saw the same thing playing out at my previous company, and not being in the mood for a conflict over that have moved on.

And yet not a single name or identifying piece of information that people can take action on, so these borderline frauds will continue drawing huge paychecks and hampering development for years to come.

The CEO was not a fraud and given the genuine fully-established and world class credentials of his technical reports in previous engagements, entirely unlikely that he could have faked it with that crowd. No. It seems he had adjusted per prevailing and current norms of SV.

Beyond that clarification, I think it irresponsible to name names. This wasn't a case of "fraud" - Peter Principle ruled the day. Both CTO and DoE had in fact lead a successful very large scale internet product company, which is the reason they were tapped. It just happens that this domain was far more nuanced and complex than the domain of their previous victory tour.

Also, as expected, they (including the super enthusiastic junior engineers that kept pushing for "microservices") have all moved on.

This is just how the industry works.

Yeah. One thing I've noticed is that people are really bad at working towards high-level, nebulous goals like "code quality, right abstractions, decoupling, cohesion". Keeping these goals in mind requires constant thought, analysis and decision making as each case is different and there's no universal solution.

So people jump at simple, single-faceted goals like "normalise the database", "spin out microservices", "don't use HTML tables", "rewrite using Rust" etc. These involve no further thought, no continuous evaluation of nebulous targets like quality, no keeping up with moving goals.

It explains quite a lot of problems with politics too. Choose from red or blue. No further thinking required. If even that's too difficult, just pick the one your parents/friends picked. Easy!

Indeed, if the team is not able to write modular code, it is not putting a network in the middle that it will sort it out, the outcome is just spaghetti network calls.

I always found the "microservices make things simpler" argument to be suspicious. At the end of the day it is just a monolith with unreliable network connections between components. Each microservice may be less complex, but you have just pushed complexity from the application layer to the devops layer. In a well written monlith the components shouldn't need to be any more complex than a microservice component.

thats because the main advantages of microservices have nothing to do with writing code.

as an example, the PathofExile.com website goes down every time the game servers restart because they share infrastructure. This should be avoided.

Someone forgot to use a load balancer with red/blue deployments.

But you can avoid this quite easily without resorting to microservices.

>it's about domain boundaries, application architecture, coupling.

Thank you! As a service consumer, if I need to call the same 3 other services for EVERY OPERATION, then we've achieved microservice hell.

>monolith with 500.0000 lines of code could be very well designed... As someone who was part of a "de-monolith" effort, the first step of our process was to create internal service facades that grouped things according to the logical domains that aligned well with our required functionality, data storage, and availability requirements.

Once those were functional, decoupled, and comprehensible, we actually had an easy to maintain, clean monolithic code base that exposed a small handful of services that were de/loosely coupled and conformed to workflows we need to support via web services.

This is something that is totally underappreciated in software. I guess it's difficult to do and takes experience to get right. And probably more difficult to explain how to do to others.

Having worked on enough crap code in the past (and right now) my primary thoughts are to try and make things understandable for the next dev that needs to pick it up after me.

Yea.

Once you have good domain boundaries you can use microservices to make the split more visible for less thoughtful devs and use the associated tooling (contract testing, ... ) to reduce operational coupling around deployments and tests.

But aside from that, anything you can do with microservices you can also do in monoliths.

Some people think that if you start creating micro services you will magically just "get" those boundaries.

and magically get the problem of distributed transactions. :)

I am yet to see a single monolith that doesn't deal with exactly the same issue itself.

Aren't monoliths by definition not distributed?

A true monolith is like a true function - it's absolutely useless because everything it does is pure and therefore it can't interact with reality at all.

In less metaphorical terms: you still need to sync external APIs, sync filesystem with the database, deploy to S3 as you don't want to saturate your web workers, or have conflicts in your parallel red-blue deployments.

If your monolith doesn't do anything I had just described then you probably aren't doing anything exciting anyway so it's quite unlikely that you've got a lot to say about software architecture.

monolithic source code can be deployed across multiple servers.

Oh, you don't know how true this is.

I'd be interested to hear about the sorts of systems that you've worked on and how anything you can do with microservices you can do with a monolith. Some problems that I've had to solve in recent years:

- Urgently deploying a fix in one part of the system without having to deploy the _whole_ system. - Updating the framework or the language (my favourite: updating from Java 8 to Java 11, which broke a lot of things and which we would have hated to have to do all in one go, if we'd had a monolith). - Scaling different parts of the system independently (both in terms of running different services on different numbers of nodes and in terms of using different hardware for application nodes and DBs). - Load testing different parts of the system independently. - Trialling a new language or framework in a small part of the system without affecting the rest of the system.

I personally wasn't aware of how much of a big deal some of these problems would have been until our system grew to the size that it is now, with a dozen or so development teams working on at least as many services. I personally have no idea how you could solve these problems on a system this size without splitting it into independently deployable services, without incurring a massive cost.

> But aside from that, anything you can do with microservices you can also do in monoliths.

Microservices can give you some things that a modular monolith can't provide: independent deployments, different tech stacks, independent scaling and better resiliency.

In short: DDD - Domain Driven Design

That's also the most useful thing i learned with doing microservices at work.

Note many good articles/videos about practical domain boundaries/designing AggregateRoot though. Does anyone have any tips? I feel that i'm lacking somewhat in designing them.