.svg)
Are you an AWS user considering moving to Kubernetes ? Think twice before going down that road as there is a better alternative – Convox.
AWS ECS
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 Convox 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
Is Convox better than 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.
What are the benefits of using CONVOX?
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.
What are the disadvantages of using CONVOX?
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 examples of CONVOX
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.
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.
.png)
