Containers & Kubernetes: Eric Brewer, Google VP Infra
It’s not often that we get to host celebrities at Q42. But Eric Brewer definitely falls in that category, and he gave a talk at our Amsterdam office Wednesday evening.
Wait, where are my manners. Let me first introduce the main character of this story, in case you haven’t heard of him before. Eric Brewer is currently Vice President of Infrastructure at Google Cloud. That makes him the guy responsible for Google Compute Engine (GCE), Google App Engine (GAE) and lately focusing on Google Container Engine (GKE) and the open-source technology on which it’s based, Kubernetes. Oh, and incidentally, back in the 1990’s Eric wrote the CAP theorem, which lies at the basis of eventual consistency, enabling distributed computer systems. Apparently the CAP theorem is also known as Brewer’s theorem.
Right. That Eric Brewer. His talk and the discussion afterwards focused on containerization. At Q42 we see a bright future for this technology. It promises to lower the amount of devops needed to maintain a website infrastructure, while keeping a lot of the flexibility of running on your own VMs. And less devops means more time to build awesome stuff!
I think this is best comparison of GAE and GKE:
GAEGKEAutoscaling, versioning, A/B testing, monitoring, alerts, cronjobs, task queues etc.The architecture is ready to handle these functionalities. They’ll be in GKE, but maybe not yet in 1.0 releaseGoogle implements OS updates & security patchesSimilar to GAE, Google will implement OS updates & security patches. This will be in place by 1.0 release.Limited to python, java, go, php. Only with certain libraries. An no websockets / long-lived connections.Any runtime you want! Use an existing docker container or create your own.Only run websitesRun anything you want: web application, websockets, mongodb, elasticsearch, redis, etc.Deploy script:
Deploy script:
Conclusion: GKE is a lot more flexible than GAE, with a minimum of extra scripting. Actually, the scripting is better in my opinion, because you define the cluster you’re deploying more explicitly, but as human readable commands.
And for a comparison of Virtual Machines (GCE) and containers (GKE), this diagram does a good job:
Because multiple containers use the same operating system and processor, they boot up an order of magnitude faster. Think ~30 ms instead of ~3 seconds.
Conclusion: If you want a runtime or libraries that are not supported by App Engine, GKE will provide the flexibility you need, without the hassle of setting up and managing your own VMs. And with the tooling of App Engine that we know and love :-).