managing a microservices development team (and advanced microservice concerns)
DESCRIPTION
So you’re decided to make the transition to a Microservice Architecture. You’ve spent time doing the research. You’ve designed out the responsibilities of each service with your team. You’ve read and memorized the entire article Martin Fowler wrote on the subject. Now, you’re running a team that’s tasked with building some Microservices. You’re built or extracted your first services. You’ve been successfully transmitting data between these services. What next? What should you be aware of? What should keep you up at night? In this talk we’ll begin with a brief introduction to the architecture pattern before covering some of the more advanced topics when developing Microservices, focusing primarily on team management and service design philosophy. We’ll discuss the CAP theorem and why it should be your obsession. We’ll look at how Conway’s Law should be taken seriously and how it can serve as a warning to facilitate better communication between teams. Finally we’ll examine some common pitfalls of Microservices architectures and how they can be mitigated.TRANSCRIPT
THIRDCHANNEL
Managing a Microservices
Development Team
Steve Pember
CTO, ThirdChannel
@svpember
THIRDCHANNEL
THIRDCHANNEL
Agenda
1. Service Design Philosophy (The Tech)
2. Team Organization (Less Tech)
3. What does it mean to be the CTO / Lead Tech person with
Microservices?
Microservices
THIRDCHANNEL
THIRDCHANNEL
Microservices To The Rescue
• Distributed Application
THIRDCHANNEL
THIRDCHANNEL
Service Design
THIRDCHANNEL
Service Design
• A Service is a Bounded Context
THIRDCHANNEL
Service Design
• A Service is a Bounded Context
• CAP Theorem
THIRDCHANNEL
CAP Theorem (Brewer’s
Conjecture)In a Distributed System, can have two of:
• High (C)onsistency
• High (A)vailability
• High (P)artition Tolerance
THIRDCHANNEL
THIRDCHANNEL
THIRDCHANNEL
CAP Theorem (Brewer’s
Conjecture)• High (C)onsistency, (A)vailability, or (P)artition Tolerance
• More of a Sliding Scale, Really
THIRDCHANNEL
CAP Theorem (Brewer’s
Conjecture)• High (C)onsistency, (A)vailability, or (P)artition Tolerance
• More of a Sliding Scale, Really
• Focus on Speed
THIRDCHANNEL
CAP Theorem (Brewer’s
Conjecture)• High (C)onsistency, (A)vailability, or (P)artition Tolerance
• More of a Sliding Scale, Really
• Focus on Speed
• Embrace Eventual Consistency
THIRDCHANNEL
Service Design
• A Service is a Bounded Context
• CAP Theorem
• Data Locality
THIRDCHANNEL
Data Locality
• Spatial: how far away is the data?
THIRDCHANNEL
Data Locality
• Spatial: how far away is the data?
• Temporal: how often is it accessed?
THIRDCHANNEL
THIRDCHANNEL
THIRDCHANNEL
Data Locality
• Spatial: how far away is the data?
• Temporal: how often is it accessed?
• Microservices Goal: Have highly Spatial Data and efficiently
handle Temporal Data.
Team Organization
THIRDCHANNEL
Team Organization
• Multidisciplinary Teams
THIRDCHANNEL
DBAs
Engineers
UX / Design
QA
Front End Service
Internal Tools Services
Order Management Service
THIRDCHANNEL
Team Organization
• Multidisciplinary Teams
• Conway’s Law
THIRDCHANNEL
Conway’s Law
“organizations which design systems ... are constrained to
produce designs which are copies of the communication
structures of these organizations”
-Melvin Conway, 1968
http://en.wikipedia.org/wiki/Conway's_law
THIRDCHANNEL
Team Organization
• Multidisciplinary Teams
• Conway’s Law
• Autonomous Teams
Leadership Responsibilities
THIRDCHANNEL
Leadership Responsbilities
• Keep Teams Aligned with business goals
THIRDCHANNEL
Leadership Responsbilities
• Keep Teams Aligned with business goals
• Drive Microservice Vision
THIRDCHANNEL
Leadership Responsbilities
• Keep Teams Aligned with business goals
• Drive Microservice Vision
• Defend Microservice Vision
THIRDCHANNEL
Leadership Responsbilities
• Keep Teams Aligned with business goals
• Drive Microservice Vision
• Defend Microservice Vision
• Mentor & Educate
In Summary:
Data Locality is Scary
Empower Your Service Teams
Thank you!