Convox As A Solid Kubernetes Alternative
Are you an AWS user considering moving to Kubernetes ? Think twice before going down that road as there is a better alternative – Convox.
To be more precise, the alternative to Kubernetes on AWS is AWS EC2 Container Service (ECS) and Convox just works on top of it, providing elegant environment to manage applications and deployments.
The biggest disadvantage to Kubernetes is that you are going to have to rely on AWS platform, but if you already use AWS, this shouldn’t be a problem.
HOW IT WORKS
So there is ECS, you can think of it as a AWS alternative to Kubernetes, it allows you to create cluster on top of EC2 instances, scale it, run docker apps on it, scale them and load-balance traffic using Elastic Load Balancer.
4 nodes with 23 running containers.
The biggest problem with ECS is that it is hard to configure, you have to either use their web forms to deploy an app or write nasty json configuration files – yuck!
Convox gives you whole environment where you can design how app should be running and then run it locally or on the cluster. Some its noteworthy features include:
- Building an application and storing version history
- Rolling updates (zero downtime deployed)
- Health checks
- Rollbacks, to any previous version
- Log aggregation & search
- Scaling your app (memory, processor, container instances)
- Scaling your cluster (more nodes or upgrading node’s type)
- One-off commands
- Cron-like tasks
- Managing SSL certificates
WHY NOT KUBERNETES
The biggest advantage of using Convox is that it requires almost zero DevOps time, creating cluster and deploying first app takes minutes. Thanks to AWS and ECS, it just works, you don’t need to worry about networking, configuring fluentd or other parts of Kubernetes.
I am not saying that Convox is better than Kubernetes in every case but if you are a team of 5 developers just entering the world of containers going with Kube would be an overkill.
Even if you are bigger but already using AWS platform, Convox could still be a better option than Kubernetes. It all comes down to just how much you need to customize your cluster setup.
CONVOX: THE GOOD PARTS
First thing to notice is that it reuses docker-compose.yml file and extends it with labels to define how app should be build and run. Except for Dockerfile this is the only file you need to configure your app.
You can run any app locally almost as if it was run in a container (it even creates fake load balancer), which is really great. This way your local environment can mimic production more accurately, what is always welcome.
You have control over environment variables of deployed apps. Moreover, changing any of them creates a new release as if you would build a new version. This is really nice because you have a version history of env variables changes.
You can easily bash to the running container or spin a new container to run one-off command (like DB migrations). You can even run periodic, cron-like jobs, what is truly amazing.
CONVOX: THE BAD PARTS
For us the most annoying part is that you can’t provide your own ID when building new version and then use that ID to reference the build when releasing. Convox always generates its own ID and that is what you have to use.
This is problematic when you have Continuous Delivery and you build every commit on every branch, when you want to automate deployment you have a problem because you don’t know the ID of the release.
The other thing is that in Convox, there is no concept of application environment like in Elastic Beanstalk. Application environments allow running multiple environments side-by-side like production, staging and testing, where each one could be running a different build.
So basically after building new app version you can choose on which environment you want to promote that build.
Unfortunately, this is not possible in Convox, to workaround this we create multiple apps like appx-production, appx-staging, appx-testing and then our CD has to build multiple times, once per app.
Lastly, there is no official way to run off-cluster builds, which would be really nice when you have your own CI/CD. Although there is a workaround, we still wait for official solution.
REAL LIFE EXAMPLE
Here is a real life configuration that we use for one of our applications.
docker-compose.yml file that defines how app runs locally and on cluster.
|$ convox ps --stats|
|ID NAME RELEASE CPU % MEM MEM % STARTED COMMAND|
|194e11bd73ba celery RRQAMDWPRFM 0.27% 255.9MB/256MB 97.95% 2 days ago sh -c "/base/entry celery_worker --concurrency=4"|
|921d844e2f8e celery RRQAMDWPRFM 0.26% 255.3MB/256MB 99.76% 2 days ago sh -c "/base/entry celery_worker --concurrency=4"|
|958a76250efe celery RRQAMDWPRFM 0.22% 255.2MB/256MB 94.96% 2 days ago sh -c "/base/entry celery_worker --concurrency=4"|
|d6620aa2e68a celery RRQAMDWPRFM 0.26% 255.9MB/256MB 99.46% 2 days ago sh -c "/base/entry celery_worker --concurrency=4"|
|de6852cc3a3d celerybeat RRQAMDWPRFM 0.01% 63.9MB/64MB 99.77% 21 seconds ago sh -c "/base/entry celery_beat"|
|6a96a6d6c6ad hd RRQAMDWPRFM 0.69% 384.0MB/384MB 99.99% 2 days ago sh -c "/base/entry web"|
|db5807b27812 hd RRQAMDWPRFM 0.44% 383.0MB/384MB 99.99% 2 days ago sh -c "/base/entry web"|
|d5e64d11ec03 web RRQAMDWPRFM 0.66% 383.9MB/384MB 99.98% 2 days ago sh -c "/base/entry web"|
|69a4a04e1118 web RRQAMDWPRFM 0.01% 383.8MB/384MB 99.95% 2 days ago sh -c "/base/entry web"|
|88e752f5c1e2 web RRQAMDWPRFM 0.32% 383.2MB/384MB 99.95% 2 days ago sh -c "/base/entry web"|
|9606de3cfc58 web RRQAMDWPRFM 0.46% 383.8MB/384MB 99.95% 2 days ago sh -c "/base/entry web"|
Each of the services can be scaled independently
Convox is a really great piece of technology, anybody using AWS that is considering switching to Kubernetes should give it a try. We did and after half of year of using it on production it works flawlessly and we are really happy with it.