Microservices with Stijn Van den Enden & Andreas Evers - BeJUG

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.

Transcript

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 • Release and deployment • Scaling • Development
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 integrations backends { 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. Accounting Inventory Billing Ordering Functional decomposition of the business domain
22. Functional decomposition of the business domain Accounting Inventory Billing Ordering customer Invoice balance order item item stock order order item incoming cash outgoing cash stock
23. Benefits of functional decomposition
24. Accounting Inventory Billing Ordering 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 Service Inventory Service Billing Service Ordering Service customer Invoice balance order item item stock order order item incoming cash outgoing cash stock Accounting Inventory Billing Ordering 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?
29. Implementing a Microservice
30. java -jar payara-micro.jar --deploy test.war
31. Service Discovery
32. Node Client Node Node Node Node ? Loadbalancer Single Point of Failure Manual configuration management
33. Client Node Node Node Node ? Registry register health lookup Node unregister
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 registration Sidecar 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 based DNS ⊖ • 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 …
46. Architect for Failure
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-459 MicroService Build
56. preference-service- artefact-765 preference-service- artefact-311 preference-service- artefact-459 preference-service- artefact-765 deployment context Handover 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 Handover Machine 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
61. Container Image preference-service- artefact-765
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 traffic test 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
72. CollectD & StatsD
81. Roll Your Own https://github.com/DennisJaamann/micro-services-gui/tree/dev
82. What about DynaTrace?
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