Download as PDF, PPTX
More Related Content
Similar to Microservices on a budget meetup
Microservices on a budget meetup
- 1.
- 2. HELLO! We are: KevinKalmbach* - Sovrn Bill Bauernschmidt - Pivotal Mike Sarver - Ibotta Matt Reynolds - Ibotta Dirk Butters (Manager) - Sovrn 2
- 3. Agenda ▫ Why Change? ▫Why Microservices? ▫ The Platform we built and alternatives ▫ Designing a Microservice ▫ Operational Concerns ▫ Culture 3
- 4. 4 WHO ARE YOU? Ireally wanna know... - The Who https://commons.wikimedia.org/wiki/The_Who#/media/File:Who_-_1975.jpg
- 5.
- 6. Challenges we allface ▫ To stay competitive, we need to deliver quality features and innovations with higher efficiency and at a faster pace ▫ Faster time to market without jeopardizing system stability ▫ The sophistication and frequency of security attacks are rapidly increasing ▫ Systems and codebase complexity is increasing ▫ Improving developer productivity 6
- 7. Where we arenow… Monoliths!
- 8. Monolith Pros ▫ Singlecodebase ▫ Easier to trace issues ▫ In process calls ▫ Simpler infrastructure ▫ Easier to manage with central ops team 8
- 9. Monolith Cons ▫ Difficultto reason about (large scale) ▫ Co-mingling of functionality (difficult to determine effect of change) ▫ Change needs to be coordinated ▫ More comprehensive testing required ▫ Slower turnaround,slower feedback ▫ Everyone owns it means no one owns it ▫ One failure could cause significant issues 9
- 10. What needs tohappen?
- 11.
- 12.
- 13. “ In short, themicroservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. 13 - Martin Fowler
- 14. Microservice Pros ▫ Boundedcontext - easier to reason about ▫ Independent - more responsive to stakeholders ▫ Faster turnaround - no “release train” ▫ More granular scalability ▫ More resilient - services share little ▫ Compose new functionality easier 14
- 15. MicroService ▫ Many verysmall components ▫ Business logic lives inside a single service domain ▫ Simple wire protocols, e.g. HTTP with XML or JSON ▫ API driven with SDKs/Clients 15 Microservices Vs Traditional SOA SOA ▫ Fewer more sophisticated components ▫ Business logic can live across multiple domains ▫ Enterprise Service BUS (ESB) like layers between services ▫ Middleware
- 16. Microservice Cons ▫ Howdo we… ▫ Find it? ▫ Secure it? (larger surface area) ▫ Monitor it? ▫ Troubleshoot it (multiple services chain)? ▫ Know what it is (service/version)? ▫ Test it? 16
- 17. Some Solutions Weused... ▫ Service Registry to find services ▫ Spring Security basic auth/OAuth JWT for access ▫ Monitoring endpoint with metrics provided OTB ▫ Transaction Tracing/Splunk for troubleshooting ▫ Info endpoint with git SHA, Tomcat version etc ▫ Contract testing for joint client/server validation 17
- 18. Microservice Principles ▫ Modelaround a business domain ▫ Culture of automation ▫ Hide implementation details ▫ Decentralize ▫ Deploy independently ▫ Isolate Failure ▫ Highly Observable ▫ Stateless 18 - Sam Newman
- 19. Platform Overview What isNephos (what we built)?
- 20.
- 21. Cloud Infrastructure The common servicesrequired to support microservices in the cloud 21 https://commons.wikimedia.org/wiki/File:Forth_Bridge_Structure.jpg
- 22. ▫ Eureka (ServiceDiscovery) ▫ Zuul (Edge Services) ▫ Centralized Configuration Server ▫ Auth Server 22 Infrastructure Servers: (all open source)
- 23. Building Blocks for Services Weprovided building block libraries developers could use in their service 23 https://commons.wikimedia.org/wiki/File:Lego_Color_Bricks.jpg
- 24. ▫ Hystrix (CircuitBreaker) ▫ Rest Template/Feign ▫ Reactive Java ▫ Spring Security ▫ Lombok ▫ Input Validation 24 Libraries Available: (all open source)
- 25. Inheritance Your service getsa lot “for free” when you inherit the Nephos parent POM and library 25 http://arcdn02.mundotkm.com/2015/12/Rich-Kids-of-Instagram_1390479709246671.jpg
- 26. ▫ Build asTomcat executable Jar & Docker image ▫ Discovery & Config clients ▫ Client Side Load Balancing (Ribbon) ▫ Spring cloud Sleuth transaction tracing ▫ Base OAuth Authentication ▫ Management Endpoints (/info,/health,/metrics...) ▫ Swagger API documentation ▫ Standardized logging ▫ Global Controller Exception Handler26 Your Inheritance: (open source & glue code)
- 27.
- 28.
- 29. ▫ Allows servicesto be called dynamically ▫ Service client automatically registers (securely) ▫ Used by Zuul for external requests ▫ Helps with Canary 29 Eureka Service Registry
- 30.
- 31. ▫ Provides AuthNand AuthZ services ▫ Provides interface to external RBAC tools ▫ Uses short lived JWT for signed claims ▫ Works with Spring Security libraries 31 Auth Server
- 32.
- 33. ▫ Service clientautomatically gets config (securely) ▫ Provides for encrypted values ▫ Centralized configuration controlled in Git ▫ Defined per environment using profile 33 Config Server
- 34.
- 35. ▫ Routes externalrequests to services ▫ Checks for valid Auth token ▫ Helps in Canary ▫ Can be dynamically loaded with custom filters 35 Zuul Edge Services
- 36.
- 37. Who you are.Everything requires authentication microservices: to platform (auth-server, eureka, config) clients: calling services - browsing not logged in from web/mobile/kiosk/… - back-end clients calling other services users: done on a client’s behalf calling services - signed in user from web/mobile/kiosk/... 37 Authentication
- 38. How: OAuth2 andJWT JWT Short lived signed claims, includes client and user information for authorization. Open, industry standard RFC 7519 method for representing claims securely Additional information: https://jwt.io 38 Authentication
- 39. What you areallowed to do Zone/Environment level security (are you even allowed in here) Service specific level authorization - Done in the service - Spring Security: URL pattern and Controller39 Authorization
- 40. ▫ Client ▫ Audience:Service level ▫ Scope: client level permissions ▫ User ▫ Authorities: Roles and permissions 40 Authorization levels
- 41.
- 42.
- 43. ▫ Run onKubernetes as proxy sidecar ▫ Provide routing based on K8s services ▫ Statsd metrics, Zipkin traces* ▫ Basic Circuit Breaker ▫ Ingress support ▫ Basic quota management ▫ Flexible routing rules for Canary etc ▫ Service identity and security via K8s service accounts43 Service Mesh - Istio Envoy/Linkerd
- 44. ▫ Query languagefor APIs built by Facebook ▫ Client and Server libraries in multiple languages ▫ Query only for fields you want ▫ Request across multiple resources ▫ Need to limit complex queries ▫ Control queries on public APIs ▫ Harder to cache ▫ More complex setup44 GraphQL
- 45.
- 46. ▫ Bounded Context ▫Resiliency ▫ Idempotency ▫ Stateless ▫ Projections ▫ Transactions ▫ Security 46 Design Considerations
- 47. ▫ 6 weeksfrom request to production ▫ Data fusion from 3 source systems with multiple failovers ▫ First use of Hystrix,RX and Couchbase ▫ 99.95% requests < 250ms ▫ Zero downtime, Zero customer issues ▫ Black Friday peak load ~2M transactions per hr 47 Case Study - Daily Deals
- 48.
- 49. ▫ Automation -script standard tasks ▫ CI/CD Pipeline ▫ Rollout - Canary/Blue-Green ▫ Tracing - Zipkin, open tracing, Spring Sleuth ▫ Centralized,standardized logging - Splunk,ELK ▫ Monitoring (health,info,metrics) Prometheus ▫ Alerts - runbooks, remember resiliency ▫ Substrate - Docker, Kubernetes, Istio? 49 Ops considerations
- 50.
- 51. ▫ Agile -affects the business side too ▫ “You build it - You own it” - Devolve power ▫ Products not Projects ▫ DevSecOps / Rugged DevOps ▫ Conway’s Law - Group business with IT ▫ QA? - Contract Tests, automated testing ▫ Governance 51 Cultural Aspects
- 52.
- 53. CREDITS Special thanks toall the people who made and released these awesome resources for free: ▫ Presentation template by SlidesCarnival ▫ Building Photographs by Unsplash ▫ Most other Images From WikiMedia Commons (images credited on page) 53