Chill Code is a public recipe book, and a robot, for deploying software infrastructure into the cloud.
The recipes (chills) are provided by all of you (our users) and defined within our user interface (the Chill Code website). Many of the best early chills are recipes for deploying websites. For example, the WordPress chill defines:
- software (Apache HTTPD, PHP)
- files from GitHub (config + demo content)
- a slot for a database
- a startup command and various configuration options (e.g. port 80 is public)
Here is a screenshot of the public page for that WordPress chill:
I describe Chill Code as a public recipe book. By default, every chill is public, although private source code remains private. If you have taken the time to connect bits of software together and push them to the cloud, then you have a use case and some reasoning behind the implementation. The chances are that others have a similar use case and can learn or benefit from your design and reasoning – so why start research from scratch each time? Collective wisdom creates better software infrastructure in an age when there are fewer specialist infrastructure folk.
Therefore chills are optimised by us to be discovered by other users via search engines, social media etc…. tuned by the various indicators we have for how popular a given chill is. Every public chill page highlights the author, the number of forks and how to fork it.
The robot is our automation engine that takes the recipe defined by a given user (or a version forked by other users) and executes the steps in the recipe to deliver a piece of software infrastructure in the cloud. In practice this means that the robot is doing some of the following:
- Instantiating one or more server instances on AWS (other providers such as Azure, Rackspace, Cloud to come soon).
- Installing the open-source software defined defined within the recipe onto the relevant server instances.
- Instantiating other services provided by the cloud provider – today, this means databases, but other services such as load balancers are in the pipeline.
- Installing software or content from GitHub (other repositories to be supported eventually).
- Compiling source code if a supported build file (nix) has been provided
- Configuring the server instances with environmental variables and port visibility
- Starting the software defined in step 1.
Thereafter, Chill Code monitors your service at a high level (we are not a monitoring tool, but one could design chills with monitoring built in) and provides buttons to start and stop your environment.
The recipes are abstracted away from any definition of environment so that one may run multiple environments (Dev, QA, Prod) with different configurations (1x server vs 3x servers) in different clouds (AWS vs Azure). Eventually we shall expose an API that allows users to embed control over these environments in their workflows (e.g. spin up environments in unit tests, provide failover for production). That API is extant but unhardened.
Indeed, it is not hard to see all the directions that we could take Chill Code. We could provide a lot of poorly implemented solutions. But we are disciplined and our focus is on providing the greatest solution for capturing and delivering the collective wisdom of developers and engineers pertaining to software infrastructure and automating that wisdom in a form that delivers immutable, consistent and consistently great software infrastructure.
Chill Code 