Microservices anti-patterns in Melbourne
This January I was lucky enough to go my favorite tennis tournament, the Australian Open. It’s held every year in Melbourne, which is a wonderful city.
Microservices adoption anti-patterns
While I was there, I gave a presentation on microservices adoption anti-patterns at the Melbourne Microservices Meetup. It’s a significantly expanded version of the keynote that I gave at the O’Reilly Software Architecture conference in London. It starts by describing the essential characteristics of the microservice architecture. After that it covers various anti-patterns including Magic Pixie Dust and Microservices as the Goal. It also describes some technical anti-patterns.
Overview
A typical mission-critical enterprise application is a large, complex monolith developed by large team. The velocity of software delivery is usually slow, and the team struggles to keep up with the demands of the business. Consequently, many enterprise applications are good candidates to be migrated to the microservice architecture. As you might expect, migrating to microservices requires an enterprise to tackle numerous technology-related challenges. But enterprises often encounter obstacles that have less to do with technology and more to do with strategy, process, and organization.
In this talk I describe the essential characteristics of the microservice architecture.You will learn about its benefits and its drawbacks. I describe several anti-patterns of microservices adoption that he’s observed while working with clients around the world. You’ll learn the challenges that enterprises often face and how to overcome them as well as how to avoid the potholes when escaping monolithic hell.
Slides
Read more
Learn about the anti-patterns:
- Microservices are a magic pixie dust - believing that a sprinkle of microservices will solve all of your development problems
- Microservices as the goal - making the adoption of microservices the goal and measuring success in terms of the number of services written
- Scattershot adoption - multiple application development teams attempt to adopt the microservice architecture without any coordination
- Trying to fly before you can walk - attempting to adopt the microservice architecture (an advanced technique) without (or not committing to) practicing basic software development techniques, such as clean code, good design, and automated testing
- Focussing on Technology - focussing on technology aspects of microservices, most commonly the deployment infrastructure, and neglecting key issues, such as service decomposition
- More the merrier - intentionally creating a very fine-grained microservice architecture
- Red Flag Law - retaining the same development process and organization structure that were used when developing monolithic applications.
Avoiding the anti-patterns
Talk to me about my microservices consulting and training services including how I can help your organization avoid these anti-patterns by creating a microservices migration roadmap. In particular, I have a Microservices for leaders class
Premium content and office hours is now available for paid subscribers at 
