Container Service as a Service

works in dev all the way down.

Great distinction. Either way it's nice to see DO expand its offerings. Love their service and the team.

Maybe this is a dumb question, but couldn't/shouldn't a KaaS (and other orchestration systems) just be a layer on top of "vanilla" CaaS?

CaaS-es (i.e. "things that present themselves as a Docker daemon or something like it") don't allow you to provision IaaS-level resources like VMs or disks, merely connect your containers to existing resources. When CaaS-es do allow you to provision stuff (like e.g. Hyper.sh does), they do it through a direct IaaS-level API that is separate from the functioning of the CaaS itself.

The major cloud providers' deployments of Kubernetes (and other server-side persistent-orchestrator systems, like the venerable CloudFormation) are deeply integrated into the cloud platform they're running on, such that the orchestrator itself can provision resources for a container to run on as part of deploying the container. This becomes important when elastically auto-scaling a container, because each container might need e.g. its own disk, and you can't create them ahead of time if you don't know how many you'll need.

This also means that, unlike a CaaS, k8s et al can manage the very cluster that k8s is running on, scaling it out to suit the size of the current/estimated workload.

Theoretically, you can bootstrap k8s on top of a vanilla CaaS—this is how minikube installs "using" your local Docker install, and this is how deployable PaaSes like Flynn and Deis work. But this approach doesn't supply k8s with the cloud-specific integration it needs in order to provision stuff. It might work if you're deploying against something with a standardized API like OpenStack; but none of the major cloud providers are compatible with such APIs, and so they need to build their own k8s plugins that call their IaaS-level APIs, to make k8s work on their clouds.

Or, to put all that another way: if there were standard IaaS-level APIs for k8s to hook into, Docker (and the CaaSes that either use or emulate it) would just hook into those APIs itself, and there would be no need for a higher orchestration layer.

tl;dr CaaS doesn't orchestrate the underlying infrastructure whereas k8s primary purpose is to create a cloud agnostic way to orchestrate containers and the infrastructure that they run on.

Kubernetes has worked to not be coupled to Docker (http://cri-o.io / https://www.opencontainers.org/), so in a sense, it already is built on top of a "vanilla" container service.

Don't you need to setup network paths? And connect containers to each other..

Then setup/teardown in specific order.. and if you have state, keep a subset of containers alive to avoid loosing state (even if it's replicated).

Kuberneted is designed in a way where stateless pods (collection of containers sharing the same ip and identity) are decoupled from stateful ones. There are concepts designed into K8S that allows components to attempt to self-heal.

For example, a pod that requires a postgresql pod to connect to will fail and crash out. The scheduler will start a new one. If the postgresql pod is up by that point, then the rescheduled pod will no longer crash.

As far as the network paths, one of the really cool things about pods running inside a k8s cluster is that they can access any of the other pods, even if they are on a different node. However, pods typically reference services (such as postgresql) by dns name. You specify the set of pods that belong to the service by label selector. This allows the pods to come up, tear down, crash, moved to another node, while the service maintains a stable point of contact. It is quite brilliant, and other orchestrators quickly tried to copy it.

Stateful workloads are still difficult. Each distributed stateful system has its own way of setup and teardown. What we will probably see are custom Operators designed for each distributed stateful system, coming out over the years.

Curious - what are some good alternatives to Fargate? Enjoy the ease of use, but more expensive than I'd like for low-to-no traffic side projects

GCP has Serverless Containers coming soon: https://cloudplatform.googleblog.com/2018/07/bringing-the-be...

Zeit V1 supports launching containers (but isnt part of V2): https://zeit.co/docs/v1/getting-started/deployment/#docker-d...

Digital Ocean Droplet

AWS Micro Instance

AWS Lightsail

Linode Nanonode

Shared Hosting

-----

Tons of options for $5 a month.

Sorry, should've been more specific - looking for the same sort of 'provide a container and we take care of everything else' experience, but ideally for a cheaper price. I know I could get a micro instance and set up ECS on it, but it just seems like such a royal PITA...

Also like how my deploy script is basically 'build image; push image; aws ecs update-service'.

With my side projects that are running on a droplet, it feels like there's an incredible amount of additional setup that I need to do every time I add an additional project. Add the new site to the reverse proxy, setup a git server I can push to, set up post-receive hooks for the server, etc., etc.

I would look into the first option, Digital ocean's droplets.

You deploy a docker container and they handle the rest

How do you do that? I only know the traditional "install OS and handle devops yourself" model.

Having said that, I got a cheap and rather beefy server on Hetzner and installed Dokku on it, and I couldn't be more satisfied. It's like having my own Heroku for my low-traffic side-projects, almost for free.

what makes ECS 'vanilla'? i thought it was just a bespoke competitor to K8s.

Maybe you're thinking of EKS? ECS is an extremely basic scheduler that's closer to Nomad.

EKS is no more a competitor to K8S than DOK8s is a competitor to K8s. The CNCF Conformance page[1] shows a link to a spreadsheet[2] which indicates there are currently 96 products by 82 different vendors, including 34 hosted platforms like EKS, which are all Kubernetes.

ECS on the other hand, is a so-called "vanilla" container service which provides its own abstractions and offers no suite for conformance, or compatibility with other vendors' offerings. I have not heard lots of people say great things about ECS. If I could say one nice thing, it's that there is probably less to learn about ECS than about Kubernetes.

[1]: https://www.cncf.io/certification/software-conformance/

[2]: https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4Eb...

For me, ECS having less to learn was its main appeal. You get integration with AWS load balancers giving zero down time deployment and its API to automate is very straight forward. I set it up 2 years ago and have barely touched it. I evaluated K8s at the same time and after a full day was left completely confused how to do the same thing even if I spent a full werk.

ECS has definitely got some oddities mainly in the task definition spec which is most a 1:1 with docket commands but with their own AWS stuff mixed in. Part from that the simplicity vs K8s was its biggest draw card. Lot has happened with K8s in two years I’d imagine, so same choice today might be a different story.

that is correct