From June 24 to 27, an academic double-conferences has been taking place in Prague: IC2E 2019, the venerable seventh IEEE International Conference on Cloud Engineering, and ICFC 2019, the recently spun off first IEEE International Conference on Fog Computing. The Service Prototyping Lab at Zurich University of Applied Sciences contributed a tutorial on Kubernetes application engineering on the first conference day. The important research-inspired message conveyed is that Kubernetes is a nice container management platform, but not a cloud platform per se, and characterised by a lack of tools to ensure simplicity and quality in applications, and still emerging understanding of how to design applications in a technically and economically optimal way. This blog post reports on some of the conference discussion topics as a service for those who could not attend..
The eternal software circle of life continues to pose non-trivial challenges. Developers write code, run tests, push and/or deploy, perhaps leading to more tests, and finally see their software used in production. Eventually, they might see everything working out correctly or rather not, as indicated by log messages, user complaints and other side channels, and even more eventually, when nothing else gets in the way, they might even attempt to fix the problem at any code location which might have a probability of contributing to the issue.
While hybrid, multi- and cross-cloud applications are on the rise, even for scenarios in which purely public cloud deployments are planned, having an equivalent private cloud stack available is useful in many ways. With the relative portability of popular open source cloud stacks, this is rather trivial to accomplish. For many large cloud providers, there are commercial solutions like Microsoft’s Azure Stack, IBM’s Cloud Private, Oracle’s Cloud Native Framework, Google’s Anthos (née CSP), Alibaba’s Apsara Stack and Amazon’s AWS Outposts (as well as Greengrass for Lambda and other specialised offers). Yet sometimes, these are not an option for technical or business reasons. In this blog post, alternative options are discussed.
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.
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.
For almost five years, we have been researching cloud-native applications. As part of an industry-wide push to cloud-native computing, a lot of stacks and middleware components are proposed every day, but few tools and processes help improving the applications themselves especially in terms of quality attributes such as discoverability, elasticity and resilience. With Helm charts, there is already a higher-level approach to package cloud applications in Kubernetes environments. Our work on static analysis of Helm charts and quality assessment beyond is documented and ongoing. In this post, we take a first look at CNAB, or Cloud Native Application Bundle which is self-described as secure and cloud-agnostic way to deliver applications.
In our research group, we have for many years observed and systematically explored how cloud applications are being developed. In particular, we focus our investigations on cloud-native applications whose properties are largely determined by exploiting the capabilities of modern cloud platforms for both their development and operation. As we are involved in European research on testing cloud applications (Elastest), our aim was to look at the current project results through the cloud-native glasses. This blog post reports about end-to-end testing of composite containerised applications from this perspective.
In recent months, we have extensively studied Helm charts, including setting up a continuous quality assessment, to find out more about this promising packaging format for Kubernetes applications. Apart from individual tweets and occasional talks, there was a lack of a coherent presentation of the ongoing work. Yet, due to the increasing installation base of Kubernetes stacks, the significance of this work appears to be on the rise. This blog post therefore tells what we achieved already and what we are still going to do in the next months.