MicroServices - How Do I Build Them - Edinburgh October 2016

Transcript

1. Microservices What Are They? How Do I Build Them?
2. $(whoami) • Scott Pringle • PHP Developer @ People’s Postcode Lottery • Microservices Advocate • DDD Edinburgh Organiser (soon)
3. What are they? Software design architecture of separating an application into a suite of small, independent services. Independent applications with no dependencies on any other services. Exposed via a pre-defined API for external consumers
4. Should I Build Them? • Do you have a DevOps culture? • Can you define clear boundaries for your internal domain? • Do you have a reasonable sized team? • Is your application more resource heavy in certain contexts?
5. Advantages
6. Smaller Apps & Teams • The less your app has to do, the less complex it (should) be • Easier to understand the purpose of the code • Separate teams based on service boundaries • Manage knowledge within teams easier • Designate internal leaders to manage workflow
7. Testability • The more defined your context is, the easier it is to test • Test suite will be smaller and quicker to run • Unit and Integration tests are fast - use them
8. Deployability • Only deploy the service that’s changed • Deploy with confidence
9. Protocol Agnostic • Generally services are exposed over HTTP • What about non-web services? • So long as the service can respond, any (reasonable) protocol can be used
10. Polyglotism • Every service can be written in any language • Use the tools that are right for the job • Can result in complex systems with too much variation - Proceed with caution
11. Redundancy • Both an advantage and disadvantage • Consumers need to be redundant to handle a service not working • Should result in better uptime for customer-facing applications
12. Disadvantages
13. Cross Service Transactions • Avoid, avoid, avoid • If one part fails, how do you roll back everything? • Use queues (RabbitMQ/SQS) and dispatch events to a stream
14. Eventual Consistency • Data can’t be expected to be permanently consistent across services • Read models may be updated from multiple sources
15. Service Discovery • Services need to be load balanced • Can’t expose specific ports for a service • Getting easier with Docker SwarmKit
16. Harder to test But you said they’re easier to test! Unit tests are easier as you know the boundaries of each individual service and it’s collaborators Functional tests are nearly impossible
17. Denormalized data
18. Denormalized Data • Don’t use the same database server… • ...Even with separate databases • Most databases are in Third Normal Form • Services should know everything about their own context, nothing else
19. Reporting • Push all data to one central store used ONLY for reporting / business intelligence • Amazon Redshift • Google BigQuery • Do not use this data for transactional information • Automatically updated views/queries for reporting • Stream processing of events for eventual consistency
20. That Sounds Difficult!
21. CQRS To The Rescue • Have as many read models as your system requires • Build domain logic to handle commands/writes • Reads interact directly with the data-store • Use whatever data-store makes sense for the read model
22. Commands • Abstract business logic out of controllers / CRUD relations • Validate all data before submitting a Command • Commands should store and dispatch events to a queue
23. Events • Log all events • Don’t risk losing an audit trail • Use events to update your read model via a PubSub queue • Ideal scenario: Using events to replay your entire history (EventSourcing)
24. What About Dev Environments?
25. Problems... • Machines only have a certain amount of memory • Don’t want to checkout 50+ services to run 1 application
26. TIP Only run the services you need to
27. Be Selective • Only run the services you actually need to test • You’re only going to be add/updating 1 or 2 parts of the system, run those services
28. TIP Share your resources!
29. Shared Resources • Only do this for development… • No need to run 15 MySQL Containers/Instances on a local machine
30. TIP Provide an SDK to application teams
31. Application SDKs • Provide an SDK for every language / framework being employed to build an application ◦ Or at least a versioned API with spec • Expose your MicroService API via a public API • Only need to update the SDK • Provide a mock service for development
32. TIP Define your API without implementation
33. RAML / Swagger • Pre-defined API • Contract created for API at the beginning of development • Consumers can continue working without complete services
34. Example RAML - Types #%RAML 1.0 title: Microservice Demo version: v1 baseUri: https://api.edpug.co.uk mediaType: application/json types: User: type: object properties: id: integer email: string
35. Example RAML - Endpoint /users: get: responses: 200: body: application/json: type: User[] example: | [ { "id": 1, "email": "me@scottpringle.co.uk" } ]
36. Example RAML - Endpoint continued /users: put: body: application/x-www-form-urlencoded: properties: email: type: string responses: 201: body: application/json: type: User example: | { "id": 1, "email": "me@scottpringle.co.uk" } 409: body: application/json:
37. How Does This Affect PHP?
38. Slim Lumen Silex
39. Thanks For Having Me! @Luciam91 Slides http://speakerdeck.com/Luciam91
40. Domain Driven Design Edinburgh Looking for a venue & sponsors Interested? dddedinburgh@scottpringle.co.uk @DDDEdinburgh January 2017