Every week here and in our newsletter, we feature a new developer/blogger from the DZone community to catch up and find out what he or she is working on now and what's coming next. This week we're talking to Matt Butcher, Lead Cloud Engineer at Revolv, Inc, author of seven books and numerous articles on technology, and teacher at Loyola University Chicago. Most recently, Matt was featured in DZone's 2014 Cloud Platform Research Report.
1. What have you been working on lately?
At Revolv, we are building a home automation platform that can link together a diverse range of best-of-breed smart devices (think Sonos, Philips Hue, and Belkin WeMo). We use a three-tier architecture (a hardware controller, mobile apps, cloud). The problems we deal with are complex, we iterate rapidly, and I work with some truly brilliant people. It's my ideal job. Technologically speaking, Revolv is on the cutting edge of what is poised to be the next big thing: the Internet of Things.
My domain is cloud services. So I oversee the REST API server, backend services, and also our cloud deployment platform. I've been working on porting a very large Java code base to a much smaller Go code base. Go is the perfect language for working with web services and REST. It is nimble, compact, and compiles to a variety of platforms. Google built it with HTTP-based servers in mind, and its core libraries reflect this focus.
2. Tell us in a little more detail how you created the mini-PaaS using Docker, Packer, and Ansible that you reference in the Cloud Research Report.
I really like Elastic Beanstalk, Amazon's PaaS-like tool. It solves some of the typical deployment issues well, and it offers the advantage of using compute instances in lieu of containers. But it only supports a few languages. Notably for us, it does not support Go.
When I expressed my frustration with the state of our PaaS alternatives, my colleague Lann said, "Hey, I think we could build something specific for our needs." And off he went. The next morning he demoed it, and by that afternoon we were using it for deploying one of our internal-only apps. Now we're looking at deploying more of our infrastructure with it.
The basic workflow is pretty straightforward:
- Build a suitable operating system image with Ubuntu Server, Docker, and Ansible
- Compile our Go sources (locally, before deployment)
- Create an Amazon AMI disk image with Packer
- Load that image to the cloud
- Spin up new VMs running that image
- Insert the new images into the load balancer
- Remove and destroy the VMs running the old image
Our little mini-PaaS is still pretty bare-bones, and still under development. But we feel like we're able to easily build what we need, without incurring hours and hours of extra DevOps time.
The cloud landscape is changing rapidly right now, and some really exciting things are happening with Docker and containers. We've got our eye on CoreOS. Once it matures, we may use that as the basis for a version 2.
3. Should we even think of this mini-PaaS solution as a cloud platform and a type of PaaS? Or is it more of a deployment utility, or a 'framework'?
That is a fantastic question that strikes at the heart of a vexed issue. The term PaaS is in danger of becoming too nebulous or watered down to mean anything. Recently, I wrote a blog post trying to nail down what the essential functions of a PaaS are. Briefly, a PaaS has five functions:
- Deploy an app from workstation to Cloud
- Provision the necessary environment
- Manage the applications lifecycle (start, stop, restart, pause, etc.)
- Manage extrinsic services (databases, message queues, etc)
- Report and monitor for critical events
A full-on PaaS like Stackato does all of these, and does so for a wide variety of use cases. Our nascent mini-PaaS currently handles deployment, some provisioning, and lifecycle management, but relies upon AWS for database, reporting, and monitoring.
Right now, our provisioning phase is not completely automated. We still do some manual work during deployments, but that will change as we learn the best way to reliable deploy.
4. Are there any particular developer tools or resources you couldn't live without?
I am deeply invested in Vim (Vi Improved). I tried using an IDE for a few months, and it felt like it got in the way more than it helped. These days, I use the Janus Vim distribution, which pre-loads and manages several useful VIM plugins. It's tuned for Mac OS X, but it works well on Linux, too.
I write lots of my documentation in Markdown format. The Mou app is great for that. I've also been testing out the [GitHub Atom editor](http://atom.io/). With its crisp feel and great feature set, I could imagine it becoming my documentation tool of choice.
Finally, I spend a lot of time working at the command line. On Mac, I love using iTerm2 with a Quake-style "slide-down-from-the-top" full screen setup. I'm also an avid fan of Oh-My-Zsh, a suite of tools that makes working with the already pleasant `zsh` shell even better.
5. Do you have a favorite open source project (or projects) that you've contributed to recently?
As I mentioned earlier, I've been focusing my development efforts on the Go language. To that end, Matt Farina and I have been working pretty steadily on a different sort of application framework called Cookoo. We've been playing it pretty close to the chest with Cookoo, but as we're closing in on a 1.0 release, I'll probably start talking about it a little more.
For the last few years I have been a huge fan of OpenStack. Recently, OpenStack adopted the PHP SDK that I wrote while at HP Cloud. Given my admiration, I'm really excited to be able to say that I'm an OpenStack contributor.
Also, we just issued version 1.0.3 of the HTML5-PHP library, the first full HTML5 parser/serializer for PHP. It has been fun to see the number of contributors on that project increase.
6. Do you follow any blogs or Twitter feeds that you would recommend to developers?
For cloud-related things, I am closely watching the CenturyLink Labs blog right now. They are putting together some really interesting projects. More than any other, that blog represents the rapid changes that are occurring in the cloud landscape.
I keep an eye on RedMonk, too. They put together some excellent developer-centered analysis on the state of technology. Just recently, they released their report on programming language usage. Their methodology includes tracking GitHub and Stack Overflow to see what people are really doing, and what questions people are really asking.
On Twitter, I enjoy @davecheney (he has a great blog, too). In addition to being an ambassador for the Go language, he does interesting things with the Raspberry Pi and other "tiny computers." I've also followed Hilary Mason (@hmason) for a long time. She is a witty and insightful data scientist. I'm always learning something new from this pair of developers.
7. Did you have a coding first love -- a particular program, gadget, game, or language that set you on the path to life as a developer?
I started my coding life with Perl. Yes, Perl. This was 1995, I was in high school, and Perl was a great language to learn on. I say that for two reasons.
First, Perl offered quick payoffs: I could be productive writing (really bad) short and easy scripts. I wasn't doing lame coding exercises, I was *writing tools*.
But Perl's hidden reward was in how it exposed me to the styles and techniques of other developers. As I used different Perl modules, I learned how stronger programmers solved problems. Perl's total absence of an opinion about what good code looked like forced newbie developers like me to learn, as the Perl mantra goes, that "there is more than one way to do it." In a peculiar way, Perl taught me not just how to write Perl, but how to write C, Java, Python, shell scripts, and so on.
8. Is there anything else you'd like to mention?
I've had an interesting experience over the last year. I've found myself swinging back from NoSQL to SQL-based databases. I don't have any "disillusionment" about either one, but I've found that the combination of great DBaaS providers and a possibly coincidental need to model mostly relational data, I've been much more productive with SQL-based solutions. For a guy who at one time swore he'd never write SQL again, it's really something to be excited again about good old fashioned relational databases.
That said, I'm realizing that some of the most frequently required SQL tasks, like migrating and installing, are still painful. These tasks get implemented in the application framework layer, which is the wrong place to put the logic. We just end up rewriting the same stuff over and over again. For Rails. For Django. For the Play framework. I'm looking forward to the day when some smart people build a tool to do this in a language/framework agnostic way.