The Six Pitfalls of building a Microservices Architecture (and how to avoid them)
•
0 likes•84 views
Thinking of moving to Microservices? Watch out! That quest is full of traps, social traps. If you are not able to handle it, you may be blocked by meetings, frustration, endless challenges that will make you miss the monolith. In this talk, I share my experience and mistakes, so you can avoid them. Creating or migrating to a Microservices architecture might easily become a big mess, not only due to technical challenges but mostly because of human factors: it’s a major change in the software culture of a company. In this talk, I’ll share my past experience as the technical lead of an ambitious Microservices-based product, I’ll go through the parts we struggled with, and give you some advice on how to deal with what I call the Six Pitfalls: The Common Patterns Phobia The Book Club Cult The Never-Decoupled Story The Buzz Words Syndrome The Agile Trap The Conway’s Law Hackers
Recommended
Recommended
More Related Content
What's hot
Similar to The Six Pitfalls of building a Microservices Architecture (and how to avoid them)
Similar to The Six Pitfalls of building a Microservices Architecture (and how to avoid them) (20)
More from J On The Beach
More from J On The Beach (20)
Recently uploaded
Recently uploaded (20)
The Six Pitfalls of building a Microservices Architecture (and how to avoid them)
- 1. The six pitfalls of moving to a Microservices Architecture (and how to avoid them)
- 2. ThePracticalDeveloper.com Intro About me… • Independent Consultant from Málaga, working in Amsterdam. • Solutions Architect at • Book & Blog Author (ThePracticalDeveloper.com) • Love traveling and hiking …and made some mistakes with Microservices
- 3. ThePracticalDeveloper.com The Project •Moving from a Chaotic Monolith to Microservices •Greenfield (starting from scratch) •Lots of new features in the roadmap •Tired of all the Monolith limitations •Almost no experience with Microservices •5 teams: ~25 devs, 5 POs, 1 infra/ops (!!) WHAT COULD POSSIBLY GO WRONG?
- 4. ThePracticalDeveloper.com The six pitfalls •The Agile Trap •The Conway's Law Hackers •The Book Reading Cult •The Never-Decoupled-Enough Story •The Common Patterns Phobia •The Buzzwords Syndrome
- 5. ThePracticalDeveloper.com The Agile Trap (1/6) • Load Balancing • Service Discovery • Gateway • Messaging • Centralized Logging • End-to-End tests • Containerization • Continuous Integration • …
- 6. ThePracticalDeveloper.com The Agile Trap (1/6) •How to deal with it • Prepare a list with all the ‘technical epics’, make it visible. • Take some time to build the foundations • Go Platform-as-a-Service (PaaS), if you can afford it. Do you have support in your organization to achieve this?
- 7. ThePracticalDeveloper.com The Conway’s Law Hackers (2/6) Software Piece 1 Software Piece 2
- 8. ThePracticalDeveloper.com The Conway’s Law Hackers (2/6) Microservice 1 Microservice 2 Microservice 3 YOU’RE A GENIUS
- 9. ThePracticalDeveloper.com The Conway’s Law Hackers (2/6) •How to deal with it • If you apply “Reverse Conway”, be flexible. • Put more focus on Interfaces • Start with a single, small team. • Yes, keep the team SMALL at the beginning and you’ll go faster. • S-M-A-L-L!
- 10. ThePracticalDeveloper.com The Book Reading Cult (3/6) MICROSERVICES ADVANTAGES OF LOOSE COUPLING WE MUST DECOUPLE STUFFTHE EXPERT’S BOOK
- 11. ThePracticalDeveloper.com The Book Reading Cult (3/6) •How to deal with it • READ BOOKS and Put the concepts into practice …using your business case. • Adopt “Evolutionary Software”. Avoid “Perfect Creations”. • Do Continuous Improvements. Don’t feel attached to code. Experiment. • Create “Stage 2” epics and keep them visible.
- 12. ThePracticalDeveloper.com The Never-Decoupled-Enough Story (4/6) •The “Contract Signed” flow • The User signs a Contract digitally • The first Invoice should be generated • We send an email with the Invoice
- 13. ThePracticalDeveloper.com Invoices Service Emailing Service Users Service The Never-Decoupled-Enough Story (4/6) Contracts Servicehttp:// http:// Get user details (address, etc.) http:// Generate invoice Send email
- 14. ThePracticalDeveloper.com Invoices Service Emailing Service Users Service The Never-Decoupled-Enough Story (4/6) Contracts Service Event: Contract Signed Invoice Ready Get user details (address, etc.) Get user email
- 15. ThePracticalDeveloper.com Invoices Service Emailing Service Users Service The Never-Decoupled-Enough Story (4/6) Contracts Service Event: Contract Signed Invoice Ready User Updated (email) User Updated (address) User addresses User emails Always in-sync! Always in-sync!
- 16. ThePracticalDeveloper.com Invoices Service Emailing Service Users Service The Never-Decoupled-Enough Story (4/6) Contracts Service Event: Contract Signed Invoice Ready Get user details (address, etc.) Get user email
- 17. ThePracticalDeveloper.com The Never-Decoupled-Enough Story (4/6) •How to deal with it • Apply DDD and Event-Driven patterns as much as you can but… • Don’t make a drama of having synchronous calls • Create a Microservices Map, keep it updated and visible. • OK-ish? • Too much spaghetti? àWhy Microservices?
- 18. ThePracticalDeveloper.com The Common Patterns Phobia (5/6)
- 19. ThePracticalDeveloper.com Freedom of choice A typical monolith Java Spring MySQL REST Microservice 2 Scala PostgreSQL GraphQL Microservice 1 Spring Boot MariaDB REST Microservice 3 Node.js Neo4j AMQP Microservice 4 ?
- 20. ThePracticalDeveloper.com The Common Patterns Phobia (5/6) •How to deal with it • How far do you want to go? Make it clear. • Nothing / Guidelines / Common code (libraries) / Rules • Explain it. Why Common Guidelines? • Get some consensus. • Write down the decisions • And their reasons and their constraints. See tpd.io/adr.
- 21. ThePracticalDeveloper.com The Buzzwords Syndrome (6/6) • Microservices • Event-Driven Architecture • Reactive Programming • Serverless (lambda architecture) • Blockchain • Internet of Things • DevOps • Big Data • “Moduliths”
- 22. ThePracticalDeveloper.com The Buzzwords Syndrome (6/6) •How to deal with it • Don’t use buzzwords if you’re not sufficiently informed. • Use Critical Thinking, Be Pragmatic and Realistic. • Challenge: come up with design and a plan. • There should always be a reason! • Remember to write it down.
- 23. ThePracticalDeveloper.com Wrapping up •Microservices are not the solution to all your problems. •Start with a small team (better boundaries and interfaces) •Make your plan, guidelines and decisions visible to everybody. •Learn from books, but also from experienced people. •Don’t be afraid of starting with a Monolith.