Admittedly it has been a long time since I have written code as part of my job. I have written scripts and worked on projects but not really true code writing to build an application. Now everyone seems to be doing just that, my 9 yr old daughter is interested in writing her first app for her iPod Touch, my 13 yr old nephew has taken coding classes and gone to coding summer camp.
I am however a big consumer of apps, whether it is the Movember app during the month of prostate awareness in November, or twitter or any of the countless others that I have installed across devices. The saying “software is eating the world” appears to be true. I am constantly looking for ways to interact with customer service and sales people less and less and report issues or buy things through apps.
The types of applications have changed too, I am not talking about the Exchange and SharePoint monoliths that require months of planning and deployment time and consulting hours. I am talking about the mobile applications and the homegrown in house finance and collaboration systems that are popping up through out corporations and agencies. These applications are written in Java, Python or Ruby and are developed using agile methodology. They are deployed iteratively and constantly updated to ensure they are meeting their users needs and requests. This is the age of software, and perhaps it really is eating the world.
Enter PaaS
That’s where PaaS comes in, let’s imagine a world where corporate Git repositories are leveraged to collaborate on application builds. The code is then stored in the repository, the agency has infrastructure in multiple datacenters and have already tackled the job of creating a service catalog for the traditional platform 2 applications (Exchange, Windows, SharePoint). In this world there would be a PaaS instance deployed in each of their datacenters, as well as into a public cloud offering like vCloud Air\vCGS or even AWS. Now let’s say that our Developers have access to that PaaS and a browser (crazy talk I know).
Leveraging a Cloud Foundry deployment they could perform CF Push commands from the CLI or via the browser GUI call the Git Repository and deploy their application to any of the sites available to them or all the sites at once. Each dev team could have their own agnostic CF environments to deploy their application into and unlike OpenShift from RedHat these teams won’t be able to see or sniff the traffic running in other dev instances.
These applications can be pushed across sites and scaled up in seconds, 100’s of instances near instantly deploying all from code. The PaaS examines the code determines the infrastructure requirements and if they have the appropriate pieces be it a linux VM or an in memory database service and builds the required pieces as it deploys the application.
I know what you are going to say so let me beat you to it, “But Docker can containerize the application and allow me to deploy it to blank infrastructure as well”. The answer there is both yes and no, because Docker can enable application decoupling from the infrastructure and container based apps can be deployed more nimbly, however Docker requires a pretty sturdy infrastructure to stand on and still relies on a third party configuration and automation layer; think Puppet, Chef or Ansible. Docker is a cool technology but it fails to meet the same ease of deployment that Cloud Foundry has.
Don’t believe me? Check out this video demo:
Ok I get that it’s a marketing video but you see the potential it’s a matter of pushing out application code and being able to do it across instances and change pointers without downtime. Meaning you can have continual releases of the application. All Cloud Foundry cares about is Apps, DNS names, and number of instances, you don’t have to worry about whether the instance is starting because once you push you are told when the app is deployed. No more checking on your AWS instance to see if each service started.
To me PaaS really is the future and it’s cool as hell.
Try it yourself at
