GoogleCL Puts Another Tool in the Devops Integration and Automation Toolbox

Google’s latest offering is a hint of things to come and indicates a recognition of devops as a real discipline

Interestingly enough devops is comprised of two disciplines: development and operations. The former traditionally solve problems and address challenges through development, through coding, through a programmatic solution. The latter, operations, is often more administrative focused and its solutions to the same issues and challenges will also be programmatic, just on a different level – that of scripting.

There is no right or wrong answer to this one; in fact the concept of devops is about bridging the gap that exists between development and operations and doing so in a way that enables IT to be more agile and able to extract benefits from emerging data center models like virtualization and cloud computing . Thus, it should not be a surprise to view the introduction of a CLI interface to Google as the means by which devops is enabled with another integration and automation option.

Ever wanted to upload a folder full of photos to Picasa from a command prompt? We did, a lot, last summer. It made us want to say:

$ google picasa create --title "My album" ~/Photos/vacation/*.jpg

So we wrote a program to do that, and a whole lot more.

GoogleCL is a command-line utility that provides access to various Google services. It streamlines tasks such as posting to a Blogger blog, adding events to Calendar, or editing documents on Google Docs.

For example:

$ google blogger post --blog "My blog" --tags "python, googlecl, development" my_post.html
$ google calendar add "Lunch with Jason tomorrow at noon"
$ google docs edit --title "Shopping list" --editor vim

GoogleCL is a pure Python application that uses the Python gdata libraries to make Google Data API calls from the command line.

Introducing Google Command Line Tool

At first glance GoogleCL is probably not a big deal. After all, there already existed an API that developers could leverage to take advantage of Google Data. But consider that most APIs = even though they may be REST-based and therefore more familiar and even usable to ops-focused admins, the lingua franca of the REST world falls squarely in what most would define as being definitely “developer-oriented”: JSON and/or XML. While admins are certainly familiar with HTTP and the ways of the Web, they may not be so comfortable with JSON and/or XML. Exposing an API through a scripting language that ops is familiar with like Python (or TCL, or PERL) is a definite step toward enabling the emerging devops paradigm to flourish and grow. The short example offered by Google in the aforementioned blog provides a glimpse of how documents and tools deployed within Google’s environment might be leveraged and scripted from within the enterprise in support of more integrated, streamlined operations.

Imagine, for example, that one of the applications you support wants to leverage one of Google’s existing services. Let’s say you’re going to use a Blogger account as a mirror “just in case” your own blog site gets overloaded because, well, every once in a while you write a really good blog and your existing capacity isn’t quite enough to handle the load along with all the other applications being serviced. So you’re going to mirror that blog on Blogger if the  traffic gets above a threshold. You don’t have to actually upload it right away. While in the case of Blogger it’s not incurring any costs to mirror the blog as a matter of operational policy, in other cases it might be and there may be business reasons why you don’t want it mirrored unless you’re forced to because of capacity constraints. So you don’t mirror unless it’s necessary. But then it becomes necessary. How do you rapidly mirror the blog to the external service and simultaneously ensure that it can be leveraged as another resource for requests for that blog? Operationally this becomes simple by executing a script that posts a copy of the blog via GoogleCL to Blogger and then notifying your traffic management device (load balancer, depending on your architecture ) that there is a new resource that should be leveraged to handle the load – which should also be available via either an API or a CLI scripting language. Or perhaps it’s as simple as enabling a network-side script that redirects to the blogger-hosted mirror when the connection count on your internal instances is over X or the network-bandwidth being used is over Y or whatever it is that triggers the need. This method keeps control with the organization but leverages off-premise services in a form of instant cloud-bursting. Instant (on-demand) capacity with a simple CLI script.