All Posts in “DevOps”

How to save a billion dollars tomorrow…(Guest Blog by Eugene St.Clair)

GeneMy first guest blogger is a long time friend, Eugene St.Clair is CEO at Humanproof, a Human Factors Engineering consulting firm headquartered in Arlington, Virginia. He has 14 years of experience supporting the FAA, Navy, Homeland Security, and other government and commercial clients and strives to bring Human Factors Engineering and Usability testing to air traffic control, information management systems, and other large-scale systems such as ships, healthcare, and energy production. Using the disciplines of Human Systems Integration (HSI), Gene and Humanproof help to reduce total system lifecycle cost, human error, and improve total system performance and safety by addressing the needs of each user in the context of the task, system, and operational environment.

How to save a billion dollars tomorrow…

I will start by saying that I recognize there is no ONE right way to do anything. With that said, I also won’t hesitate to say that my way is better than yours. In all seriousness though, each method has its pros and cons and I offer up only a suggestion that may augment our capabilities, speed product development, increase user satisfaction and user adoption, and ultimately advance the progress of the human race.

I have heard much about development processes such as waterfall, scrum, spiral development, sprints, etc etc etc. I have heard much from software developers about how modules and tasks can be split up and built and basically after very few meetings and little understanding of the real requirements of the end product, everyone runs off and starts coding, building, and trying to figure it all out. This method is then mitigated by more frequent meetings and increased communication among the team.

PaaS is BadaaS

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

How to get started with DevOps

DevOps-Panther I have previously covered what DevOps is, there is a greater question of whether or not DevOps is a good thing or not. I believe that DevOps can help but may not be for every working environment or organization.

I was working with a team recently on a proposal to help a customer who wanted to implement a DevOps and service catalog framework. One of the team members sent me the Statement of Work (SOW) and it had a few objectives and associated goals and tasks. All in all a very nice representation of an SOW for project related activity. What it wasn’t though or at least not in my opinion was an implementation of a DevOps model.

We went back and forth via email on what DevOps is and what first phases were it went something like this:

Them: We are looking to do an application rationalization engagement and build out the hybrid cloud service catalog.

Me: But you said the request was to transform their teams to utilize a DevOps model of application and infrastructure management. That means we need to help them visualize the work they have in process (WIP), identify their workflows, and leverage the team mentality that will reduce deployment cycles and improve time to value.

Them: Right we are going to do that by showing them where their application workloads should sit.

Me: …