Downloaded 393 times
Uploaded byEberhard Wolff
Microservices Technology Stack
The document discusses the microservices technology stack, highlighting various integration techniques, such as server-side and client-side integration, service discovery, and resilience strategies. It emphasizes the importance of deployment automation, centralized logging, and configuration management, alongside the testing processes like consumer-driven contract tests. The text also notes that while microservices offer flexibility and independent deployment, they introduce technical complexity and operational challenges.
More Related Content
Similar to Microservices Technology Stack
Microservices Technology Stack
- 1.
- 3.
- 4.
- 5.
- 6. Why can’t Ijust deploy Microservices on an Java EE server?
- 7. Microservices are just smallREST services, right?
- 8.
- 9.
- 10.
- 11.
- 12.
- 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 SideIncludes) ... <div> ... a lot of static content and images ... </div> ... ... <header> ... Logged in as: Ada Lovelace ... </header> <div> some dynamic content </div>
- 15. ESI (Edge SideIncludes) ... <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 > Broadsupport 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 > Donot 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 > Nosupport for non-Java technologies > Programming model very different from normal web applications > Why would you use Portal Servers?
- 19. Client-side integration > Clientrequirements (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.
- 22.
- 23. Messaging > Natural fitfor asynchronous communications > E.g. event-driven > Decoupling: Sender and Receiver only know topic / queue > Re-submission for resilience > Not natural for synchonous communication
- 24.
- 25. REST > Natural fitfor synchronous communications > Evolvability with HATEOS > Content negiotation > Not natural for asynchonous communication
- 26.
- 27. Service Discovery > Servicesneed to find each other > Enables load balancing > For REST only > E.g. DNS
- 28. Netflix Eureka > Cacheon the client > Quick > Proven > Support for non-Java systems with sidecar only > No DNS
- 29. Hashicorp Consul > DNSinterface > Supports storing configuration > Consul templates to create configuration files > Product
- 30. Resilience > Service notavailable? > 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 LoadBalancing > 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.
- 35. Security > Single Signon for all Microservices > Each Microservice decides about access policy
- 36. Client Security Server User / password Tokenwith role Micro- service Request with Token Access / no access
- 37. Security > JSON WebToken (JWT) > Define standard for tokens > Includes additional data > Can be stored in a cookie
- 38.
- 39.
- 40.
- 41. No independent testing = noindependent deployment
- 42.
- 43.
- 44.
- 45. Stubs > Does thecalling Microservice work as expected? > Use stubs to replace called Microservice
- 46.
- 47.
- 48. Could just usesome stub / test tool.
- 49. Consumer-driven Contract Test > Doesthe called Microservice work as expected? > Use consumer-driven contract test to replace calling Microservice > Easy to test changes to interfaces
- 50.
- 51.
- 52.
- 53. > Pact https://github.com/realestate-com-au/pact > Pacto https://github.com/thoughtworks/pacto >Wiremock http://wiremock.org/
- 54.
- 55. Hold my orange juicewhile I deploy a Microservice!
- 56. Deployment Not Easy >Lots of microservices > Lots of stages > Deployment automation mandatory
- 57.
- 58. Deployment Automation > Deploymentautomation mandatory > Significant investment > …but worth it!!
- 59. Docker Images > Easyto 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 > Simpleformat > Centralized installation easy > Unfamiliar to devs
- 62. Hold my orange juicewhile I grep the logs for all Microservices!
- 63. Far too manyfiles on far too many logs!
- 64. Centralized Logging > Collectall 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 juicewhile I do top on my server!
- 71. Far too manyservers!
- 72. Centralized Metrics > Collectall 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: OpenSource 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: usesElasticsearch for storage > …and Kibana for analysis
- 78. Hold my orange juicewhile I configure my server!
- 79. Configuration Files > Easyto create > Servers self- contained > No centralized update possible > Needed with canary releasing?
- 80. Configuration Server > Easyto 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 > Lotsand 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.
- 85.
- 86. Use a technologyonly if it solves a problem.
- 87. > Deployment automationis great! > Maybe Microservices finally enforce deployment automatiom? > Operation & testing requires additional effort > Communication: No DNS? No Messaging? Operations Communication Testing
- 88.
- 89.