What does Chill Code do?

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.



A Little Bit of Background

There’s a lot of philosophy behind the way we built Chill Code.  Not so much in terms of development techniques or Agile methodology but rather in terms of what we are up to, who we are doing it for, and why we think they need it.  I thought I might take a little time to explain how we got to where we are.

We began with an observation.  Two actually.  The first observation was that the number of people out there with a great idea vastly exceeds the number of software architects, and infrastructure engineers (cloud or otherwise) available to help those people out.  If you are a small group of very creative engineers you are faced with a few options, none of which are particularly appealing.  You first option would be to just “wing it” and put together your infrastructure and to the best of your abilities.  If you do that you are making a couple of pretty bad compromises.  For one thing, you are guaranteed to get some serious things wrong (security, and scalability are the obvious ones). For another, you end up taking a significant amount of time learning to do something which is neither directly you “big idea” nor is it something which you are likely to add any value.  That’s the first observation – the one that produced one of our first tag lines “helping developers make good software, not bad infrastructure.”  Your other option would be to hire on a very expensive architect type early on in your project, an expensive proposition which – speaking as someone who spent a fair amount of time in enterprise architecture – I wouldn’t recommend.  Not that enterprise architects are bad folks, but good ones are rare and expensive and likely will continue to be so.  On top of that they aren’t really going to contribute too much to your “big idea” either.  Software architects, and infrastructure engineers have spent their careers learning and practicing precisely all that esoteric stuff that you don’t know, but they almost certainly have not spent their lives thinking about the thing that drives you to create your project.

The second observation was more geared toward how software and infrastructure architecture is practiced.  If you compare how your friendly neighborhood software architect works and develops their skills, to how a developer works you should be struck by how arcane and in some ways backward it is.  If you are a developer and you want to figure out how to do something, yes you probably read books, but chances are one of your first stops is Google where you will find an enormous set of references and examples of similar things to what you were after.  Go to some place like Stack Overflow and you have an incredible repository of practical advice and information.  A software architect on the other hand, must trawl through a mountain of detailed reference material, generally quite theoretical and then synthesize that with her own experience to come up with something which may or may not be right.  She’ll spend a frightening amount of time trying to keep up on the latest developments in a tremendous variety of technologies, with essentially no hope of keeping up.  Someone once asked me how much time I spent just doing reading and research, my answer – about 20 hours a week.  I can’t say whether that is typical or not, but I wouldn’t be surprised if it were.  Now I recommend spending as much time as possible reading and researching, but when you compare what an architect has to do to get a solution to a problem to what a developer needs to do – i.e. google, and failing that a post a question “Hey how do I do X?” it’s pretty backward.  For all intents and purposes there is no real online community equivalent of Stack Overflow, or GitHub for infrastructure and software architecture patterns.  The mechanism for that kind of doesn’t really exist – and although some developments have been made in the realm of “Infrastructure As Code” there’s no social exchange for the exchange of practical and actionable material.  We sometimes refer to this as the “Stack Overflow argument” or the “GitHub for infrastructure” argument, in the sense that what we want is the same sort of vibrant referenceable community resource as those two sites.

These observations led us to the conclusion that what we should be doing is removing the friction in this whole area of implementing an idea.  If you are “Bob with The Big Idea” then you shouldn’t be forced to make the compromises I made above, and if you are “Sue the Expert Architect” you should have an easier life.  So how do we help Bob and Sue – well it’s an old story by now – let’s build a useful online community for Bob and Sue to exchange information, i.e. the patterns, we call them Chills. Sue gets to test out and refine her ideas, and see how many folks are using her patterns and get direct feedback.  Bob, on the other hand gets what amounts to a fitness tested design pattern.  Throw in a about a year’s solid work and presto change-o you have Chill Code.

We have a quite a few other “philosophical” points of view, which I or Jasper will explain in other posts going forward.  These all have their own little sobriquets such as “Reward learning and effort, don’t punish ignorance,” and “Make doing the right thing to do the easiest thing to do.”