One year ago, we started running the cloud-announce mailing list for the wider research community in the area of cloud computing. The list serves to connect people in this area, but it also serves as rough indicator of research trends and pace. It is time to reflect on the first year of operation, revisit some policy decisions, and give an outlook for 2017.
Our lab (Service Prototyping Lab) offers a unique homonymous elective module on the bachelor’s level in computer science at the School of Engineering at Zurich University of Applied Sciences (ZHAW): Internet Service Prototyping. In the recently concluded semester term, the module was organised for the first time. Several students were brave enough to vote this combined Monday-morning lecture and lab into their curriculum which takes place in the 5th semester for full-time students and slightly later for part-time students of computer science. This post reflects on the educational motivation, the design of the course, the didactic and technological concepts, and some expected and unexpected results in the wake of rapid technology changes on a monthly basis.
An academic entity – more concretely, a research laboratory – resembles a stateful function: It receives input and generates output based on both the input and on previously generated knowledge and results. The input is typically a mix of fancy ideas, industry necessities, as well as funding and equipment. The output encompasses publications, software and other re-usable artefacts.
In the Service Prototyping Lab, we rely on access to well-maintained cloud environments as one form of input to come up with and test relevant concepts and methods on how to bring applications and services online on top of programmable platforms and infrastructure (i.e., PaaS and IaaS). This Samichlaus post reports on our findings after having used several such environments in parallel over several months.
With the end of August 2016, the Service Prototyping Lab (SPLab) finished its first year of operation. The applied research lab contributes to a better understanding of Software-as-a-Service (SaaS), cloud-ready and cloud-native applications, industrial domains for hybrid cloud applications (e.g. Cloud Robotics) and prototyping techniques to rapidly bring new complex Internet services to the market. Coming now into the second year, we’re even more ready to act as innovation partner with scientific work techniques to Swiss and European companies and research institutions.
We all know this tedious situation: Plenty of mobile robots around us, and we’d just like to use one of them for a specific task, but we don’t know which one we should take, as they’re all regularly busy on their own. Perhaps this is not a likely scenario right now, but it will be in five or six years from now and it will require novel approaches of how we manage their functionality in terms of services they offer. The Cloud Robotics research initiative is thus looking into robotic device management not so much from a hardware perspective but more from an angle of assessing which robotic resources can be used to deploy or run services and value-added applications on single robots, fleets of robots, or hybrid cloud/fleet constellations. With Roboreg, a first tangible robot-specific registry concept has been realised. The tool will be explained in this blog post.
The Elastic Compute Cloud (EC2) offered by AWS as public commercial service has been one of the first and probably the seminal service for the research on cloud applications and infrastructure. From an application perspective, hosting in EC2 means wrapping the application into one of the provided virtual machine (VM) images and instantiating it in sufficient numbers (e.g. with autoscaling). Ultimately, for custom applications, it also possible to import custom VM images. This involves creating the machine image, testing it on a local hypervisor (KVM, Xen, VirtualBox, …) or in a local cloud stack (OpenStack, CloudStack, OpenNebula, …), then copying the image into the Simple Storage Service (S3) (in a reliable manner), initiating the import process, and waiting for the VM image called Amazon Machine Image (AMI) to become available. This import process is not well-documented and regularly causes high effort with application providers. Hence, this blog post offers a detailed walk-through and points out common pitfalls.
Cloud services are meant to be elastically scalable and robust against all kinds of failures. The core services are very mature nowadays, but the tools which glue them together are often in need of quality improvements. Two common risks in networked environments are (1) unavailability and (2) slowness of services. The first risk is easier to detect but more severe in its effects. Furthermore, there is a dependency between the two as timeouts in many layers of the software cause unavailability failures upon strong slowdown. Timeouts should be avoided but are often part of protocols, libraries, framework and stacks with almost arbitrary combinations, so that in practice, failures happen more often than necessary. This post shows how research initiatives in the Service Prototyping Lab work on improving the situation to make cloud services access more robust and easier to handle for application developers.
The goal of the Cloud Robotics initiative of the SPLab is to ease the integration of Cloud Computing and Robotics workloads. One of the first things we need to sort out is how to leverage different networking models available on the cloud to support these mixed workloads.
In this blog post we’ll see one little handy trick to have ROS nodes run as pods (and services) in any Kubernetes cluster so that they can transparently communicate using a ROS topic.