Upgrade to Pro — share decks privately, control downloads, hide ads and more …

PHPEM- JULY 2015

PHPEM- JULY 2015

Avatar for Shaun Hare

Shaun Hare

July 02, 2015
Tweet

More Decks by Shaun Hare

Other Decks in Technology

Transcript

  1. The modern monolith Talk about the monolith briefly - the

    typical approach - discuss legacy and know that not all projects even that well
  2. particular way of designing software applications as suites of independently

    deployable services Martin Fowler March 2014 Micro- services
  3. became interested because inspired by large sites Bastian Hoffman -

    PHP community lead developer at Research Gate
  4. 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.
  5. • Individual apps are simpler to understand • Better isolation

    of bugs • Ability to mix different languages or technologies • Easier to migrate the technology stack Why
  6. • NO - many factors but there are a few

    things that mean it does not suit us So is a monolith so bad?
  7. • 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?
  8. • Look in BL identify solid interfaces within code •

    packages and modules • choose business related tasks e.g get user Splitting the monolith
  9. • 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
  10. • 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
  11. • 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)
  12. • 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
  13. • Roles - Resource owner, auth service, client and resource

    server • Grant types - Authorisation code , Implicit , Password Credentials and Client Credentials Quick overview of oAuth2
  14. JWT

  15. • One issue when growing number of services is discovery

    • There are tools - ZooKeeper , consul, etcd Service Discovery
  16. • frequent/realtime updates to the records to strip out stale

    information • Easy integration into your application • Aware of starting and stopping. Service Discovery
  17. 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
  18. • 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