Microservices Technology Stack

Overview of all technologies that you can use to support Microservice applications. Covers integration, operations and testing.

1. Microservices Technology Stack Eberhard Wolff Fellow, innoQ @ewolff
3. http://microservices-buch.de/ http://microservices-book.com/
4. http://microservices-book.com/primer.html FREE!!!!
5. Microservices = Independent Deployment Units
6. Why can’t I just deploy Microservices on an Java EE server?
7. Microservices are just small REST services, right?
8. Integration
9. Components Collaborate Micro Service Micro Service Link Data Replication REST Messaging
10. UI Integration
11. Browser Order History Recommendation Order Microservice Recommendation Microservice
12. Server-side integration Browser UI 1 UI 2 Frontend Server Backend 1 Backend 2
13. Server-side Integration: Technologies > ESI (Edge Side Include) > E.g. Varnish cache > SSI (Server Side Include) > E.g. Apache httpd, nginx > Portal Server + Portlets
14. ESI (Edge Side Includes) ... <div> ... a lot of static content and images ... </div> ... ... <header> ... Logged in as: Ada Lovelace ... </header> <div> some dynamic content </div>
15. ESI (Edge Side Includes) ... <div> ... a lot of static content and images ... </div> ... ... <esi:include src="http://example.com/header" /> <esi:include src="http://example.com/dynamic" /> http://www.w3.org/TR/esi-lang
16. Portal Server > Broad support and used in many projects > Compose web application of Portlets > Portlets might be deployed independently Portal Server Portlet 1 Portlet 2 Browser UI 1 UI 2
17. Portal Server: Challenges > Do not really integrate diverse backends > Web Services for Remote Portlets (WSRP) still require Portlets > Portlets allow customization by user… > ...which make them very different from normal web applications
18. Portal Server > No support for non-Java technologies > Programming model very different from normal web applications > Why would you use Portal Servers?
19. Client-side integration > Client requirements (e.g. CORS, JS) > Upcoming: HMTL Imports Browser UI 1 UI 2 Backend 1 Backend 2
20. Client-side Integration: Code $("a.embeddable").each(function(i, link) { $("<div />").load(link.href, function(data, status, xhr) { $(link).replaceWith(this.children); }); }); > Replace <a href= " " class= "embeddable"> with content of document in a <div> (jQuery)
21. Logic Integration
22. Messaging Microservice Microservice ! ! !
23. Messaging > Natural fit for asynchronous communications > E.g. event-driven > Decoupling: Sender and Receiver only know topic / queue > Re-submission for resilience > Not natural for synchonous communication
24. REST ? # Microservice Microservice
25. REST > Natural fit for synchronous communications > Evolvability with HATEOS > Content negiotation > Not natural for asynchonous communication
26. https://jaxenter.de/ microservices-rest-vs- messaging-29875
27. Service Discovery > Services need to find each other > Enables load balancing > For REST only > E.g. DNS
28. Netflix Eureka > Cache on the client > Quick > Proven > Support for non-Java systems with sidecar only > No DNS
29. Hashicorp Consul > DNS interface > Supports storing configuration > Consul templates to create configuration files > Product
30. Resilience > Service not available? > Cicuit breaker > Fail fast > Time out > Hystrix > DO NOT IMPLEMENT RESILIENCE YOURSELF!
31. Proxy Load Balancing > Centralized Load Balancing > Can become bottle neck > Single point of failure Load Balancer Server Client
32. Client Ribbon: Client Side Load Balancing > Decentralized Load Balancing > No bottle neck > Resilient > Can consider response time > Data might be inconsistent Load Balancer Server
33. Client Alternative: External Load Balancer > Nginx, Apache httpd… > Probably for each used Microservices > Must each be configured Load Balancer Server
34. REST Service Discovery Resilience Load Balancing Messaging
35. Security > Single Sign on for all Microservices > Each Microservice decides about access policy
36. Client Security Server User / password Token with role Micro- service Request with Token Access / no access
37. Security > JSON Web Token (JWT) > Define standard for tokens > Includes additional data > Can be stored in a cookie
38. Testing
39. Search User Order Process Microservice Continuous Delivery Pipeline Integration Tests … Microservice Continuous Delivery Pipeline Microservice Continuous Delivery Pipeline Production
40. Microservices = Independent Deployment Units
41. No independent testing = no independent deployment
42. Integration Test = Bottleneck
43. Microservice Microservice Request Reply
44. Microservice Stub Request Reply
45. Stubs > Does the calling Microservice work as expected? > Use stubs to replace called Microservice
46. Microservice Microservice Request Reply
47. Consumer- Driven Contract Test Microservice Request Reply
48. Could just use some stub / test tool.
49. Consumer-driven Contract Test > Does the called Microservice work as expected? > Use consumer-driven contract test to replace calling Microservice > Easy to test changes to interfaces
50. Record Microservice Microservice Request Reply
51. Record Consumer- driven contract test Microservice Replay request Validate reply
52. Record Microservice Stub Request Replay reply
53. > Pact https://github.com/realestate-com-au/pact > Pacto https://github.com/thoughtworks/pacto > Wiremock http://wiremock.org/
54. Operations
55. Hold my orange juice while I deploy a Microservice!
56. Deployment Not Easy > Lots of microservices > Lots of stages > Deployment automation mandatory
57. Order Billing Customer Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release
58. Deployment Automation > Deployment automation mandatory > Significant investment > …but worth it!!
59. Docker Images > Easy to build > Dockerfile = shell script > Very efficient > …even for small changes > Unfamiliar to Ops > Replace VMware with Kubernetes?
60. CD Tools > Puppet, Chef etc > Idempotent installation > E.g. easy update > Complex > Idempotent / updates not needed for Docker
61. Linux Packages > Simple format > Centralized installation easy > Unfamiliar to devs
62. Hold my orange juice while I grep the logs for all Microservices!
63. Far too many files on far too many logs!
64. Centralized Logging > Collect all logs on one server > No need for local logs > Read-only file system?
65. ELK Stack > Logstash: JRuby > Inputs, Parser, Outputs > Elasticsearch: Storage, Java > Kibana: Analysis, JavaScript Logfile Logstash Elastic- search Kibana Parse Store Analyze
68. Graylog > Open Source > Elasticsearch for storage > MongoDB for Meta data > GELF format for log messages
69. More Alternatives > Splunk: commercial > +Cloud > Cloud : Loggly > Sumo Logic > Papertrail
70. Hold my orange juice while I do top on my server!
71. Far too many servers!
72. Centralized Metrics > Collect all metrics on one server > Not just operating system, network > …but in particular application
73. Whisper Timeseries DB Graphite Web Carbon Data Library, writes / reads files Analysis Graphite
75. Alternatives > Nagios: Open Source monitoring > Icinga: Originally Nagios fork > Many commercial tools (HP, IBM, CA, BMC) > Riemann: functional programming for event streams > New Relic: Example for cloud
76. Alternatives > TICK stack > InfluxDB: Time-Series Database, also useful for Graphite > Telegraf: Collects data > Chronograf: Visulization > Kapacitor: Alerts, anomaly detection
77. Alternatives > Packetbeat: uses Elasticsearch for storage > …and Kibana for analysis
78. Hold my orange juice while I configure my server!
79. Configuration Files > Easy to create > Servers self- contained > No centralized update possible > Needed with canary releasing?
80. Configuration Server > Easy to push out changes to all servers > Can be the same server as for services discovery > Additional technology
81. > Managing secrets > Lease secrets > Revoke secrets > Key rolling > Audit logs
82. Microservice Frameworks > Lots and lots of them > Each Microservice might use a different > Not too much influence on the overall system
83. > Deployment Automation > Centralized Logging & Monitoring > Configuration > Messaging or > REST + Service Discovery + Reslience + Load Balancing > Stubs & Consumer-driven Contract tests Operations Communication Testing
84. So much stuff!
85. Technologies solve problems.
86. Use a technology only if it solves a problem.
87. > Deployment automation is great! > Maybe Microservices finally enforce deployment automatiom? > Operation & testing requires additional effort > Communication: No DNS? No Messaging? Operations Communication Testing
88. Microservices are a trade-off!
89. Microservices create additional technical complexity!