Microservices - Hitchhiker's guide to cloud native applications
•
4 likes•1,082 views
Microservices are a true hype these days. Netflix, Amazon, eBay, … are all using microservices, but why? The idea is simple; split your application into multiple services which can evolve autonomously through time. The name suggests to keep these services small. Conceptually this seems not all that different from a classical Service Oriented Architecture (SOA). Nonetheless, microservices do offer a new perspective. A monolithic application is divided into a couple small services which can be independently developed, deployed and scaled. Flexibility is increased, but using this model also has some pitfalls.This session sheds a light on the microservices landscape; the key drivers for using the pattern, tooling to support development and maintenance, and the pros and cons that go with it. We’ll also introduce some key design principles that can be used in creating and modelling these modular enterprise applications.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Microservices - Hitchhiker's guide to cloud native applications
Similar to Microservices - Hitchhiker's guide to cloud native applications (20)
Recently uploaded
Recently uploaded (20)
Microservices - Hitchhiker's guide to cloud native applications
- 1. Microservices Hitchhiker’s guide to cloud native applications Andreas Evers @andreasevers Stijn Van den Enden @stieno
- 2. Martin Fowler “The microservice 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. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.” James Lewis
- 3. Characteristics of a Microservice style
- 4. • Small and focussed on 1 capability • easier to understand • IDE and deployment faster for 1 service
- 5. • Provide firm module boundaries with explicit interface • Harder to violate boundary in development
- 6. • Independent • Development • Release and deployment • Scaling
- 7. • Loosely Coupled • through lightweight communication
- 8. • Fault Isolation vs. bring all down.
- 9. • Decentralised choreography • vs. central orchestration • vs. central point of failure
- 10. • Allows try-out of new technologies. • Re-write can be limited to 1 service • Impact Analysis stops at boundary
- 11. • Decentralised data • polyglot persistence
- 12. Strong Module Boundaries Distribution Eventual Consistency Independent Deployment Operational Complexity Technology Diversity Security Segmentation Separate Scale-out Parallel Development
- 13. Is this any different from SOA?
- 14. SERVICE ORIENTED ARCHITECTURE? Yes, it’s SOA … but different implementation approach: Classic SOA integrates different applications as a set of services Microservices architect a single application as a set of services
- 15. Classic SOA integrates different applications as a set of services Enterprise Service Bus WS* WS* WS* WS* WS* WS* WS* WS* WS* WS* Workflow Engine Intelligence Orchestration
- 16. Microservices architect a single application as a set of services business platform accounting service contract service ordering service logistics service prospects service capability X service capability Y service external integrationsbackends { API } { API }{ API } { API } { API } { API } { API } { API } { API } { API } { API }
- 17. Classic SOA integrates different applications as a set of services Microservices architect a single application as a set of services Typical implementation solution differs! Heavy-weight ESB WS*/SOAP Orchestration License-driven Target problem: Integrate (Legacy) Software Intelligent Communication Layer Light-weight HTTP/REST/JSON Choreography Target problem: Architect new Business Platform Dumb Communication Layer Intelligent Services
- 18. Any practical advice on how I can start building the microservice stuff?
- 19. side note: Domain Driven Design Tackling complexity by abstracting the business domain concepts and logic into a domain model and using this as a base for software development “In order to create good software, you have to know what that software is all about. You cannot create a banking software system unless you have a good understanding of what banking is all about, one must understand the domain of banking.” Eric Evans
- 20. Domain driven design deals with large complex models by dividing them into different functionally bounded subdomains and the explicitly describing the interrelations between these subdomains. Bounded contexts
- 21. AccountingInventory BillingOrdering Functional decomposition of the business domain
- 22. Functional decomposition of the business domain AccountingInventory BillingOrdering customer Invoice balance order item item stock order order item incoming cash outgoing cash stock
- 23. Benefits of functional decomposition
- 24. AccountingInventory BillingOrdering customer Invoice balance order item item stock order order item incoming cash outgoing cash stock Benefits of functional decomposition
- 25. Applying services to bounded contexts Accounting ServiceInventory Service Billing ServiceOrdering Service customer Invoice balance order item item stock order order item incoming cash outgoing cash stock AccountingInventory BillingOrdering customer Invoice balance order item item stock order order item incoming cash outgoing cash stock
- 26. take notice.
- 27. Sam Newman “If you’re coming from a monolithic system point of view, you’ll have to get much better at handling deployment, testing, and monitoring to unlock the benefits we’ve covered so far. You’ll also need to think differently about how you scale your systems and ensure that they are resilient. Don’t also be surprised if things like distributed transactions or CAP theorem start giving you headaches, either!”
- 28. What do we need to get started?
- 30. java -jar payara-micro.jar --deploy test.war
- 32. NodeClient Node Node Node Node ? Loadbalancer Single Point of Failure Manual configuration management
- 34. K/V K/V K/V K/V K/V /etc distributed raft - leader election //Adding a value $ curl http://127.0.0.1:2379/v2/keys/message -XPUT -d value="Hello world” //Quering $ curl http://127.0.0.1:2379/v2/keys/message { "action": "get", "node": { "createdIndex": 2, "key": "/message", "modifiedIndex": 2, "value": "Hello world" } } //Delete $ curl http://127.0.0.1:2379/v2/keys/message -XDELETE Operations
- 35. K/V K/V K/V K/V K/V /etc distributed raft - leader election SkyDNS //registration $ curl -XPUT http://127.0.0.1:4001/v2/keys/skydns/local/ production/preference/1 -d value=‘{“host”:”service5.example.com”,"port": 8080, “priority”:20}' Operations % dig @localhost SRV preference.production.local ;; ANSWER SECTION: preference.production.local. 3600 IN SRV 10 20 8080 service5.example.com. preference.production.local. 3600 IN SRV 10 20 8081 service4.example.com. ;; ADDITIONAL SECTION: service4.example.com. 3600 IN A 10.0.1.125 service5.example.com. 3600 IN A 10.0.2.126 Operations
- 36. A HashiCorp Project. https://www.consul.io/ K/V K/V K/V K/V K/V Distributed Key/Value Store http dns Client raft - leader election gossip - node detection Node { "service": { "name": "preference", "tags": ["spring"], "port": 8000, "checks": [ { "script": "/usr/local/bin/check_preference.py", "interval": "10s" } ] } } Service Registration $ dig @127.0.0.1 -p 8600 preference.service.consul SRV ... ;; QUESTION SECTION: ;preference.service.consul. IN SRV ;; ANSWER SECTION: preference.service.consul. 0 IN SRV 1 1 8000 agent- one.node.dc1.consul. ;; ADDITIONAL SECTION: agent-one.node.dc1.consul. 0 IN A 172.20.20.11 Service Query (DNS) $ curl http://localhost:8500/v1/catalog/service/preference [{"Node":"agent- one","Address":"172.20.20.11","ServiceID":"preference", "ServiceName":"preference","ServiceTags": ["spring"],"ServicePort":8000}] Service Query (http)
- 37. Static Dynamic Loadbalancer Loadbalancer MicroService MicroService MicroService MicroService MicroService Web Front End Web Front End Web Front End Web Front End Web Front End MicroService MicroService MicroService MicroService MicroService A B Midtier Service Registry MicroService register renew get registry eureka ribbon https://github.com/Netflix/eureka https://github.com/Netflix/ribbon
- 38. Apache ZooKeeper™ synapse - HAProxy based service discovery/routing nerve - sidecar for service registration we can’t cover them all …
- 39. Registration Embedded In-app registrationSidecar based approach ⊖ • more difficult to take service lifecycle into account ⊕ • no impact on the application • language agnostic • easier to control service registration ⊖ • requires language specific integration • will not work with legacy services ⊕ • deep integration with insight in the service lifecycle Discovery API basedDNS ⊖ • TTL difficulties • complex routing requires tighter integration ⊕ • legacy integration ⊖ • API integration has impact on the application ⊕ • service metadata can be leveraged for routing
- 40. API Gateway & Routing
- 42. Hides partitioning of microservices Single point of entry Client-tailored API Request aggregation for performance Simplifies clients by aggregation of APIs Increased complexity Increased response time by network hop
- 43. Surgical Routing Stress Testing Canary Testing Authentication Authorization Choosing origin servers Logging debug info Adding headers Gathering statistics and metrics Filter error handling Generate static responses Load Shedding Dynamic behaviour change …
- 52. Deployment
- 53. from CI to CD
- 54. Continuous Integration Infrastructure build Source Control System Monolithic Build single version tree /preference-service /ordering-service /inventory-service … Repository preference-service- artefact-311 preference-service- artefact-311 preference-service- artefact-311
- 55. Continuous Integration Infrastructure Source Control System own version tree /preference-service Repository /ordering-service Repository /inventory-service Repository MicroService Build preference-service- artefact-765 preference-service- artefact-311 MicroService Build preference-service- artefact-459MicroService Build
- 56. preference-service- artefact-765 preference-service- artefact-311 preference-service- artefact-459 preference-service- artefact-765 deployment contextHandover environment specific technology specific application specific
- 57. preference-service- artefact-765 preference-service- artefact-311 preference-service- artefact-459 preference-service- artefact-765 deployment context Handover Automated installation scripts ⊖ execution time lots of scripts with small delta’s ⊕ transaction cost goes down repeatable deployments Machine image with backed in microservice as build artefact
- 58. preference-service- artefact-765 preference-service- artefact-311 preference-service- artefact-459 preference-service- artefact-765 HandoverMachine image with backed in microservice as build artefact VM Image ⊖ overhead of machine VM based deployment ⊕ speed of deployment Containers with backed in microservice as build artefact
- 59. Compute, Storage, Network Host OS Hypervisor VM1 MicroService Guest OS JVM VM’s abstract underlying hardware, but limits resource utilisation VM2 MicroService Guest OS JVM • Isolation • namespace • pid mnt net uts ipc user • resource usage • (CPU, memory, disk I/O, etc.) • Limited impact on Performance - • http://ibm.co/V55Otq • Daemon and CLI Compute, Storage, Network Host OS container1 container2 container3 container4 JVM JVM JVM MicroService MicroService MicroService JVM MicroService Containers have own isolated resources
- 60. /preference-service Repository DockerFile Continuous Integration Infrastructure Container Image Repository Compute, Storage, Network Host OS daemon container1 JVM MicroService pull push build provision container1 JVM MicroService Source Control System
- 63. Patterns
- 64. Container Image preference-service- artefact-765 Blue Green Content Based Router Blue/Green deployments Container Image preference-service- artefact-765 Container Image preference-service- artefact-123 production traffictest traffic
- 65. Container Image preference-service- artefact-765 Stage 1 Stage 2 Stage 3 Content Based Router Canary staged deployment
- 71. Zipkin + Sleuth heavily borrowing from Dapper & HTrace
- 84. - Correct Functional decomposition is crucial - reflect it in a organisational structure (💡Conway’s law) - Getting it right is not guaranteed to be easy - your aiming for a very high standard in software delivery - balance the needs (advantages) with the costs (tradeoffs) - take a simple step at a time Conclusion Are they here to stay? who can tell? but the monolith is dead