Review: GlueCon 2014

GlueCon 2014 was held on May 21-22 at the Omni Interlocken Hotel in Broomfield, Colorado, and I was fortunate enough to be selected as a speaker there for the second year in a row. For those of you who aren’t familiar with GlueCon, it’s not quite an unconference, but it is a loosely-structured gathering of people working in lots of different technologies that drive the web today, with the focus on the “glue” that holds them all together: developers.

The morning of the 21st was a series of keynotes, and devops seemed to be the topic on everyone’s mind. There was one keynote in general that I strongly disagreed with: John Sheehan of Runscope claimed that “API SDKs Will Ruin Your Life” (the title of the keynote). The assumption, of course, was that the only reason that anyone would use an SDK is because the native API is terrible, and it is the reliance on SDKs that is causing API devs to get sloppy. While that might be true in some sense, the responsibility for creating a good API rests on the API developers, and if they are not professional enough to take pride in the quality of their APIs, I doubt that any SDK would change that. Creating good, consistent APIs is not easy, and typically shouldn’t be left to the the people creating the underlying product that the API is exposing.

The afternoon was broken into several tracks, with the idea that the talks in each track were related, and would happen one right after the other, with no break in between. This was when my talk was scheduled, and it was part of the Cloud track. The talk was titled “How to Leave Rackspace”, and no, I wasn’t encouraging people to leave Rackspace! (I like having a job!). It was about the realities of portability among clouds, and emphasized the importance of data gravity binding you to a provider. I also covered the importance of API compatibility, and how working with providers sharing a common API, such as OpenStack-based providers, won’t do anything about data gravity, but will at least allow your applications to run on different providers.

The script I showed used pyrax to transfer a running compute instance in Rackspace to the HP cloud, so that you could move an entire server with just a few lines of code. The overall lesson, however, was to take the time to choose your provider carefully up front, instead of relying on some promise of portability later. The audience seemed pretty engaged during the talk, but there weren’t many questions and what seemed like lukewarm applause afterwards. I was a little disappointed, but noticed the same pattern for the other speakers who followed me, so I thought it might be due to the format. Later on I did run into several people who attended my session, and their feedback was very positive, so that made me feel better about the talk. This was the first time I’ve given this particular talk, and so I was very appreciative of the feedback.

After my talk was an excellent talk by Cornelia Davis of Pivotal that gave us a peek under the hood of Cloud Foundry. I was familiar with what Cloud Foundry could do, but I hadn’t had any exposure to the underlying architecture, so this was very interesting. Following that were talks on OpenStack Swift and network virtualization, which were both full of useful information, and then there was a talk on “The New Development Experience” that had some good stuff on Bluemix, IBM’s implementation of Cloud Foundry, but was too filled with buzzwords to be interesting. For a sample of what I mean, here’s a sentence from the talk abstract:

“The cloud combined with the need-for-time to value is driving a movement toward a scalable and flexible cloud computing development model that provides application developers with the freedom to innovate rapidly, integrate with existing infrastructure, use or create APIs, and create cloud native applications”.

I spent the rest of the day working at the booth, and noticed a distinct difference in attitude from last year’s crowd. For some reason, the crowd last year was not only very pro-AWS, but actively hostile to OpenStack. This year I didn’t get any of that negativity; instead, I spoke with developers and business people who knew about OpenStack and Rackspace, and simply wanted more information. My favorite, though, was Atsushi Yamanaka, from IDC Frontier in Japan. He flew to the Denver area the previous day from Tokyo to attend GlueCon, and was flying back to Tokyo the day after GlueCon ended. Talk about dedication! He wanted to get a better idea of Rackspace’s presence in the Asia/Pacific area, both current and future, and unfortunately I had to explain that those decisions are made at much higher pay grades than mine!

The second day of the conference similarly opened with a series of keynotes. I had to work the booth and also work on some code, so I didn’t catch most of them. I did, however, catch the keynote by Joshua McKenty of Piston Cloud Computing, which I found to be equal parts entertaining and informative. I’ve known Joshua for several years now, since the birth of OpenStack, and know as well as anyone how he can tend to overstate things just to get a rise out of the audience. He also knocked SDKs, but made it clear that it was only when they were used as crutches for bad APIs, and I had to comment about it on Twitter. The example he gave was that if instead of a website, you had created a duck, when you create the duck API, it would be dumb to expose the gizzard and the inner workings of its circulatory system, yet developers do the equivalent of that regularly. When people want to use your duck, they are interested in its ability to fly or swim or eat or quack, and don’t really care about the incredibly complex implementation details that make those abilities possible. Developers, on the other hand, are so proud of their incredibly complex implementations that they tend to feature them front and center in their API design. This makes for an unwieldy API, which then almost forces users of it to rely on an SDK to be able to do anything useful.

There was another keynote by Julia Ferraioli from Google on developer outreach, and since that’s my job, I was interested to hear what she had to say. Unfortunately, the talk was really nothing more than the general knowledge stuff that people working in this field for any length of time already know; I certainly didn’t pick up anything new. I hope, though, that maybe some of the non-developers in the crowd learned something.

I wish I could comment on more of the talks, but again I spent a good part of the day either working the booth or writing code for work. I did see a couple of talks that revolved around novel uses of Docker to either speed up or reduce the cost of CI/CD enviroments; it certainly seems as though Docker was the new hotness among developers at GlueCon.

I can’t say enough good things about the event itself: the location, the organization, the food/refreshments, the attendees, and the quality of the talks were all excellent. If you get a chance to attend GlueCon 2015 next year, go for it!

PyCon Canada Review

It’s been almost a week since PyCon Canada ended, and I had meant to write up a review, but I was busy, so better late than never.

Besides an opportunity to learn more about Python, this conference served as a “training ground” for next year’s PyCon Montréal, which is where the 2014 US PyCon will be held. Yeah, I know, it seems silly to still call it PyCon US instead of PyCon North America, but I suppose it has to do with domain names, trademarks, etc., so I’ll refrain from ranting about that. So to that end, I volunteered to be an MC for roughly half of the total conference. Normally for PyCon you have two roles: Session Chair, who introduces the speaker, times the talk, and manages the Q&A session; and Session Runner, who makes sure that the speaker gets from the green room to the correct session room, and who handles any problems such as missing video adapters, etc. But for PyCon CA, this was changed so that there was an MC and a Runner. The MC was someone with experience from PyCon US, and they served for half of the day in the room. There were fresh runners for each session, but rather than just escort the speaker, they did everything that session chairs and runners do, with the MC guiding them and making sure that they knew what was expected, and who could help out if there were any problems. So in many ways, though I spent half the conference running the talks, I felt like I hardly did anything. The runners did just about everything, and I only had to help out a few times. I have no worries that they’ll be ready for the big leagues next year!

As expected, there were many interesting sessions. I’m not going to give you a summary of everything I saw that I liked, but instead I’ll touch on a few highlights. Probably the one that made the biggest impression on me had nothing to do with Python per se, but instead was about Sketch, a programming language designed by MIT to get children thinking about programming without saddling them with the tedium of learning syntax. This was shown in the keynote on Sunday given by Karen Brennan, who is an Assistant Professor of Education at Harvard University. Besides making it easy for the kids to get started learning about programming concepts, it also makes it easy for them to share their projects, or to take someone else’s project and add to it. In other words, they are teaching kids about the benefits of open source and shared code! And while it’s designed for kids, I think it would also be a huge benefit for non-technical adults by helping familiarize themselves with programming without having to get totally geeked out.

Another talk I enjoyed was Git Happens, which was given by Jessica Kerr. This was one of the talks for which I was MC’ing, and hadn’t otherwise planned on attending, as I’m comfortable enough with Git. But rather than be bored, her way of explaining how Git works was much, much clearer than I have ever been able to manage when helping someone else get up to speed with Git.

Brandon Rhodes gave an excellent talk entitled Skyfield and 15 Years of Bad APIs , which covered his efforts to re-write his astronomical calculation library. It was fascinating to see how decisions which seemed reasonable at the time turned out to be less than optimal, and how he learned from them to make the new version much cleaner. As an aside, if you haven’t seen Brandon talk, you’re missing something special. He blends insight with an extremely dry sense of humor, making for a very enjoyable session.

I’ve already written about Dana Bauer‘s Red Balloon demo, so I won’t repeat it here. Suffice it to say that it captivated the attention of everyone in the room.

My talk was basically the same talk I had given the previous month at PyCon Australia, but in a much shorter time slot: 20 minutes instead of 45! I spent much of the time before the conference consolidating my slides, and eliminating anything I could in order to cut the length of the talk. I practiced giving the session over and over, speaking as fast as I could. When the time came, I apologized in advance for the speed at which I was about to give the talk, and then blazed through it. To my surprise, I managed to finish it in 18 minutes, and had time for a few questions! Afterwards I spoke with some who attended the talk to get an idea how it seemed to them, and they didn’t feel like I skipped over anything that made it hard to follow, which was my goal when I was paring it down.

After the sessions had ended, I went with a fairly large group of people to a local restaurant. I didn’t know very many people, and those with whom I sat were all from the team in Montréal who were going to be running PyCon 2014. They started out as strangers, but by the end of the evening (and more than a few pitchers of beer!), we became friends, and I look forward to seeing them again in Montréal next April!

OpenStack Miniconf at Pycon AU 2013

Friday was the pre-conference day, with two miniconfs: one for Django, and the other for OpenStack. While I’d love to spend some time digging deeper into Django, I figured that given my background as an OpenStack developer, the OpenStack miniconf was for me.

There were probably 40 people or so in attendance, and it was a good mix of those who were completely new to OpenStack, those who have looked into it a bit and wanted to learn more, and those who either were core developers or (in my case) a former core dev. Tim Serong from OpenSUSE opened up the day with the talk “WTF is OpenStack?“, which was an excellent introduction for those who had heard a lot about this “cloud” stuff. The presentation included the classic spoof by The Onion about “that Cloud thing” (with apologies to Robert Collins of HP, who really does totally know what that is). He covered all the projects within OpenStack, and how they work together.

Robert Collins then followed with a talk on “Deploying OpenStack using OpenStack“, which tackled the issue that although OpenStack allows you to automate the provisioning of cloud resources, installing OpenStack itself is a terribly manual process. His solution is “TripleO“, which stands for “Openstack On Openstack”. It sounds similar to the iNova project from Rackspace, but with several differences. From the ReadMe:

TripleO is the use of a self hosted OpenStack infrastructure – that is OpenStack bare metal (nova and cinder) + Heat + diskimage-builder + in-image orchestration such as Chef or Puppet – to install, maintain and upgrade itself.

Christopher Yeoh of IBM was next, and gave an excellent overview of the changes coming in v3 of the Nova API. The current v2 API was smartly designed by making only a precious few critical parts part of the core API, and making everything else an extension to this core. The problem is that some of the implementation details that seemed wise at the time are starting to show some cracks, both with consistency in naming and in the connection to the core Nova code. Nova v3 API addresses these problems by removing the requirement that extension name matches the class name, allowing for cleaner (and thus more consistent) extension naming.  Extensions now must be derived from a common base class; this was optional in v2. Overall, it was apparent that the people working on the v3 API had learned the lessons that the v2 experience offered, both good and bad, and that as a result the v3 API will be much more consistent and robust.

After lunch Tim Serong gave a talk on the state of OpenStack development on OpenSUSE. They are doing some interesting stuff with Crowbar for deployment, and have spent a lot of time on their internal CI processes. I didn’t take very extensive notes, as this is an area that I have little experience and/or interest in, but it was obvious that Tim is passionate about this, and that they are doing some excellent work at OpenSUSE.

Next up was Robert Collins again, this time talking about testing, covering both improvements in the tools themselves (e.g., the testtools module), as well as his work in creating a test runner runner. No, that wasn’t a stutter – this is a script to run a test runner, such as Jenkins in this case. With the growth of projects in OpenStack, it can take a very long time to run the tests, which is done when a change is first proposed for review, and then again when it has been approved to ensure that no conflicts have creeped in while the change was in the review process. In order to speed this up, his test runner runner breaks the tests into several parallel processes, and then aggregates the results. This means that the time required to run all the tests  can be reduced greatly, depending on the number of parallel processes. It also provides for test randomization, which can help reveal hidden test inter-dependencies.

Next up was a talk on how to get involved in OpenStack development, which covered the basics of where you can find bugs to work on, or blueprints to contribute to, as well as the review process and Gerrit. Michael Still from Rackspace was supposed to give this talk, but the birth of his child was a bit more important, so Robert Collins stepped up and did the talk for him. This was more of a review session for me, but it had a lot of useful information for those who were new to OpenStack development.

That was the last talk; after that was the hackfest, which had the goal of getting participants to find a fairly simple bug, fix it, and submit it for review. In practice, though, most of the time was spent helping people get Devstack up and running on their machines. Those of us who were OpenStack ‘veterans’ helped where we could, and in the process I had some great discussions with people about OpenStack, so even though we never got to fix any bugs, I believe that the people there who were new to OpenStack got a lot out of that time.

Finally was the bar track! Many of the miniconf attendees, myself included, retired to one of the many bars here at Wrest Point, and enjoyed a cold beer after a long day of learning about OpenStack.