Git changed the way we think about source
control. Before the days of Distributed Version Control Systems (DVCS)
like Git and Mercurial, branching was a
scary thing to do. It was to be avoided if possible since you were going
feel so much pain when it was time to merge your branches back in to the
Git made branching super-easy. Now we branch every time we need to make
a change, do a hotfix or add a new feature. Tools like Git
Flow make that even more streamlined.
This ease has made us change the way we develop software and think about
development. We no longer worry or think about running three different
changes in parallel, because we do them in different branches. We can
checkout other developers code in the middle of our development with
Git has changed our development paradigm, because it is not just a
better Subversion. It is fundamentally different.
The same thing happened when Amazon released
EC2. As Infrastructure as a Service (IaaS) has become more and more popular, commoditised and accessible to
everyone, the way we think about servers has changed.
It wasnt long ago (and it is still the case in some big organisations)
when getting a new server meant filling out forms and signing off
approvals, waiting for the procurement officers to run a tender, get the
prices, compare them and place an order for a new server. You had to
then wait for 4-8 weeks for the new kit to arrive and another 2 weeks
for it to get fitted into a rack, another week for it to be provisioned
official tools and be handed over to you.
Now that has changed: You might have to wait 4 weeks for a IaaS to be
chosen by your procurement officers, but once you have an account with
say Terremark or Amazon you are good to go
and can fire up servers with a couple of clicks.
With this power at your fingertips, you can now think about your
architecture differently. You no longer need to make your software fit
the existing infrastructure: your infrastructure can change as your
This has changed the way we look at servers and infrastructure. IaaS is
not just a quicker way of getting servers up and running, it has
fundamentally changed the way we look at developing software.
Now I think it is time for us to do the same thing with another
important part of development cycle: Deployment.
Traditionally deployment has been the painful point of development
cycle: configuration files, operational requirements and handover
documents. Some industries like finance have strict rules about
deployment cycles: numerous environments before production, several test
cycles and release schedules. This all is in contrast with the agile
development philosophy of rapid iterations.
This is were we want to make a difference: we want to change the way
developers think about software deployment by making it easy and
painless. At Cloud 66, our mission is to drag
software deployment and operation out of old school of development into
the new world of agile and fast iterations.
By making deploying new software stacks a quick and painless practice we
want to change the way we think about developing software again.
Cloud 66 is not just an easier way of deployment and operating your software. This is fundamentally different.