1 / 46

Introduction to Microservices

The introduction covers the following<br>1. What are Microservices and why should be use this paradigm?<br>2. 12 factor apps and how Microservices make it easier to create them<br>3. Characteristics of Microservices

anilallewar
Download Presentation

Introduction to Microservices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • Why Microservices? • Typical Use Cases • Characteristics

  4. Software Architecture Evolution http://www.kanbansolutions.com/blog/microservices-architecture-friend-or-foe/

  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 • Why Microservices? • Typical Use Cases • 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 • Codebase • Single codebase for one app - tracked in revision control • If more than 1 app then each has it’s own codebase - distributed system • Dependencies • Declared explicitly through dependency manifest - gradle, maven, npm • Dependency isolation - no implicit dependencies, gradledependencyManagement for exact version of dependency • Simplify developer setup • Project dependencies - build system (gradle)  • Runtime dependencies - containers (docker, linuxlxc)

  12. 12-Factors • Processes • Stateless - share nothing • Persistent data needs to be stored in stateful backing service like database • Port binding • Export HTTP as a service by binding to a port • In built web server like Tomcat for Spring boot • 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 • Config • Strict separation of config from code • Hosted externally or setup as environment variables • 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 • 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 • Disposability • Started or stopped at moments notice • Pets v/s Cattle • Dev/prod parity • DevOps, quick deploys • Use Docker and external configuration • Logs • Treat logs as event streams routed to common destination • ELK stack, Fluent etc

  15. 12-Factors • 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 • Why Microservices? • Typical Use Cases • 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 • Why Microservices? • Typical Use Cases • Characteristics

  22. Who is doing microservices?

  23. Monolith Monolith Unintended side effects Release – 4 months Go-live firefighting Quicker competitors Fear of release 3-4 months gestation Horizontal scaling Recruitment

  24. Chipping The Monolith

  25. Large Distributed System Registry Dashboard Health Dashboard Github Security Metering Web Apps Registry/Discovery (Eureka) Circuit Breaker (Hystrix) Config Server API Gateway (Zuul) Web Portal Web Service 3 Web Service 1 Mobile Apps Ribbon Ribbon Ribbon Auth Server Web Service 2 Web Service 4 3rd Party Integration OAuth 2.0 Load Bal Auth-DB DB1 DB2 Routing

  26. Agenda • What are Microservices? • SaaS and 12-Factor apps • Why Microservices? • Typical Use Cases • 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 Failures means only that microservice is redeployed. Circuit Breakers can help stop propagate the effect May or May not have published interfaces between components Any Failure means redeploy entire application Restful APIs mostly are the published interfaces.

  29. Organized around Business Capabilities

  30. Products not Projects Project Model Amazon Model- You Build it, You run it ! Product Model

  31. Decentralized Governance R ruby java node mysql redis hbase

  32. Decentralized Data Management

  33. Infrastructure Automation Microservice Monolith Continuous Delivery A Must

  34. Design for failure Microservices needs following to function Circuit Breaker – Fallback Response Detect Failure Early 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 CloudwithNetflix 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. LightbendLagom • 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

More Related