Running a successful developer workshop (aka tutorial) is really difficult. I’ve attended enough workshops that have gone poorly to know that for a fact. Participating in such a workshop can be very frustrating and a huge turn off for whatever technology is being presented. That translates directly into losing developer mindshare. I think we, as an industry, can do a better job of running developer workshops.
So you have spent months convincing your leadership to go with OpenStack. Finally the keys of the cloud are turned over to you as the Cloud Operator, and you then look over at your co-workers and say “now what”. The next set of phrases normally are something like: Now how do we best administer this cloud? Cloud is suppose to be easier, right?
The goal of this post is to develop an application in an environment that’s as close to your remote deployment environment as possible. Let’s do this using Docker Machine and Compose to move an app from local development to remote deployment.
Through the course of technology, infrastructure and application monitoring have changed positions. Not so long ago, monitoring was an afterthought when rolling out your new application or standing up your new rack of servers. More recently, I have observed monitoring to be one of the first considerations, to the point where it is actually in the initial project plan.
This evolution, while late in my mind, is the right direction…not just for the System Admin who gets the 2AM email alert or the application owner who on a monthly basis sadly report to his leadership 97% SLA on his app. Truly knowing how your application is affecting your infrastructure is one of the keys to a successful cloud.
With monitoring now being in an elevated position, that then leaves you to think: what should I use for monitoring? While there are plenty of software solutions in the market, many of which solve for different problems.
OpenStack Swift is the object storage project within OpenStack. From the OpenStack Swift documentation, “Swift is a highly available, distributed, eventually consistent object/blob store. Organizations can use Swift to store lots of data efficiently, safely, and cheaply.”
Now that Swift can be easily deployed and used, what are some of the use cases for it in Rackspace Private Cloud?
Architecting applications for a cloud environment usually means treating each cloud server as ephemeral. If you destroy the cloud server, the data is destroyed with it. But, you still need a way to persist data. Cloud block storage has typically been that solution. Attach cloud block storage to a cloud server, save your data within that cloud block device, and when/if the cloud server is destroyed, your data persists and can be re-attached to another cloud server.
At first glance, Ansible and Docker seem to be redundant. Both offer solutions to the configuration management problem through very different means, enabling you to reliably and repeatably manage complicated software deployments. While you certainly can use either on its own with great success, using both together can result in a fast, clean deployment process.
There are two ways that you can combine them, both useful for different reasons. You can use Ansible to orchestrate the deployment and configuration of your Docker containers on the host, or you can use Ansible to construct your Docker container images based on Ansible playbooks as a more powerful alternative to Dockerfiles.
As a PhD student at UC Berkeley, my duties involve some amount of teaching; so, this semester (Spring 2015), as well as last spring, I have been a teaching assistant for a class taught by my advisor, Tom Griffiths. The class, called Computational Models of Cognition (COGSCI 131), aims to introduce students to computational models of human behavior. The problem sets are a mixture of simple programming assignments—usually requiring students to implement pieces of different models—and written answers, in which students report and interpret the results of their code.
In the past, the problem sets were written in MATLAB. This year, however, we decided to make the switch to Python. In particular, we decided that the IPython/Jupyter notebook would be an ideal format for the assignments. The notebook is a cross-platform, browser-based application that seamlessly interleaves code, text, and images. With the notebook, it is possible for us to write instructions in the notebook, include a coding exercise after the instructions, and then ask for their interpretation of the results immediately after that. For an example of what the notebook looks like, you can check out try.jupyter.org for a demo.
OpenStack SDKs exist for several programming languages, including Python, Go, Ruby, and many more. For those who don’t wish to write code, users in the *nix world can use Curl at the command line to perform operations.
What about Microsoft Windows administrators? Are they required to learn linux and bash and curl? What if they could use the skills they already have, or learn new skills that are native to the Windows environment, for OpenStack administration? Is there a command line or scripting tool that suits the Windows DevOps world?
This is the fourth and last article in my series on OpenStack orchestration with Heat. In the previous articles, I gave you a gentle introduction to Heat, and then I showed you some techniques to orchestrate the deployment of single and multiple instance applications on the cloud, all done with generic and reusable components.
Today I’m going to discuss how Heat can help with one of the most important topics in cloud computing: scalability. Like in my previous articles, I’m going to give you actual examples that you can play with on your OpenStack cloud, so make sure you have an environment where you can run tests, whether it’s a Rackspace Private Cloud, DevStack or any other OpenStack distribution that includes Heat.