The Death of Microservices?

The Death of Microservices?
Summary

In this video, we explore a surprising move made by a major industry leader: transitioning from a microservices architecture to a monolithic system. While microservices are typically celebrated for their flexibility and scalability, they can also introduce significant challenges such as high costs, complex orchestration, and intricate management. Faced with these issues, this company decided to make a bold change.

By shifting to a monolithic architecture, they managed to significantly reduce operational expenses and enhance system performance. This strategic pivot resulted in a dramatic cost reduction while improving scalability and user experience. The video delves into why this change might indicate a turning point in how we perceive microservices.

We discuss the potential benefits of this architectural shift and what it means for businesses looking to optimize efficiency and performance. The shift challenges the prevailing narrative that microservices are the default solution for modern applications. It encourages a reassessment of architectural strategies, taking into account specific business needs and objectives.
Could this be the right moment to reconsider the architecture of your applications for long-term success? Join us as we unpack the reasons behind this shift and discover valuable insights for your own technology strategy.

Bio

With over 30 years of experience in enterprise technology, David Linthicum is a globally recognized thought leader, innovator, and influencer in cloud computing, AI, and cybersecurity. He authorizes over 17 best-selling books, over 7,000 articles, and 50 courses on LinkedIn Learning. He is also a frequent keynote speaker, podcast host, and media contributor on digital transformation, cloud architecture, AI, and cloud security topics.

Reference(s) for this video:

Where you can find me:

My Gen AI Architecture Course on GoCloudCareers:

Talking points:

Death of Microservices?

I. Introduction. 00:59
II. Background of Microservices Architecture. 03:32

Monolithic architecture is an architecture used in the process of creating applications where all the components to build applications become a single unit.

Microservices architecture offers significant benefits, including modularity, allowing easier development and maintenance since services handle specific functions. It enables independent scaling, so resources are used efficiently, and services can be updated or deployed without affecting the entire application.

B. Advantages of microservices:
1. Modularity allows for specialized functions and independent updates.
2. Scalability permits individual services to grow without impacting others.
C. Challenges of microservices:
1. Increased complexity in service orchestration and management.
2. Potential for high costs due to numerous small services and inter-service communication.
IV. Analyzing the Trend: Why Microservices May Be on the Decline. 13:36
V. The Case Against Microservices. 16:34
VI. Lessons our Microservices experiences thus far. 19:22
VII. Conclusion. 21:07

[xlerb]

Previous company I worked for had an architecture you could kindly call "a big ball of mud". So everybody decided that the thing to do was bust up the monolith and build everything out as microservices. They now have a big ball of mud - but microservice based. I don't love or hate microservices, but they're not magic and don't remove the need for a good underlying design. I certainly wouldn't be sorry to see the industry stop thinking that microservices are a panacea.

[golmatol]

The company I worked for was burned badly by moving a cloud based service to microservices .... the decision was not made by the technical leads of the company .... it was the CTO's and CEO's who bought into the hype. They commanded loudly "Let there be microservices !!". A few brave souls among us peasants voiced concerns about falling for FOMO factor and no real reasoning behind this decision. Soon after, they were no longer seen. I suspect they are now at the bottom of some river tied to a concrete block. Some 100+ microservices later, we created a behemoth that even Egyptian pharaohs would be jealous of. We proudly slapped a price tag of a million bucks on it ... ... but that pesky little rival across the street was selling a teensy-weensy monolith for half the price and a fraction of the computing real-estate; while claiming all the same functionality. We stood tall and proud and bragged about our microservice based architecture. The customers all stood around that little hot-dog stand. Our CEO roared ..."Y'all blaady cheapskate plebians!! No appreciation for fine dining". Pretty much all of them figured their workloads are not so dynamic and they don't need K8s style scalability for at least another decade or so. A year later, half the company was laid-off (your truly included). Saving grace ... the CEO/CTO's were also thrown out the window (but they had their golden chutes on).

[nicksophinos]

As a mostly front end guy, we go to an even whole new level of ridiculousness with micro-frontends.

[bjarne]

We introduced micro services at my company some years ago. Today the backend is a total fragmented mess that is extremely expensive to host. From my perspective micro services solved absolutely zero problems but added a shit tonnes of complexity

[NilsElHimoud]

I always use to think that teams that are not able to modularize a monolith should definitely not try to modularize a distributed application. FIRST mudularize the monolith THEN spin out microservices IF there is a valid reason to do that.

[rommellagera]

Only five users in the same building but solution developed using Microservices because the Team Lead, Devs and Architect opted for it. Reason it's always good in resume.

[Bigtbone]

I have been doing solution architecture in large corporations for 25 years. I watch all the fads come and go and evangelism when some new architecture pattern comes along is amazing. My good friend builds houses for a living, when a new tool becomes available he just knows how to incorporate it into his building process, what he doesn't do is try and replace ALL his other tools with the new one.

[Esteband]

The tech industry often chases trends, but we should prioritize what works best for our specific projects and teams. Meta's continued use of PHP, despite repeated declarations of its obsolescence, is a great example of this pragmatism. They've stuck with and improved a technology that suits their needs, rather than constantly switching to the latest 'shiny' thing. In software development, success comes from making informed decisions based on project requirements and team capabilities, not from blindly following trends. It's about finding the right tool for the job, whether it's cutting-edge or time-tested.

[kernelpanick]

I worked for a company with a cloud team that spun up containers with terraform and broken out to so many microservices that when I asked if we could look at a front end to confirm that these services are updated properly (just looking to confirm the footer notes went from version 15.3 to 15.4 as an example) and it started a fight within the team and a 2 hour meeting on why anyone cares about that vs how do we even know what we are changing is being changed....needless to say I left that company and they lost the contract they were on

[bitlebron]

I think the pain point is, teams now want to make everything a service when there may actually not be a need for it. We currently have identity verification done in most of our services, and each service keeps duplicating codes, so we just decided to make an independent service to handle this verification which other service can make use of. The thing is in a much as its good, it can get out of hand just cause teams feels like its the shinny thing without understanding the complexities these might cause, including using queues for decoupling which adds its own complexity for something that no other service would even use.

[CineTechGeek]

Shows you how much we have become a victim of the marketing from the large providers.
I looked at microservices for our products and the biggest advantage was non-use no cost, but when used, cost a lot more then monolithic.
Microservices are also a lot slower when you crunching a lot of data. You cannot cache it well enough and cloud costing make it super expensive.
This was always obvious but still we saw a lot of terrible choices. Only now when money is stretched, are they seeing the reality.

[genechristiansomoza]

If monolith works just fine then there is no need to microservice it. Microservice is a solution to a problem. If there is no actual problem to solve by microservice then there is no need to do it.

[MrTbirkett]

Micro-services allow you to scale - this was never about the tech or scaling horizontally to handle more traffic - it was about people, ownership and rate of change in different parts of a complicated system. It is all about organizational scale.

[stephanearguin]

One of the hidden cost is also eventual consistency. Remember that "Eventual consistency == Permanent inconsistency". A lot of mecanisms, tools, ... (aka moving parts) needs to be put in place to mitigate this problem that is near absent in a Monolith design.

[zb]

While I'm not here to specifically advocate for microservice-oriented architecture, my experience of over 20 years in the industry has shown that the most common challenges often stem from human error, rather than the technology itself. Microservices, when implemented correctly, offer a robust architectural approach. However, without the necessary skills to design and code within the framework's constraints, or by cutting corners and misapplying the technology, one cannot fairly place blame on the architecture itself.

The key to success lies in understanding which parts of a system should remain monolithic—because overcomplicating certain components can introduce more problems than it solves—and which elements can be effectively broken down into independent services. Knowing the right tech stack for different modules, and when to leverage external services to seamlessly integrate the system, is what truly distinguishes capable architects and system designers from developers who have yet to refine these skills.

[cathy]

Microservices are just one of the architectures you should be looking at when developing an application.

To many times microservices has been to go to architecture based on hype rather than requirements and most importantly the team or teams structure type to develop and support the architecture.

[DanKuchem]

IMO, the modernization discussion begins with "Why, " not a target technology. Microservices definitely has its place, but not all apps require it, nor do all teams have both the resources and skills to architect it.

[SergioBallestrero]

In most cases, the deciding factor is Conway's law.
If adopting microservices allows your different dev teams to work more independently and each at their best pace, it will most likely outweigh the cost of the increased overall complexity. As always, YMMV.

[kennymcleish]

Agree with the sentiment here. One consideration you didn’t cover was microservices as a tool to solve the problems of organisational complexity. I have spent my career in technology in banks with thousands of technology employees and hundreds of interconnected applications, many of which were legacy. Coordinating a team of dozens of people on one, aging codebase becomes very hard. Also, if you have a dependency on one of those teams, getting a change made can be a coordination nightmare. Breaking into smaller services helped to solve that organisational problem. If you have a smaller simpler service, then it’s easier for others to contribute and it was also an opportunity to modernise, adding in automated testing, clearer interfaces etc, which led to more agile teams and technology. I do agree, it became over used and the downsides misunderstood or glossed over.

[tincustefanlucian]

I'm so so glad that people started finally talking about the inherent problems of micro-service. I had so much problems explaining the dis-advantages of the micro-services, at least now I have some arguments.