Hacker News Reader

Comment by nickbauman | Hacker News Reader

I've found that Kubernetes is a big hammer. If your problem can be backed by a web app, you should start with AppEngine. If you need specialty library support or wider computational space per instance, you can move your AppEngine app to ManagedVMs (which uses Kubernetes under the covers). If you need special, "grid-like" services where you need exquisite control over the entire stack, only then does it make sense to use raw Kubernetes and Docker. And you will spend a lot of time getting it right.

View on HN

ManagedVMs don't use k8s under the covers afaik. However there's GKE (Google Container Engine), which goes on top of (at least 3) MVMs and that one does use k8s. While it is true that going with a PaaS(-like) solution like AppEngine or Heroku is easy in the beginning it can get pretty expensive pretty fast and it limits you in the choice of languages, frameworks, and data stores you can use. This can in some instances bring technical debt with it that will pose a hurdle when growing. Actually, using Docker combined with an orchestration layer like k8s is supposed to give the the ease-of-use of PaaS with the flexibility of IaaS (or MVMs), however, managing sth like k8s by yourself is not that easy and you will need quite a bunch of other tools on top, i.e. for monitoring and stuff, which paves the way for Container-as-a-Service solutions, like RancherOS, tutum, or Giant Swarm (disclaimer, I'm part of the latter company)

Correct, MVMs does not use Kubernetes today. We're looking at rebasing onto GKE now that they've hit 1.0, but nothing is set in stone yet.

Disclaimer: I'm a tech lead on Managed VMs/App Engine at Google

Since you're already here, any chance you can talk a little bit more about upcoming plans for managed vms? I hear there is a lot of investment in that area, but what will that mean technically going forward? How are things going to change so we can plan better?

I don't want to hijack the Kubernetes launch thread, but feel free to send me an email at dlorenc@google.com and I'll answer whatever I can. We have a lot of exciting stuff going out soon.

I could swear I saw "kubernetes" in the URL when I spun up a ManagedVM not to long ago. Thanks for the correction.

I've found Heroku to be about 10x the cost of AppEngine for the same kinds of apps and users. I don't even want to imagine what it would cost to create my own ec2 sprawl to do what AppEngine can do out of the box. As far as languages go, I've gone to production with AppEngine apps written in Python and Clojure. I've diddled with Go. Unless what you want is something like Node.js, which has its own limitations, I don't see this as a big problem. As far as Datastore is concerned, you can substitute the implementation of it using technologies like AppScale: Cassandra, Hypertable, etc. But I've never seen another structured storage solution in a fabric form that works as well as Datastore for 90% of my problems AT SCALE. YMMV.

FWIW, Amazon has something similar in Elastic Beanstalk. Haven't used either personally, but they are comparable services.

EB is more like Heroku than it is like AppEngine. As far as I'm concerned, the thing that makes AppEngine amazing is Datastore and how easy it is to do monstrous, sophisticated Map/Reduce over your data. I haven't even started using Spanner/Dataflow yet. It's an amazing platform (that is not without its rough edges, mind you).

In the Container-as-a-Service there's also EC2 Container Service (ECS). AWS just did a nice technical deep dive on how their orchestration works:

http://www.allthingsdistributed.com/2015/07/under-the-hood-o...

There's also a hosted version of Kubernetes, called Google Container Engine: https://cloud.google.com/container-engine/

I've worked on what is ostensibly a Heroku competitor (Cloud Foundry).

I don't see where the limits on languages, frameworks or data stores comes in.

Languages are extensible in buildpacks, data stores are ordinary services. Heroku pioneered the 12-factor app model, Cloud Foundry lets people run it themselves.

The "limitation" comes from the notion that you code to a particular implementation with Heroku (or Cloud Foundry). If you want to change implementations, you must code to that new implementation. With a true aPaaS, the implementation can change, but your code goes against the same fabric-like API.

Can you give an example?

Because I am just not seeing your point. The whole point of a PaaS is to not code to an API. You throw a 12-factor app at one and it Just Works.

Reply on news.ycombinator.com