With the proliferation of hybrid cloud, cross-cloud and post-cloud environments, finding the right concepts and tools to produce mixed-technology applications and services remains challenging. At Zurich University of Applied Sciences, a course on Serverless and Cloud-native Application Development (SCAD) prepares bachelor students in computer science for facing these challenges. We argue that this is the first such lecture in Switzerland and probably even in the world. Three years after reflecting on Internet Service Prototyping teaching, this mid-semester blog post sums up the evolution of the field, explains the course design of SCAD and briefly reports on the lab results.
With the increased adoption of serverless computing, so is the need to optimise cloud functions, to make use of resources as efficiently as possible, and to lower the overall costs in the end. At the Service Prototyping Lab at Zurich University of Applied Sciences, we investigate how cloud application and platform providers can achieve a fairer billing model which comes closer to actual utility computing where you pay only for what you really use. We demonstrate our recent findings with AWS Lambda function pricing.
In a previous post, we showed how it’s possible to trigger a Knative service when a database update occurs using the DebeziumKafka Connect plug-in connected to Knative; here, we continue this work by describing how we connected a Nextcloud file storage service to Knative, triggering a Knative service/function when a file is uploaded to Nextcloud.
The Serverless Application Repository by Amazon Web Services (AWS SAR) is, in simplified terms, a marketplace for Lambda functions. You can speed up application development by building on the functions (or function compositions) provided by it, and you can share your own functions with other cloud application developers. AWS SAR was launched over a year ago. In the Service Prototyping Lab at Zurich University of Applied Sciences, we are investigating better ways of building applications for cloud and post-cloud environments. Consequently, we did a full year observation of AWS SAR to find out what’s in it and what’s going on. Read on for some interesting excerpts and findings and for accessing the study document.
The first four “wild” years of serverless computing, starting with simple Function-as-a-Service (FaaS) launches in 2014, are over, and we are in the fifth year now. All major cloud companies offer FaaS, corresponding Backend-as-a-Service (BaaS), and related “serverless” services such as frameworks for cloud function-based data processing at the edge or in constrained environments. Researchers from universities, research institutes and research divisions in companies have covered this development, and proposed improved systems and frameworks, since 2016 – trailing two years behind industry initially, but with promising designs and prototypes which may give the necessary impetus for a next-generation serverless computing paradigm. We have surveyed 130+ research papers and announce the Serverless Research Output website which makes the results accessible.
Yesterday, we had the opportunity to attend the excellent ServerlessDays Zurich event which brought together folks interested in serverless technologies in Zurich. It was an all day event with 66 folks in attendance.
With interest in serverless computing increasing rapidly, the question of which technology solutions will win is receiving much interest. Although there is significant industrial activity relating to serverless – driven primarily by the AWS Lambda ecosystem – there is a clear need for solutions which are not premised on lock-in to a single provider and which can work across clouds. OpenWhisk and Knative are two technologies which focus on this space – here we consider the relative positioning of these technologies based on our experience working with them.
In two previous blog posts – here and here – we discussed our experience with deploying OpenWhisk on Kubernetes on OpenStack. As applied researchers at the Service Prototyping Lab, we are investigating potential use cases for such setups and for FaaS-based applications in general. In this blog post, we will therefore describe how we built a sample MQTT-based application that shows OpenWhisk in action for sensor data processing for future Internet of Things and smart dust scenarios.
The basic idea of the application is that it consumes data from an MQTT feed, stores it in a database and provides a means to access the database via a web UI. The architecture of the application is shown in the figure below. The application is based on this blog post.
In a previous blog post, we described our experience with deploying OpenWhisk on Kubernetes on OpenStack. During subsequent testing, we observed some issues with the OpenWhisk deployment wherein some OpenWhisk components – specifically, the controller and the invoker – would fail to restart after rebooting the machines running the Kubernetes nodes for maintenance tasks. To fix this, we had to redeploy OpenWhisk after each failure which resulted in significant data loss and was clearly an unacceptable operational solution.