Más contenido relacionado

Similar a Introduction to microservices(20)


Introduction to microservices

  1. Introduction to Microservices
  2. About Me! Anil Allewar • Technology Evangelist & speaker • Core interests: Cloud, Enterprise, Mobile
  3. Agenda • What are Microservices? • SaaS and 12-Factor apps • Typical Use Cases • Why Microservices? • Characteristics
  4. Software Architecture Evolution
  5. Monolith
  6. Microservices
  7. Crux of Microservices Bounded business context
  8. What are Microservices actually? Services build around bounded business context Independent development, testing and deployment Interact with end-user and with each other using well defined contract De-centralized data management and governance Automated deployments Intelligence in the endpoints and dumb pipes
  9. Agenda • What are Microservices? • SaaS and 12-Factor apps • Typical Use Cases • Why Microservices? • Characteristics
  10. SaaS & 12-Factor Apps Software-As-A-Service • Subscribe to software – periodic contract • Scalability – horizontal • Multi-tenancy 12-Factor apps • Methodology for building SaaS apps Majority of Microservices & distributed system concerns are defined by 12-factor methodology
  11. 12-Factors 1. Codebase • Single codebase for one app - tracked in revision control • If more than 1 app then each has it’s own codebase - distributed system 2. Dependencies • Declared explicitly through dependency manifest - gradle, maven, npm • Dependency isolation - no implicit dependencies, gradle dependencyManagement for exact version of dependency • Simplify developer setup • Project dependencies - build system (gradle) • Runtime dependencies - containers (docker, linux lxc)
  12. 12-Factors 3. Processes • Stateless - share nothing • Persistent data needs to be stored in stateful backing service like database 4. Port binding • Export HTTP as a service by binding to a port • In built web server like Tomcat for Spring boot 5. Concurrency • Different process models for different tasks - WebServer for HTTP, workers for background • Multiple processes on multiple machines - easy to scale out
  13. 12-Factors 6. Config • Strict separation of config from code • Hosted externally or setup as environment variables 7. Backing services • Databases, message queue system, S3 etc • Treat as attached resources accessed over a URL • No code changes needed for resource swap - local mySQL with RDS 8. Build, release run • Strictly separate build (say gradle), release(say Jenkins) and run (say docker orchestration) • Ability to rollback to previous release
  14. 12-Factors 9. Disposability • Started or stopped at moments notice • Pets v/s Cattle 10. Dev/prod parity • DevOps, quick deploys • Use Docker and external configuration 11. Logs • Treat logs as event streams routed to common destination • ELK stack, Fluent etc
  15. 12-Factors 12. Admin processes • One off administrative maintenance tasks like database migration, running one-time scripts • Must ship with application code
  16. Agenda • What are Microservices? • SaaS and 12-Factor apps • Typical Use Cases • Why Microservices? • Characteristics
  17. Communication
  18. Silos
  19. Business Agility
  20. Scale Cube To ensure scalability – applications should be able to scale in at-least 2 axis
  21. Agenda • What are Microservices? • SaaS and 12-Factor apps • Typical Use Cases • Why Microservices? • Characteristics
  22. Who is doing microservices?
  23. Monolith Horizontal scaling 3-4 months gestation Fear of release Quicker competitorsGo-live firefighting Unintended side effects Recruitment Monolith Release – 4 months
  24. Chipping The Monolith
  25. Large Distributed System APIGateway (Zuul) Config Server Registry/Di scovery (Eureka) Circuit Breaker (Hystrix) Web Portal Web Service 1 Web Service 2 Web Service 3 Web Service 4 DB2DB1 Auth Server Auth-DB Ribbon RibbonRibbon Web Apps Mobile Apps 3rd Party Integration Github Registry Dashboard Health Dashboard OAuth 2.0 Security Metering Load Bal Routing
  26. Agenda • What are Microservices? • SaaS and 12-Factor apps • Typical Use Cases • Why Microservices? • Characteristics
  27. Characteristics of Microservices Componentization via Services Organized around Business Capabilities Products not Projects Smart endpoints and dumb pipes Decentralized Governance Decentralized Data Management Infrastructure Automation Design for failure Evolutionary Design Aligned towards developing cloud native SaaS application following Twelve Factor Apps
  28. Componentization via Services Any Failure means redeploy entire application Failures means only that microservice is redeployed. Circuit Breakers can help stop propagate the effect May or May not have published interfaces between components Restful APIs mostly are the published interfaces.
  29. Organized around Business Capabilities
  30. Products not Projects Project Model Product Model Amazon Model- You Build it, You run it !
  31. Decentralized Governance nodejavarubyR hbase redismysql
  32. Decentralized Data Management
  33. Infrastructure Automation Continuous Delivery A Must Monolith Microservice
  34. Design for failure Microservices needs following to function 1. Circuit Breaker – Fallback Response 2. Detect Failure Early 3. Automatic Restore
  35. Evolutionary Design Drive modularity through the pattern of change Ongoing service decomposition - independent replacement and upgradeability You want to keep things that change at the same time in the same module
  36. Microservices - Challenges If you can’t build a well-designed modular monolith, what makes you think Microservices is the answer? – Simon Brown If not well designed – Microservices would become distributed ball of mud (though more modular!) Well defined software modules in monolith(Domain Driven Design) is pre-requisite to converting it to micro-services Hence always try to start as monolith (more agile) and then decompose to Micro-services once modularity & complexity is prime concern
  37. Organization & Architecture Changes Attempt Microservices to transform your business Microservices will trigger organization change Learning organization Deliberate & discuss – benefits v/s risks Versioning of contracts between services Dormant Monolith Automation and DevOps intrinsic to Microservices
  38. Organization & Architecture Changes Monolith first - Version 1.x of system Domain driven design – services with well defined seams Peel off Microservices once complexity and scaling needs affect productivity & innovation Invest in product management and QA Containers & Orchestration
  39. Considerations Upfront planning & decomposition of business services - else spaghetti architecture Avoid distributed monolith – Things that change at the same time should be in the same service Monitoring Microservices is order of magnitude harder – deployment map & health status Centralized logging, alerting and distributed tracing - critical to debug & resolve production issues Circuit breakers to prevent chain of failure
  40. Considerations Issue in service A could be because of input from service B or messaging queue - APM tools & strong service contracts to isolate root cause Services graph - Dependency and version management IT Governance – streamline tools & methodology Track what service API gets exposed and their security Consumer driven contracts for robust API – check out Pact / PactJVM
  41. Microservices Frameworks
  42. Spring Stack - Java Spring Boot, Spring Cloud withNetflix OSS/Consul Most stable and mature Microservices platform Opinionated view of building production applications using Spring framework – convention over configuration Supports both synchronous HTTP and reactive micro- services Additional support for streams, tasks, AWS, distributed tracing etc.
  43. Vert.x Vert.x is a tool-kit for building reactive applications on the JVM Event-driven and non-blocking using asynchronous message passing Can be used with multiple languages including Java, JavaScript, Groovy, Ruby, and Ceylon Based on Java 8 so you can write elegant code using lambda and streams
  44. Lightbend Lagom Lagom is an integrated microservice platform built in Scala APIs initially are provided for Java services, with Scala to follow Provides for asynchronous communications and event- sourcing (capture all changes to the application as a sequence of events)
  45. Seneca Seneca is a Microservices toolkit for Node.js Seneca has the following three core features: • Pattern matching: Instead of fragile service discovery, you just let the world know what sort of messages you care about. • Transport independence: You can send messages between services in many ways, all hidden from your business logic. • Componentization: Functionality is expressed as a set of plugins which can be composed together as Microservices.
  46. Contact Me @anilallewar

Hinweis der Redaktion

  1. Microservices Loosely coupled service oriented architecture with bounded context - Adrian Cockcroft Developing single application as a suite of independent small services Each service is running in it’s own process and communicating over lightweight protocols like HTTP (synchronous) or over a lightweight message bus like Akka (reactive / asynchronous)
  2. Services build around bounded business context - Bounded Context is a central pattern in Domain-Driven Design Dividing the business model into different bounded context – the bounded context can have unified model like order and order items Explicit about relationship between the context Creating whole domain model is not feasible or costs too much resources
  3. Loosely coupled service oriented architecture with bounded context – Adrian Cockcroft
  4. In the new world, it is not the big fish which eats the small fish, it’s the fast fish which eats the slow fish. —Klaus Schwab, Chairman World Economic Forum
  5. - Abbot & Fisher X Axis – Horizontal scaling Handles 1/N of the load Load balancers needs to do round-robin or resource based allocation of requests If caching, then potentially all data can be cached at each application copy Can’t handle increased application complexity and cost of development Y Axis – Functional decomposition Microservices architecture is one implementation of this scaling methodology Z axis – Partitioning / Sharding Each server runs identical copy of the application But each server is responsible for serving requests for a particular subset of data, say employees between ids 1-1000, 1001-2000 and so on Load balancer needs to be smart – route traffic based on partitioning rules Solves some of the problems of X-axis scaling – notably cache and fault isolation Still Can’t handle increased application complexity and cost of development
  6. Microservices will trigger organization change Cross functional teams that owns the whole functionality – Dev, QA, Product Owner, DBA -> Conway’s law Freedom and responsibility You build it, you run it! Learning Organization Continuously transform itself to stay ahead of competitors Microservices are not about agility, being tech savvy or cloud transformation – it’s about innovation & building business model Smaller agile team of developers – Innovative, nimble & embracing change Lean startup – MVP, feedback -> continue/pivot/stop Versioning of Contracts Enforce version contracts so that different versions of Microservices can communicate with one another Deploy only versions that play well with each other Forward compatibility & Backward compatibity Benefits Release cycle - 4-6 weeks Fully independent team Parallel development Cleaner API design “Fear of change” to “Eagerness to peel off the monolith” Challenges What to peel off Distributed systems are complex Versioning of contracts Operations overhead Testing
  7. Monolith first! Don’t even consider Microservices unless your system is really complex System complexity and business component boundaries evolve Monolith provides agility, innovation and speed when starting with MVP Microservices come with a premium of managing suite of services Martin Fowler Almost all the successful microservice stories have started with a monolith that got too big and was broken up Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. Recommend Microservices first approach for Monolith rewrite When you know the domain really really well! Containers & Orchestration Package services as containers - run on any platform Container Orchestration – Kubernetes, Swarm, Rancher Monitoring Failover and auto-scaling CI/CD Workflows – code defined, testable and repeatable Benefits Common infrastructure Products as monolith –respond to MVP feedback and pivot/continue Scaling independently Teams talk to each other Opened new possibilities – from on-prem Enterprise to SaaS on cloud Challenges Tools and design of distributed systems Monitoring – Way harder than monolith Cloud native deployment Domain driven design – services with well defined seams