The Why and How of Applications with APIs and microservices
2 likes464 views
This document discusses how to build Drupal applications using microservices and APIs. It begins with background on microservices and the problems they aim to solve like speed, scalability, resilience and testability. It then covers microservice principles like bounded context and independent deployability. The document discusses microservice architecture, integration using message-based approaches and asynchronous messaging. It provides an example of a hotel booking service broken into multiple microservices. It concludes with notes on testing, monitoring, security and API gateways when using a microservices approach.
More Related Content
Similar to The Why and How of Applications with APIs and microservices (20)
The Why and How of Applications with APIs and microservices
- 1. How to build Drupal Applications with APIs and microservices Ronald Ashri - @ronald_istos technical strategy director - @DeesonAgency and why
- 2. background in agent-based software engineering and distributed AI an agent is a computer system capable of flexible, autonomous action in a dynamic, unpredictable and open environment
- 3. background in agent-based software engineering and distributed AI an agent is a computer system capable of flexible, autonomous action in a dynamic, unpredictable and open environment microservice heterogeneous
- 4. what are the problems we are trying to solve
- 7. speed
- 9. testability
- 10. replaceability
- 11. the non-microservice way makes it less likely to address these problems
- 12. single application / single codebase or badly implemented SOA leading to tight coupling hard to support concurrency / partitioning hard to support efficient testing fear stops us from moving fast
- 13. does not handle the human issues - control - reliability - consistency - technical debt over time - knowledge management
- 14. we’ve been building monoliths long enough to know that despite the best intentions it rarely ends well - especially in large orgs with multiple teams
- 15. the microservices way - guiding principles
- 16. bounded context
- 17. do one thing well
- 18. comprehensible
- 20. deployed through automated process builds
- 21. message-enabled
- 22. composable
- 24. a system that makes change easy, safely at scale
- 25. a cohesive system “gather together those things that change for the same reason, and separate those things that change for different reasons” Robert C.Martin’s Single Responsibility Principle
- 26. a loosely coupled system “The greater the cohesion of individual modules in the system, the lower the coupling between modules will be.” —Larry Constantine and Edward Yourdon, authors of Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design
- 28. there is no ideal size the answer is 42 ;-)
- 29. 29 OPTIONALSECTIONTITLE from Microservice Architecture by Irakli Nadareishvili et al
- 30. use domain-driven design principles to identify the right boundaries for your problem https://www.martinfowler.com/bliki/BoundedContext.html
- 31. designing as a monolith with modular / component based design and then breaking it up is a valid strategy
- 32. if in order to implement a change you end up touching lots of different microservices something is wrong - couple loosely
- 33. Don’t start by designing data models - focus on business capabilities REST CRUD services are not the objective
- 34. If concerned about dependency on data stores delay implementation to the end. Build interfaces, models, mock replies and push back on the final data store.
- 35. DO NOT SHARE A DB. introduces tight coupling reduces cohesion
- 37. message-based I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is “messaging.” —Alan Kay
- 38. “(…) for far too long, developers have viewed APIs and web services as tools to transmit serialized “objects” over the wire. However, a more efficient approach is to look at a complex system as a collection of services exchanging messages over a wire.” Microservice Architecture by Irakli Nadareishvili et al
- 39. Netflix uses protocols like Avro, Protobuf and Thrift internally and JSON over HTTP for external consumers
- 40. Hypermedia driven package data together with description of possible actions HATEOS - Hypermedia as the engine of application state
- 41. event-sourcing a stream of facts about how our entities are changing - deposited £10 to account - cash - paid £5 for dinner - deposited £5 - salary - paid £3 for cinema balance: £7
- 42. event-sourcing data model vs structural data model events are the record of all that has happened with current application state being the result a structural data model shows us the current state with no background information - deposited £10 to account - cash - paid £5 for dinner - deposited £5 - salary - paid £3 for cinema balance: £7
- 45. micro services - in (micro) practice
- 47. hotel booking service channels cannot add a channel without redeploying entire site if a channel changes need to redeploy site site will be blocked as it is trying to update separate channels …
- 49. channels hotel booking service Amazon SQS coupled drupal to SQS- specific implementation will need to redeploy hundreds of sites on each change
- 50. channels hotel booking service Amazon SQS listener (silex app)
- 51. channels hotel booking service Amazon SQSlistener channel manager channel A channel B
- 52. channels hotel booking service queuelistener channel manager channel A channel B gateway
- 53. channels hotel booking service queuelistener channel manager channel A channel B gateway
- 54. What next
- 56. if you take one thing away - it is these four things • Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. • Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input. • Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them. • Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them. From the 1978 Bell Labs UNIX Timesharing system doc
- 57. questions? Ronald Ashri - @ronald_istos technical strategy director - @DeesonAgency