Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Embracing Microservices Design

You're reading from   Embracing Microservices Design A practical guide to revealing anti-patterns and architectural pitfalls to avoid microservices fallacies

Arrow left icon
Product type Paperback
Published in Oct 2021
Publisher Packt
ISBN-13 9781801818384
Length 306 pages
Edition 1st Edition
Concepts
Arrow right icon
Authors (3):
Arrow left icon
Ovais Mehboob Ahmed Khan Ovais Mehboob Ahmed Khan
Author Profile Icon Ovais Mehboob Ahmed Khan
Ovais Mehboob Ahmed Khan
Timothy Oleson Timothy Oleson
Author Profile Icon Timothy Oleson
Timothy Oleson
Nabil Siddiqui Nabil Siddiqui
Author Profile Icon Nabil Siddiqui
Nabil Siddiqui
Arrow right icon
View More author details
Toc

Table of Contents (16) Chapters Close

Preface 1. Section 1: Overview of Microservices, Design, and Architecture Pitfalls
2. Chapter 1: Setting Up Your Mindset for a Microservices Endeavor FREE CHAPTER 3. Chapter 2: Failing to Understand the Role of DDD 4. Chapter 3: Microservices Architecture Pitfalls 5. Chapter 4: Keeping the Replatforming Brownfield Applications Trivial 6. Section 2: Overview of Data Design Pitfalls, Communication, and Cross-Cutting Concerns
7. Chapter 5: Data Design Pitfalls 8. Chapter 6: Communication Pitfalls and Prevention 9. Chapter 7: Cross-Cutting Concerns 10. Section 3: Testing Pitfalls and Evaluating Microservices Architecture
11. Chapter 8: Deployment Pitfalls 12. Chapter 9: Skipping Testing 13. Chapter 10: Evaluating Microservices Architecture 14. Assessments 15. Other Books You May Enjoy

Lack of team alignment

A general rule of microservices is that one team must be aligned or made responsible for a microservice. Ideally, this will be one team per service, but this is not always possible due to limited resources. However, a team can have responsibilities for multiple services, which is common. One team may be responsible for multiple services, but a service should never have multiple teams working on it. One team must have responsibility for the analysis, development, and deployment of a service.

As with most rules, there are exceptions, and there are some rare cases where this may not be possible and where we may need two teams to share responsibility for a service, and teams will have to work together and share responsibility for a service due to organizational or other constraints. DDD calls this a shared kernel, and this requires a high level of communication between the teams sharing the service. We will explore shared kernels in depth later on in the DDD...

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €18.99/month. Cancel anytime