Cloud 66 started over 6 years ago with a single product: the best way to deploy any Rails application to the cloud. Rails developers loved our product and we grew quickly as the result.
6 years on and now tens of thousands of developers in more than 100 countries around the world use our products. We are also not a single product company anymore. After Rails we rolled out our Node.js product, then Docker backed stacks and our Kubernetes based products, Skycap and Maestro followed.
As a Rails customer of Cloud 66, you might feel we have forgotten about you and Rails. You might think we are constantly talking about containers, Kubernetes, and all those buzzwords, while we should be focusing on our Rails roots. Today I want to tell you that Rails is precisely why are investing heavily in containers.
To tell you this, let me first run through how our Rails product has evolved. The first release of Cloud 66 was made up of 2 components: a multi-cloud API to fire up servers and a customizable Capistrano script. If you've been with us long enough, you'll recall how our customers wanted us to support DigitalOcean back in 2013 when DigitalOcean didn't have an API, so I worked with Moisy, one of DigitalOcean cofounders, to spec out the first version of their API and wrote the first Ruby client for it. Soon we realized our customers are not using us just to deploy their applications, but to maintain their infrastructure for them too. This meant patching servers, building and running database servers, taking care of backups and database replication, network and firewall setup, inbound traffic management, logging facilities, team and user management across all accounts and servers, building UI over environment variables and secrets and tracking their changes, audit logs and more and more and more.
This wasn't just a Capistrano script anymore and that was exactly our vision from the beginning: we wanted Cloud 66 to be like your in-house ops team but at a fraction of the price, always up and always on top of the latest threats, best practices and technologies, and run in front of you so your business doesn't stumble when you run so fast.
Cloud 66 runs on Rails and has been since day 1. We also run Cloud 66 on Cloud 66 Rails and while not the biggest, we are our own first customers! Like most of our customers, we wanted Cloud 66 Rails to:
- Be faster in deploying to new servers and scaling up
- Have auto-scaling features
- Run multiple stacks on the same servers
- Let us deploy to fewer servers to keep our cloud bills lower while not sacrificing our up time or capacity.
- Let us rollback quickly
- Support gradual rollouts like canary releases
These are not requirements from a large enterprise customer but from many of our customers, including ourselves. We could have built all of that into our product (and in some cases, we tried!) but we also wanted to stay with industry standards as much as possible and let our customers leverage open source communities if they want. As operators, looking at what technologies can deliver those features to us and our customers, Kubernetes is the best one around. We have been using Kubernetes for our Rails stacks for over 2 years now and I can't recommend it enough.
However, building and maintaining a Kubernetes stack and deploying a production Rails stack on top of it is not easy at all. So about a year ago, we set out to build the best Rails deployment experience on Kubernetes ever. This is no simple task and we wanted to get it right. We wanted our customers to be able to deploy their Rails stacks on Kubernetes without knowing or caring what actually runs it and without having to learn Kubernetes. This meant using the same code analyzers we use on our Rails product to generate Kubernetes configuration files while taking care of things that are tricky on Kubernetes for a Rails stack like database migrations, asset compilations, setting up SSL certificates or traffic management.
Over the course of the past year, we've been building the basic blocks of that experience: Formations, Stencils, ConfigStore and many of the features we have built and announced in Skycap are those building blocks that will let us deploy our Rails stack to a Kubernetes cluster. We are not done yet and have some more work to do. But I wanted to share my excitement about this with you as I can finally reveal how all of our container talk is actually a means to deliver the best Rails deployment experience possible to our most loyal and supportive customers: our fellow Rails community. Once we're done, you'll be able to deploy your Rails stacks to any Kubernetes cluster anywhere with the same ease as you are familiar with in our Rails product, without all of that container or Kubernetes complexity, while benefiting from everything containers have to offer.
We will be sharing more about our progress here soon and around RailsConf. Stay tuned!