PHPEM- JULY 2015

Transcript

1. M&Ms - Sweet Monoliths and Micro-services Shaun Hare - July Meetup 2015
2. The modern monolith Talk about the monolith briefly - the typical approach - discuss legacy and know that not all projects even that well
3. particular way of designing software applications as suites of independently deployable services Martin Fowler March 2014 Micro- services
4. Micro-services - currently at top of hype cycle
5. became interested because inspired by large sites Bastian Hoffman - PHP community lead developer at Research Gate
6. The Amazon.com website application calls 100-150 services to get the data that used to build a web page.
7. The term “micro-service" was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring.
8. • Individual apps are simpler to understand • Better isolation of bugs • Ability to mix different languages or technologies • Easier to migrate the technology stack Why
9. • NO - many factors but there are a few things that mean it does not suit us So is a monolith so bad?
10. • The large code base slows the productivity. • We will over time reduce quality of the code. • Any original modularity will be eroded. • The monolithic application prevents the developers from working independently. • The whole team must coordinate all development and redeployments efforts. Why can a monolith be bad?
11. • Look in BL identify solid interfaces within code • packages and modules • choose business related tasks e.g get user Splitting the monolith
12. Also worth noting Monolith Micro-services
13. • Component level , each service is a component where each piece can be replaced independently from the others. • Fulfils business activity - not technological requirement • Allow for technology heterogeneity. • Decentralised data management with one database for each service instead of one database for a whole application. • Infrastructure automation with continuous delivery being mandatory. Key features of Micro-services
14. • Api Gateway • Direct client connection • Message bus Organisational Patterns
15. Api Gateway App SPA MC S3 S2 S1 MVC App S4 API Gateway
16. Direct App S3 S2 S1 SPA
17. Message bus App S3 S2 SPA S1 Message Bus
18. • Increased network usage: micro-services need to talk http is this going to be a substantial increase in traffic. • Securing communication between micro-services: more chatter, more opportunities for a gap in transport security ? • Security audits: more moving parts and less coherence does this mean more places for security vulnerabilities to hide • Are we able to deal with the complexity of multiple services Questions I had / have
19. • Testing: is testing a system of services harder or easier than testing monolithic applications? • Difficulty in production monitoring: are existing monitoring tools up to the task? • Lowered uniformity: microservices allow team members to choose their language, tool chains, etc. While fashionably polyglot, does this increase maintenance overhead? • Must we use containers - e.g. docker to deploy Questions (cont)
20. • Authentication - verify the identity of user • Authorisation - determine if a user can access a resource • In a micro service context this means - • Create a authentication service • Authorisation in each service Auth
21. • Stateless Authentication important - enter Oauth2.0 and Json web tokens Authentication
22. • Roles - Resource owner, auth service, client and resource server • Grant types - Authorisation code , Implicit , Password Credentials and Client Credentials Quick overview of oAuth2
23. • Replaces access token for client credential request • header.payload/claims.signature Can therefore also hold some authorisation info JWT
24. JWT
25. • One issue when growing number of services is discovery • There are tools - ZooKeeper , consul, etcd Service Discovery
26. • frequent/realtime updates to the records to strip out stale information • Easy integration into your application • Aware of starting and stopping. Service Discovery
27. Create a service boilerplate as a template to develop and deploy the new service. This service boilerplate must account for polyglot technologies including application servers, database, programming language, etc… Service scaffolding
28. • Monitoring, log collection, metrics, security and safety mechanisms (like timeout, circuit breakers). Boilerplate guides
29. • Ping Methods • Lightweight • Stateless (always) • filterable,pagination ready Good Api design
30. • Monoliths are not bad • Services should allow flexibility • Good for and environment like ours where we are dealing with lots of read only data Conclusion