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.
Serverless applications is one topic that SPLab has been working on for a couple of years now, with, for example, our work on a stand-alone FaaS platform Snafu, work on disaggregating applications into serverless functions, Podilizer and other activities. Having organised ESSCA some weeks ago, we are now again exploring the technical limits and challenges in this space. This blog post reports about our experience of running the combination of OpenWhisk, Kubernetes, Helm and OpenStack.
Bachelor students of computer science at Zurich University of Applied Sciences focus a lot on software development. Software is never developed in the blue; rather, software needs a concrete environment to function and to deliver value. In ‘Programming’ (1st/2nd semester) and ‘Software Development’ (3rd/4th semester), you learn some basic skills. In ‘Systems-oriented Programming’ (2nd semester), you apply these skills to predefined systems with some constraints. In ‘Web Development’ (3rd semester), you apply these skills to another environment in which there is a lot of pace through new technologies. In ‘Game Development’ (5th semester), you develop for specific interactive scenarios, and in ‘Mobile Applications’ (5th semester, you develop user-facing apps for common mobile platforms.
One of the most fascinating and economically important areas is the development of applications which run in the cloud. You may access them with web or mobile devices, but you still cannot see them! Still, they are very powerful, scalable to millions of users, and interconnected across cloud providers and with various backend systems such as databases, message queues and key-value stores. This is why we offer SCAD, a new elective module on Serverless and Cloud-native Application Development.
Through several years of research on the subject of cloud functions, researchers including ourselves have gained a thorough understanding of the advantages and disadvantages of function-based application development. Along with increased maturity of FaaS, a more specialised consideration of potential use cases is needed to filter out the ones where the technology shines compared to the ones where significant weaknesses become apparent and other technologies, perhaps even in combination, would be a better fit. This early experience report informs about how we have deployed cloud functions around an existing cloud management platform as a variant of the well-known solar system approach of introducing microservices around monoliths.