I'm done talking about microservices: the term is confusing, discussions are abstract, and without organisational change, microservices are pointless

ContainerSolution offers insights into containerization, Kubernetes, and cloud-native architecture, providing tutorials, workshops, and consulting services to help organizations adopt and succeed with container-based technologies. By exploring ContainerSolution's curated content, developers can learn about Docker containers, Kubernetes orchestration, and microservices deployment patterns for building scalable and resilient cloud-native applications. Whether you're migrating legacy applications to containers, embracing DevOps practices, or optimizing your cloud infrastructure, ContainerSolution offers resources to accelerate your containerization journey and unlock the benefits of cloud-native computing.

Container Solutions

Microservices discussions are often unproductive due to unclear definitions, abstract conversations disconnected from business goals, and lack of necessary organizational changes. Instead of focusing on microservices as an end, it's crucial to address concrete challenges like faster feature deployment, reducing system coupling, and scaling efficiently. Effective microservices implementation requires cross-functional, autonomous teams and a mature DevOps culture. Organizational change is harder than software change and essential for microservices' success.

Why I'm No Longer Talking to Architects About Microservices

Problem One: No One Knows What a Microservice Is

Problem Two: Microservices Conversations Are Abstract and Unrelated from Business Goals

Problem Three: Microservices Without Organizational Change Is Pointless

The Next Time Someone Mentions Microservices…

“If you listen closely, many of these conversations about microservices are not actually about architecture, but about wanting to work for a different company, where technology is cutting-edge and problems are theoretically interesting, rather than legacy-ridden and constrained by real-world trade-offs.”
Great line.

I’m an architect and I read this so I’m sorry I broke your rule.

Good post, but I have a question. So how do you approach in distributed system, messaging implementations?
Mono talking with it self with a queue in the middle? Would love to see your “solution” for never talking about this again.

<blockquote>
a mature DevOps culture
</blockquote>
agree, we moved to microservices but we can’t even hail the devops guy to help us investigate the issue when a service is down. “Will put that in the backlog” they say…

We’ve stopped referring to Microservices where I work, instead we’ve just gone back to SOA.
Now, where has my book on CORBA gone?