← All Articles

What Git and EC2 have in common (and what can we learn from that)?

Khash SajadiKhash Sajadi
Nov 3rd 12Updated Jul 27th 17


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 trunk.

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 with the 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
software does.

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.

Try Cloud 66 for Free, No credit card required