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.
Month: December 2016
In the context of the ECRP Project, which is part of our cloud robotics initiative, we are aiming to build a PaaS solution for robotic applications.
The “Robot Operating System” (ROS) is widely used on several robotics platforms, and also runs on the turtlebot robots in our lab. One of the ideas behind cloud robotics is to enable ROS components (so called ROS nodes) to run distributed across the cloud infrastructure and the robot itself, so we can shift certain parts of the robotics application to the cloud. As a logical first step we tried to run existing ROS nodes, such as a ROS master in containers on Kubernetes, then we tried to use a proper Platform as a Service (PaaS) solution, in our case Red Hat OpenShift .
OpenShift offers a full PaaS experience, you can build and run code from source or run pre-built containers directly. All of those features can be managed via a intuitive web interface.
However, OpenShift imposes tight security restrictions on the containers it runs.
These are:
- Prevention from running processes in containers as root
- Using random user ID for running containers (Support Arbitrary User IDs)
Overview
Function-as-a-Service (FaaS) is a relatively novel approach to run fine-grained code on the cloud. Almost all major cloud providers have opened such services in recent months. The approach still needs to be investigated in terms of evaluation, use-cases, performance and programmability. The first step of research was to overview the FaaS providers and to estimate their features and technical characteristics. The results were described in our previous blog-post. The FaaS paradigm allows one to write light-weight hosted functions targeted on a certain task and upload them to the cloud, or even author them online in Azure and Bluemix, for instance. But what if the user already has an existing application and would like to move it to a FaaS platform, or in marketing terms, to a “serverless” architecture. The Podilizer tool aims to perform an automated translation of existing Java code into uploadable functions and to deploy them to cloud in one go. This tool is related to research on the degree of automation and flexibility in terms of switching service technologies without development effort.
Rapid service prototyping, cloud application prototyping and API prototyping are closely related techniques which share a common goal: To get a first working prototype designed, implemented and placed online quickly, with small effort and with little headache over tooling concerns. The approaches in this area are still emerging and thus often ad-hoc or even immature. Several prototyping frameworks do nevertheless show a potential to become part of serious engineering workflows. In this post, the Ramses framework will be presented and evaluated regarding this goal.
The serverless architecture is getting a lot of attention and there is a lot of talk going on about it (forbes, gigaom, techbeacon). This new architecture is especially useful for developers since there is no need to worry about deployment or interactions between different servers. The developer only needs to worry about the code, a function. Functions are the way applications are written in this architecture, otherwise known as Function as a Service (FaaS).
Last week we organised the 7th SDN workshop with our collaborators and co-organisers SWITCH at their own premises in Zurich. The bi-annual workshop was the 2nd in the series of this year’s workshop. Wondering why the 7th SDN workshop took place for only half a day? So did we with our co-organiser SWITCH, before we got to know it was a public holiday in many Swiss cantons 🙂
Nonetheless and as usual, it brought high quality speakers and talks in a relaxed atmosphere of discussions and debates. What follows is a short recap of the presentations, as usual for those who missed the event.
There is an ongoing debate in the community about the level of awareness (and related to this, influence) an application or SaaS instance should have concerning where and how it is hosted. The arguments range from “none at all”, spoken with a deploy-and-forget mindset, to “as much as possible”, spoken with a do-it-yourself attitude. In practice, some awareness and influence is certainly present, for instance in application-specific autoscaling, self-healing, self-management in general.
One particular aspect in the discussion is about whether an application should know in which cloud environment it is running. Even though the engineer may have targeted a specific stack with project conventions, there may be migrations between several instance of the same, e.g. different installations of OpenShift, Cloudfoundry or other stacks to run cloud applications, across regions or even across providers. Already some time ago we looked into identifying the level of virtualisation in a nested virtualisation context. Now we complement this vertical view with a horizontal one. This blog post does not argue for or against cloud provider identification; it merely describes a tool to gain this knowledge and exploit it in any possible way. The tool is called whatcloud.
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.
Subscribe
Subscribe
Recent Comments