Innovation Without Asking Permission
1 like•400 views
The document discusses strategies for service decomposition to transition from monolithic to microservices architecture, emphasizing three approaches: strangle, extract, and extend. It highlights the importance of bounded contexts and API design in facilitating innovation and continuous experimentation in software development. Additionally, it addresses the challenges and benefits of distributed systems and the need for effective technology selection and maintenance.
Innovation Without Asking Permission
- 1. @DaggieBe#DevoxxPL Platinum Sponsor: Innovation Without Asking Permission Bart Blommaerts BB Consulting
- 2. bbconsulting.be Bart Blommaerts Application Architect BB Consulting @DaggieBe
- 3. 3 Blockchain DeepLearning Serverless Reactive Software development is awesome
- 4. 4 Chained Learned nothing ServerError Radioactive Legacy applications …
- 5. Observation: There's a colossal gap between a lot of solutions presented at conferences and the kinds of problems many folks are actually trying to solve. Robert Smallshire (@robsmallshire)
- 7. Service Decomposition Three Approaches to Moving From a Large Monolith to Smaller Services Strangle Extract and re-implement. Extend Prevent the monolith from becoming larger. Split Focus on data. Look for high cohesion and low-coupling. @DaggieBe
- 8. • Conduct a dependency analysis • Focus on the data • Split off one by one and validate • Learn and refine Split @DaggieBe
- 9. • Existing functionality is extracted and re-implemented • Use an Anti Corruption Layer for decoupling • Make the monolith smaller Strangle @DaggieBe
- 10. • Minimise impact on the existing application • Implement new features as separate services • Use an Anti Corruption Layer for decoupling • Prevent the monolith from growing Extend @DaggieBe
- 11. You do not need to stick to a single approach.
- 12. Anti-Corruption Layer Decouple domain models Enforce bounded contexts Focus on good APIs Translate to / from different models
- 13. Anti-Corruption Layer Deal with data access: - Shared repository - Data synchronised repository - Event-Driven synchronised repository @DaggieBe
- 19. What is an event? Something that has happened in the past. Types of data An event can contain 3 types of data data it owns data it needs reference data @DaggieBe
- 22. Identify domains Focus on business capability BusinessCapability Don’t focus on technology layer TechnologyLayer @DaggieBe
- 23. domain: - mail delivery sub domains: - optimal route calculation - geographical division - product management - people - constraints - … Identify bounded contexts @DaggieBe
- 25. Talk to business stakeholders Identify bounded contexts @DaggieBe
- 26. Look at the data Identify bounded contexts @DaggieBe
- 27. Look at the code Identify bounded contexts @DaggieBe
- 28. Between bounded contexts, multiple integration patterns are possible Identify bounded contexts @DaggieBe
- 30. 3. Demo
- 31. Observation: There's a colossal gap between a lot of solutions presented at conferences and the kinds of problems many folks are actually trying to solve. Robert Smallshire (@robsmallshire)
- 32. 4. APIs
- 33. Examples: - Paypal: https://developer.paypal.com/docs/api/ - Zalando: https://zalando.github.io/restful-api-guidelines/ - GitHub: https://developer.github.com/v3/ - Stripe: https://stripe.com/docs/api#intro - Microsoft: https://github.com/Microsoft/api-guidelines/ - Travis: https://docs.travis-ci.com/api/ - Adidas: https://github.com/adidas-group/api-guidelines - … API Guidelines @DaggieBe
- 34. Postel’s Law: Be conservative in what you do, be liberal in what you accept from others. Jon Postel
- 35. Quickly repurpose top innovation before global communities. Documented API Swagger HAL RAML Avro Schemas @DaggieBe
- 36. 5. Without asking permission?
- 37. Continuous Experimentation Microservices enable experimentation Feature toggles Dynamically enable or disable features Traffic routing Route your traffic to your experiments Data-driven decision making Monitoring and telemetry to observe behaviour @DaggieBe
- 38. Distributed systems are hard Fallacies of distributed computing Benefits Loose coupling, enabling innovation, … Drawbacks Moving parts, transport, consistency, … @DaggieBe
- 39. Maintenance Microservices enable technology introduction No free lunch Dedicate time to technology selection DevOps End-to-end responsibility @DaggieBe
- 40. Middleware Runs on my machine … Dependencies Containers without orchestration? Suitable infrastructure Database, messaging bus, monitoring, … @DaggieBe
- 41. GREG YOUNG - 5 common reasons DDD projects fail and how to avoid them https://skillsmatter.com/skillscasts/1431-greg-young-ddd-projects Sources MARTIN FOWLER - Richardson Maturity Model https://martinfowler.com/articles/richardsonMaturityModel.html WIKIPEDIA - Fallacies of distributed computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing IEEE Software - Continuous Experimentation https://ieeexplore.ieee.org/document/8255793/ DEMO - Postal Demo https://github.com/bart-blommaerts/postal-demo DEMO - Postal Calculator https://github.com/bart-blommaerts/postal-calculator @DaggieBe