Microservice Architectures

Microservice Architectures at InVision

Transcript

1. Microservice Architectures Don’t Do This
2. Microservices
3. Microservices “the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API” - Martin Fowler
4. Microservices “Mo Services Mo Problems” - Me
5. Don’t Do This
6. Don’t Do This • Seriously, don’t do this • Consider a Majestic Monolith • Take on microservices begrudgingly • Wait until > 5 teams / 25 developers
7. It’s Not About Tech
8. It’s About Business • Scale the product organization • Fast product delivery at 10s -> 100s -> 1000s of developers • Microservices enable horizontal scaling of teams
9. Architecting The Product Org
10. Business Domains • “Bounded Contexts” - Domain Driven Design ◦ A logical boundary in the business domain • High cohesion within a bounded context, low coupling between ◦ Align your services within bounded contexts
11. Team Structures • Conway’s Law ◦ “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” • Organize your teams to reflect the system design you desire ◦ Teams own one or more bounded contexts
12. Venn Diagram!
13. Team Incentives • Objectives and Key Results (OKRs) ◦ A way to incentivize and align multiple teams / business groups ◦ Popularized by Google • Align business domains with teams incentivized to work on them
14. InVision
15. InVision Business Domains aka - shameless plug
16. Prototypes
17. Boards
18. Freehand
19. Studio
20. Comments
21. Inspect
22. InVision Product Org
23. InVision Product Org • A team owns one or more business domains • The team owns the services for those domains • Formal handoff to transfer domain ownership ◦ Driven by staffing and by incentives
24. My Team • We own the prototype sharing domain & the studio sharing domain • We own the Single Page Apps and Backend for Frontend for both domains • To better align with incentives we are: ◦ Taking ownership of the studio domain service ◦ Relinquishing ownership of the prototype sharing spa/bff
25. It’s A Little Bit About Tech
26. Architectural Patterns • API Gateway ◦ Single point of entry for all requests • Backend for Frontend ◦ Owns aggregation for a specific frontend • Domain Services ◦ Owns data storage for a business domain • Database per Service ◦ Each domain service has its own database • Core Services ◦ Generic services with no business logic
27. Remember: Don’t Do This ;-)