A novel approach to Microservices with

Varnish

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

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

quux

zoo

baz

bar

foo service directory

“Where is Foo?”

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

• 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

New architecture

• Many small services

• All services should be completely stateless

• Potentially leveraging different languages and runtimes for each application if needed

• Use Varnish for caching of all data

• Support dynamic relationships between objects

quux

zoo

baz

bar

foo

varnish

quux

ing

baz

titl

art

varnish

Cache invalidation

• Primary data handled by CMS

• Derived data clearly marked as such

• HTTP headers used to tag cache metadata

X-Key VCLvcl 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"));

}

}

GET /api/v1/artdb/get_article/50052 HTTP/1.1

Host: foo.com

200 OK Content-type: text/json

xkey: 50052

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)

Purging with x-key

PURGE /the/URL/doesnt/really/matter HTTP/1.1

Host: foo.com

Key: 50052

200 OK (..)

n-gone: 3

Missing anything?

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

thanks