The Service Prototyping Lab at Zurich University of Applied Sciences is committed to advancing the state of technology for bringing applications to the cloud, for the benefit of the society of large in general and of the local industry in particular. This obliges us to closely monitor industrial trends along with academic advances. A hot topic currently found in both is the higher-PaaS-level service class of FaaS, or Function-as-a-Service, which coincides with the marketing term Serverless Computing. We have already contributed analytical work on finding the limits and possibilities of today’s FaaS systems (preprint), and engineering work on translating legacy monolithic code into fine-grained functions (preprint). It was only a matter of time until the limits in both commercially operated FaaS services and open-source FaaS prototypes became too severe for our work. Hence, after a careful analysis of what is available, we decided to come up with an alternative FaaS host process design. The design led to an architecture, and the architecture eventually to an implementation called Snafu. This post presents Snafu and positions it as Swiss Army Knife for situations in which functions should be prototyped, tested or hosted.
NetSys is a regular biennial conference covering networked and distributed systems. This year, NetSys’17 took place in Göttingen, Germany. We have attended and report on some of the research and technology trends, obviously with a focus on our own research directions. Apologies ahead for not giving a full account of the whole conference as our presence was limited by lecturing duties.
The world of research is a complex one which despite myths does not exist in isolation. And publishing is another world within this world which is mythical even to most researchers. Open access models are being widely discussed, but there are trends and necessities going beyond and evaluating other, more consequent options. This post reports on the trends and options with the aim of becoming a text piece rich enough of information to initiate fruitful discussions on how we, as wider research community around service, cloud, distributed computing, should publish our work, our results and our interactions around them.
Title: MOSAIC – Monitored Platform for Container-Based Applications
Industry Partner: VSHN AG
Research Partner: SPLab and ICCLab, ZHAW
Funded By: Commission for Technology and Innovation
Summary: The MOSAIC project focuses on providing a platform for delivering any kind of application as a service, with a focus on container-based applications. It features an integrated incident management system as well as a container-optimized storage system. The platform will be able to deploy hybrid applications split into multiple locations, optimizing resiliency and cost in the process, as well as support continuous integration and deployment of each service.
Project MOSAIC aims to deliver a platform to deploy and manage distributed, container-based applications. None of the currently available Platform-as-a-Service frameworks provide the same benefits to application developers: MOSAIC delivers a vendor-independent, Platform-as-a-Service framework independent, software suite which can orchestrate applications on multiple providers, automatically monitor them during runtime, automatically detect and resolve runtime incidents, all based on a custom storage backend optimized specifically for container-based cloud-native applications.
Document management is an established software-powered business domain. As with most software applications, an ongoing trend is to move the functionality of document management systems (DMS) and related functionality (Enterprise Content Management – ECM, Content Services – CS) into well-defined services, primarily in cloud environments, resulting in cloud-native document management systems/services (CNDMS).
In the context of the research initiative on cloud-native applications and the ARKIS project within the Service Prototyping Lab, we have been looking deeper into the issues surrounding cloud-native document management and have built a prototype implementation to test-drive any ideas and new concepts. This post introduces the software and the challenges already solved with it. Continue reading
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.
Service prototyping is still a young topic when it comes to cloud services, web services or other network services. Researchers are concerned with defining the topic more accurately and finding out which metrics matter, for instance time, quality or cost. New definitions, methods and tools will result from this process.
In a previous blog post, we have discussed the process of automating service and API prototyping tools on the scripting level, ensuring that all commands to install dependencies and to configure the software are executed properly, in order and without omission. The tool in focus has been Ramses which turns RAML web service descriptions into executable prototypes. The focus of this post is to take this idea further to the SaaS and web application level. A convenient web application, accessible from every browser, should offer a guided prototypical service generation based on just the service interface description which specifies its resources, methods and data types.
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.
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.
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.