When I first started writing applications that ran in OpenStack clouds or worked against the APIs the experience was painful. To figure out what I could do with the APIs I ended up in the source code for OpenStack or asking those who were in the source or knew the system better. If I’d been using a different, maybe more popular, cloud I could have quickly found my answer in the documentation. As a user I longed for something better.

Fast forward to today. OpenStack has come a long way in many regards. Yet, I still find myself poking around in the code and the community to figure out how some things work. Just last week I learned about two undocumented REST API calls that I would be using if I’d known about them.

This isn’t to say that the documentation team is somehow lacking. There is a lot of documentation and they have a real desire to provide useful documentation. I appreciate their work and drive to get us to something better. Making things better just takes more than a documentation team.

Application Developers

The target audience here is those who write applications that run in and against OpenStack. This is the audience who will build the OpenStack ecosystem. The audience who will influence their organizations to use OpenStack based on whether the experience works for them.

It’s important to know that this audience is different than those who build OpenStack or operate it. Sure, there is some overlap. Yet, there is a significant amount that’s different.

Since this audience is building their own applications they are interested in how their applications function, how OpenStack behaves, and the APIs their apps interact with. They shouldn’t have to know or spend time looking into how OpenStack works. They should never need to open the code. Doing so takes on extra cognitive load and spends time they aren’t spending on their product.

For OpenStack to be successful we need to have application developers who are successful.

Application Developers at Atlanta Summit

When the track listing for the conference portion of the Atlanta summit came out it was great to see one for Apps on OpenStack. At the summit there were a handful of sessions as well. It was great to see this segment and I hope to see this contingent grow over time.

The only two problems I saw were the small number of app devs and when two summit sessions for this crowd were at the same time.

developer.openstack.org

The Friday before the summit developer.openstack.org came online. This is the first iteration at providing a place for application developers. I was quite happy to see this online, look forward to it helping application developers, and am hoping that there is continued iterative improvement in it.

Software Development Kits

The long tail of application developers are going to benefit from some good SDKs in the popular programming languages. Prior to 2014, the only option provided by OpenStack were the service clients which were for python only and not intended to be for this outward audience. The alternatives were often built by a vendor and none of them enabled you to work with multiple REST API versions along with a number of other nuances.

In 2014 a number of efforts were started in Stackforge and, where there were already popular cloud libraries, some combined efforts continued to improve them. In Stackforge there are now efforts for PHP, .NET, Go, and Python. The general cloud libraries include support for Ruby, Java, and JavaScript.

Just Anteing Up

What we have right now is just the beginning of what application developers need. The latest Thoughtworks Technology Radar say that OpenStack is labeled as trial rather than adopt. Making OpenStack easy to get stood up is one thing. Enabling the users of those clouds to be successful is another.

I look forward to the end users being successful because that will drive OpenStack to be successful.