Microservices use case

1. A novel approach to
Microservices with
Varnish

3. Microservices (1/2)
• Application pattern used for the last couple of years
• Reduces complexity by having small (micro) services that
are relatively simple
• Distributed application

4. Microservices (2/2)
• A loose 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 is Foo?”

6. Potential pitfalls
• Performance on 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 of 2007:
• 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
• Many small 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
• Primary data handled by CMS
• Derived data clearly marked as such
• HTTP headers used to tag cache metadata

13. X-KeyVCL
vcl 4.0;
import xkey;
backend default { .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 about 10 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