Microservices

Microservices

• 1.
  A novel approachto Microservices with Varnish
• 3.
  Microservices (1/2) • Applicationpattern used for the last couple of years • Reduces complexity by having small (micro) services that are relatively simple • Distributed application
• 4.
  Microservices (2/2) • Aloose collection of RESTful APIs • One or more applications • Potentially on different platforms • Typically each service has its own infrastructure • Services are typically synchronous
• 5.
  quux zoo baz bar foo service directory “Where isFoo?”
• 6.
  Potential pitfalls • Performanceon large scale microservices is tricky - caching is always used • Debugging distributed systems is hard • Specifically distributed state can make it a lot harder
• 8.
  • As of2007: • Had a monolithic Java application CMS • Tons of state and caching inside the application • Deployment was a pain • Debugging was a pain
• 9.
  New architecture • Manysmall services • All services should be completely stateless • Potentially leveraging different languages and runtimes for each application if needed • UseVarnish for caching of all data • Support dynamic relationships between objects
• 10.
  quux zoo baz bar foo varnish
• 11.
  quux ing baz titl art varnish
• 12.
  Cache invalidation • Primarydata handled by CMS • Derived data clearly marked as such • HTTP headers used to tag cache metadata
• 13.
  X-KeyVCL vcl 4.0; import xkey; backenddefault { .host = "192.0.2.11"; .port = "8080"; } acl purgers { "203.0.113.0"/24; } sub vcl_recv { if (req.method == "PURGE") { if (client.ip !~ purgers) { return (synth(403, "Forbidden")); } set req.http.n-gone = xkey.purge(req.http.key); # or: set req.http.n-gone = xkey.softpurge(req.http.key) return (synth(200, "Invalidated "+req.http.n-gone+" objects")); } }
• 14.
  GET /api/v1/artdb/get_article/50052 HTTP/1.1 Host:foo.com 
200 OK Content-type: text/json xkey: 50052
• 15.
  GET /api/v1/ingress/get_ingress/50052 HTTP/1.1 Host:foo.com 

200 OK Content-type: text/json xkey: 50055 xkey: 50053 (derived from 50055)
• 16.
  Purging with x-key PURGE/the/URL/doesnt/really/matter HTTP/1.1 Host: foo.com Key: 50052 
200 OK (..) n-gone: 3
• 17.
  Missing anything?
• 18.
  Results • After about10 years in production the architecture is still very much relevant • Statelessness has saved thousands of hours of debugging • After replacing bans with x-key performance is still very good • Scaling stateless services up and down is effortless
• 19.
  thanks