Open Stack

The #OpenStack Seattle community and progress of Cloud technology

I had the opportunity to be a part of the #OpenStack Seattle conference yesterday in the morning. I was invited by Sriram who runs the local chapter. If you dont know much about OpenStack, it is an open source initiative to help companies run their own private and public clouds. There is an awesome getting started reference card that Sriram has put together for you to read as well.

OpenStack has been around since 2010, but only now has started to pick up steam. Over $1.5 Billion worth of market value has been created around the software. It helps you manage compute, networking and storage resources, provision them, optimize and also help you scale the cloud solution you decided to manage.

There were about 150 folks at the meetup, a third of them having implemented OpenStack in production, another third considering it and the remaining who were too bored to raise their hands.

Open Stack
Open Stack

The thing that I found interesting is still the resistance in larger companies to open source software. This was named as the #1 barrier to adoption among most of the folks I spoke with. This is a real problem that exists after so many years of open source in the enterprise. Many people whose jobs depend on applications and services being available and performing well still want to be able to have a company or another organization support them through the process.

The perception among many of the folks who are in traditional technology organizations (who run internal systems) is that open source is largely unpredictable, mostly renegade and insufficiently production ready.

There are 2 observations I had from the various presentations yesterday morning.

First, developers are becoming more powerful in the IT organization compared to the Operations teams, which were pretty powerful 10 years ago.

Previously you had to ensure that the application that you built was on an environment that the Operations team (DBA’s system administrators and network administrators) supported. Most operations teams had standard policies around the database used, the languages and environments supported, so most applications were fairly similar.

If you were building an app that had intense media or voice / video usage, you had to build so much into the app to work around the limitations of the environment used.

Not any more.

The #1 issue that I heard from many of the operations folks is that developers are starting up instances on the public cloud, using a set of “right technologies” for the app – based on their familiarity, hosting and supporting the app themselves until the innovation phase of the app is done and then “throwing it over the wall” for the operations teams to support them.

Second, the “stack choice” – which database to use, which language, framework, caching system, platforms (IoS, Android, etc.) to support is also a lot more complicated for developers.

This is a serious problem for developers. If you are developing a data science, or big data application, you are likely to use R or Python.

If you are however building a simple internal CRM app, then you might choose to build it with Javascript and a Node.JS or Backbone.JS framework.

Add the concepts of containers, virtual machines (which are phasing out), microservices, API based systems, and many more choices, you are suddenly spending a lot of time figuring out which “stack” to use.

Most developers are just talking to their friends at companies which have done similar apps and “copying and pasting” their stacks.

This will be a very interesting space to watch in the next few years.