Slicing and Dicing with Consequences: The Effect of Microservices on API Design
Download as PDF, PPTX1 like464 views
The document discusses the impact of microservices on API design, highlighting the shift from monolithic applications to microservices that allow for continuous updates and greater agility in response to changing business requirements. It identifies challenges involved in defining services, deployment units, and client engagement, proposing solutions like mapping business operations and implementing the API gateway pattern for better management and orchestration. The author, Al Tsang, emphasizes the importance of treating everything as a resource and utilizing CQRS to enhance API engagement and efficiency.
More Related Content
Similar to Slicing and Dicing with Consequences: The Effect of Microservices on API Design (20)
More from SmartBear (20)
Slicing and Dicing with Consequences: The Effect of Microservices on API Design
- 1. The Effect of Microservices on API Design by Al Tsang @altsang Slicing and Dicing with Consequences
- 2. Background
- 3. About Al 9/25/2017 Express Gateway 3 Wrestled with this technical “alligator” as both practitioner and vendor Founder and CEO of LunchBadger Co-Founder and CTO of StrongLoop (acquired by IBM, 2015) VP of Engineering (Platform, eCommerce) at Shutterfly VP of Engineering at cFares OSS Community Member and Contributor LoopBack Express Gateway
- 4. Monolith vs. Microservices 9/25/2017 Express Gateway 4 Business requirements change rapidly AND continuously – so the need for shipping updated version of your app are increasing exponentially. A microservice app Continuous updating in parts. A monolithic app All or nothing — a big, giant thing that can’t fit through the shipping door. vs.
- 5. Microservices: an ideal that’s been out there for a long time Decades of best practices in the modern web era Web-scale experiences (Amazon, Google, Netflix, etc) Cloud native technologies Microservices as individual processes Processes encapsulated in containers Containers orchestrated 9/25/2017 Express Gateway 5
- 6. Microservices and APIs The natural evolution of microservices are APIs to the “N” client - client traditionally was built by the company, but now can be built by anyone APIs = business leverage and amplification 9/25/2017 Express Gateway 6
- 7. Challenges
- 8. An Architectural Style, Not a Fixed Blueprint Microservices are the new norm – but also more of an architectural style There are too many ways to slice and dice 9/25/2017 Express Gateway 8
- 9. Problem #1: Services can be discreetly defined in many ways – Business capability – Domain and subdomains – Model 9/25/2017 Express Gateway 9
- 10. Problem #2: Deployment units can vary in granularity – How many services per host? – What services per host? 9/25/2017 Express Gateway 10
- 11. Problem #3: APIs are at another level 9/25/2017 Slicing and Dicing with Consequences 11 Optimal microservices at odds for consumption 2 1 3 customer name Item with info rating 1 2 3 – APIs = engagement – Engagement requires mashups/aggregation – Too big, hard to maintain
- 12. promotions Customer name1 4 Problem #4: Each Engagement Has Different Permutations 9/25/2017 Slicing and Dicing with Consequences Clients can be unknown and clients can be many – APIs must somehow be dynamic Item + description2 rating3 customer name1 item + descript2 item + descript2 item + descript2 Item + description2 rating3
- 13. v customer name1 Item + long description 2 imageX personalization Z promotions4 Problem #5: Many Engagements 9/25/2017 Slicing and Dicing with Consequences 13 2 1 3 promotions personalization customer name music Z 1 s 4 + ? = z s 4 x customer1 item + desc2 item + desc2 item + desc2
- 14. Solutions
- 15. Problem: Services can be discreetly defined in many ways – Business capability – Domain and subdomains – Model Solution Step #1: Start a map – Map your business with entities first and then with operations – Bubble up first class operations – Treat EVERYTHING as a resource 9/25/2017 Express Gateway 15
- 16. Problem: Deployment units can vary in granularity – How many services per host? – What services per host? Solution Step #2: Continue the map – Look at your past consumption and project your future consumption – Mark your hotspots for deployment granularity AND scale
- 17. 2 1 3 Solution 9/25/2017 Express Gateway Step #3: CQRS – Aggregate query models (presentation) – Finite command models (actions) Problem: Optimal microservices at odds for consumption – APIs = engagement – Engagement requires mashups/aggregation – Many unknown clients = many engagements promotions personalization customer name music Z 1 s 43 + = All Step #3 problems can be solved with CQRS
- 19. Means to an End: The API Gateway Pattern Centralized Middleware Public APIs – Authentication – Security – Traffic Control – Ops – Logging – Transformations – Etc API Gateway 9/25/2017 Express Gateway 19 Client Only for internal usage Only for specific partners AWS Lambda, etc
- 20. Means to an End: The API Gateway Pattern Dynamic Orchestration and Mashup – Optimized endpoints – Request collapsing – And more – GraphQL API Gateway Invoices DB schema Customers DB schema Orders DB schema 9/25/2017 Express Gateway 20 Client
- 21. 9/25/2017 Express Gateway 21 Wrap Up
- 22. Quick Plugs: Express Gateway 9/25/2017 Express Gateway 22 Backed by:
- 23. Quick Plugs - LunchBadger Build, manage, and deploy your microservices as APIs through one unified experience: – Express Gateway - Management – Express (LoopBack) - Composition – Docker and Kubernetes - Cloud Native Portable Runtime 9/25/2017 Express Gateway 23
- 24. Join Us! 9/25/2017 Express Gateway 24 Express Gateway www.express-gateway.io github.com/ ExpressGateway/express-gateway @express_gateway facebook.com/ExpressJSGateway Lunchbadger www.lunchbadger.com @lunchbadger facebook.com/LunchBadger