With vector tiles one doesn't have to containerize anything - just shard them onto a bunch of servers and server them over https. Put an accelerator/cache in front and proxy to the desired region backend.

With image tiles it's a hurdle. You have to build 18 zoom levels of tiles. The most detailed layers have an astronomic number if tiles. You also need a huge amount if storage.

http://tools.geofabrik.de/calc/#type=geofabrik_standard&bbox...

Did I mention the data being huge? What's the point of having 15Tb container, which takes forever to deploy? You can certainly containerize the services, but there's no benefit containerizing the data, since you have to replace it all at once rather than synchronizing the differences.

How intensive is it to rasterise on demand?

Depends on the degree of complexity of the tiles. We tried it (using tilecache or tilestache and mapproxy) and it becomes unresponsive when you rasterize several tiles (9). It can take several secons for a busy tile. If the user gets impacient like I do, zooms in and out and pans the map, it freezes to a halt. It's doable over clear water and maybe on the highway, but not in busy cities, at least not with hundreds of users requesting on demand tiles and without an insane amount of rendering resources. My impression is that it works if you're the only user and a really patient one at that.

Why not use vector tiles? I can generate a vector tile package of the whole planet in Esri .vtpk format and it takes up around 30Gb. A map service can be published from it easily. Takes me about 2 days for initial translation and about 1 week ti generate the vtpk. Neither of these have been optimised for speed. I have an old Galaxy S3 upstairs running an app that displays this vtpk - so I can have the entire world down to house level on my phone.