The Thing No One Tells You About Microservices

Are your microservices even microservices? I, and many other thought leaders in software, think microservice architecture is widely misunderstood and as a result, not implemented correctly.

In this episode, Dave Farley explores how to design microservices to avoid sharing data stores between them.

-

🖇 LINKS:

-

⭐ PATREON:

-

👕 T-SHIRTS:

A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!

🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

-

BOOKS:

and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-

CHANNEL SPONSORS:

#softwareengineer #developer #microservicesarchitecture #microservices

[JustLikeBuildingThings]

So much of this hurts. On a large government programme I turned up for greenfield project, and were dictated by the client we must use microservices and graphQL. We were then presented with a huge data model of a monolithic data structure with dozens of tables, all complete with attributes... before any work being done to actually decide what was being built. It made the project massively complex, to the point where graphQL was abandoned and project converted to a monorepo. No one understood the complexities of what they were asking for in terms of complex business logic and failure handling.

The culture of muppets designing systems from ivory towers using buzzwords is the biggest IT con in our time, pissing up millions of public funds. If people knew the full extent of it they would riot.

[GackFinder]

Microservices are great if you're willing to deal with the the ridiculous extra costs to manage the ridiculous extra layers of stuff you need, such as monitoring, alerting, retry logic, versioning, authentication and authorization, deployment, dead letter queues, idempotency requirements... for every single microservice.

[Fanmadeb]

I just quit mit second job in a row where a large part of my decision was based upon upper- and/or middle management making stupid technical and architectural decisions.
In both of these jobs were software "architects" who were sure that they know better how to define microservices and how to use them.
Not "when" to use them, because basically both of them are certain that monoliths are something that can only be bad and need to be avoided.
In their world, no experienced developer would decide on a monolithic approach for anything.

Apart from that, they both designed "miroservice architectures" that basically contradict everything mentioned in this video.
Like ~30 "microservices" in the one company, which are all requiring the same package, which defines the data structure that all of them are supposed to be using.
Of course, those 30 microservices are all developed and maintained by exactly one team with three members.
Updating anything there is a always a big pain, very often resulting in bugs and errors that make it to production and in turn to the customers.

Oh, neither one of them could manage to integrate anything that would allow proper logging.
So just to find out where exactly an error in that mess happened was very often a hard task that could take half a day while involving half a dozen of people in itself.
Not to mention the debugging process afterwards.

I quit the first job because I thought that this was a problem of a small and understaffed company.
So I switched to a larger corporation with billions in turnover, only to see that they did the exact same thing, just with more people involved.

While I had my talk with HR about my reasons, I did a bit of self-reflection and I found out that I have learned a lot of good and bad things in each company I worked for, but my last job was the first one where I can't think of one good thing I learned.
Of course this is only considering the professional context, I still got new contacts and met very nice people from which I also learned good things, but I've contributed some things to the code of that company's system that I've learned previously without learning anything beneficial from their code except how not to do it (most of which I've seen before).

This is really frustrating and I have no motivation to start at any other company right now.

[jimiscott]

Here are the hard truths about microservices...
1. Your organisation probably doesn't need them - do you have the scale?
2. Your first attempt at building microservices is probably wrong and you end up with a distributed monolith (or a distributed ball of crap) - I am going to say this is akin to first designing an OO system with loads of hierarchies - these will be wrong.
Just do nicely independent services - they may be large - they may be small - as long as they're independent you should be OK.

[skylineuk]

I’ve been in the systems development game since the mid 1980’s. Sticking to any one methodology is crazy, different ones work better in some cases than others. Never start out with a methodology, decide on the methodology after you have specified the problem and allowed for growth, scaling and future direction as much as possible. The number of “university type” projects based on the so called holy grail of methodologies I have seen fail is just plain crazy 😢.

[jimhumelsine]

Building a microservice is easy. Building a system of microservices is hard. -- Paraphrasing Sam Newman.

I'm glad that Dave listed "Bounded Context." This is a Domain-Driven Design concept, and I'd like to follow up with another DDD concept: Context Map, which defines the communication channels between Microservices.

Bounded Contexts and Microservices get most of the buzz, but the real work resides in the Context Map. And I'm of the opinion that for the most part, the Context Map is not the responsibility of the average developer. The average developer is responsible for the implementation of the microservice given the communication channels and protocols within which it operates. The average developer is very much interested in the Context Map, but mostly within the context of how his/her microservices interact with it.

It is the architects and possibly the lead software developers who are (or should be) responsible for the Context Map. How often do they own this responsibility or even realize that they should? If no one is responsible for the Context Map and manages it, then entropy will take over. The system will become a huge distributed big ball of mud.

[AWildLukeAppeared]

the overuse of these buzzwords is horrendous. Ive not long started work at a new company and today cheekily struck-through the words "microservices" and "service orientated architecture" in the company's technical documentation and replaced it with "distributed monolith". very tongue in cheek of course and people can always switch it back if they like, but lets see if it starts a conversation. The problem from my point of view with just splitting things into separate repos and calling it a day is you then have all the difficulties of working with microservices ( of which there are plenty ) and absolutely none of the benefits ( of which there are also many when its done right ).

[dameanvil]

00:00 🎯 Microservices are powerful but often misunderstood in practice, leading to teams claiming to use them when they might not be.
02:34 📚 Agreeing on clear definitions and terminology is crucial for effective communication and learning within the industry.
05:15 🔍 Microservices must adhere to specific attributes like being small, focused, autonomous, and independently deployable to be considered as such.
09:32 🚀 Independently deployable microservices are essential for enabling organizational autonomy, scalability, and faster software delivery.
13:10 🔄 Sharing data between microservices via messages instead of a shared database reduces coupling and enhances scalability and maintainability.

[Vendavalez]

If the problem you are trying to solve with microservices is tight-coupling, please do yourself a favor and don’t move to microservices until the underlying code base is already loosely coupled. If you don’t know how to make a monolith loosely coupled, what makes you think you will be able to keep microservices loosely coupled? You will end up with a distributed monolith and every change will require 7 PRs and 7 simultaneous deployments. And lord help you if you have to roll anything back.

[bobbycrosby]

I think the problem is people and organizations that can't benefit from microservices are trying to use them because it's what Google/Netflix/Whatever uses. So they cut corners.

[ВладиславДараган-шф]

Why people forgot that distributed computing is hard and keep talking about microservices as silver bullet?

[roundtheloopandback]

Around late 2012 I became aware of the microservices approach and definitions of what one was, my understanding then is as you have posted now, yet this video is still required in 2024 (and it really is required) because people simply cannot builld microservice architectures as intended. They are not easy and introduce issues of their own, this is an excellent post as normal on the subject and should be shown to business people and developers alike.

[Rope]

I really appreciate how in this video you've taken my previous comment, regarding the title and the content's misalignment, into account.
As always the content itself is superb of course.

[VincentJenks]

Extremely well articulated, thank you. As an architect and mentor, it’s very hard to convey these concepts, even to technical staff. It’s even harder to convey the value because many want the easy, naive approach that’s obvious on day one of a project. It’s experience with the hell that most large projects devolve into that have led us to new approaches, like microservices.

[oleleclos]

You're spot on about definitions. It's an uphill battle to insist that words matter, but it has to be done because otherwise we lose the ability to have a clear and meaningful conversation. I designed software in the 1980s, at the time when microprocessors greatly expanded the IT market and it flooded with clever dicks, many of whom took to using long words, often in the wrong place, to cover up ignorance or uncertainty - only managing to make it worse. But even (and maybe especially) when that's not the case, we do ourselves a favour if we stick to clear definitions. And then invent new words to mean new things, of course, but still be clear about their meaning.

[scottnash]

Remember how badly the term "cloud" was corrupted by legacy on-premise software providers. It got to the point where I needed to specify the key question "Are all customers running on the same version of the software?" whenever I was evaluating vendors.

[IronDoctorChris]

I think part of this is because microservices are the correct choice for such a small percentage of development teams. 90%+ can likely get by just fine with a modular monolith. So they build like that and mistakenly refer to it as "microservices".

[lilivier]

I've always found that 'One task' is too vague. I've noticed that nobody has the same definition of what a 'task' is.

[adrianpaulwynne]

Not all coders are rock stars (yet). In any team, many are still in the early stages on their career.
Some things are easy, like coding and testing a synchronous function that represents some business logic. Everyone in the team can do it.
Some things are much harder, like dealing with synchronisation and eventual consistency and failure modes and deployment and security. Not everyone in the team can to do it well (yet).
The microservices model pushes responsibility for the difficult problems down into every small (by definition) microservice. It becomes everyones responsibility
Furthermore, the patterns implemented in each microservice have to be mutually-compatible
Is this realistic, or a recipe for chaos, fragile systems and endless meetings?
how do you solve this?

[scottnash]

Love the example of the Orders; it's a common issue in the enterprise systems I deal with as a PM. While denorming the account ID seems strange at first, it's MUCH easier to justify if you assume that the Accounts are in a third-party SAAS CRM system that has its own uptime policies (not uncommon). By definition you have to design with denorming so that it can operate independently. The more third-party systems, the more important this gets.