We are announcing the latest release of the open source Cyclops framework, as part of our ongoing work to advance metering and monetization across cloud platforms, bringing improvements and new capabilities:
meaningful logs, now able to identify errors more effectively and
provide more information on generated records
checkpointing, with the ability to roll coin rules back using git
versioning and re-create affected records
In previous blog posts – here and here – we showed how to set up OpenWhisk and deploy a sample application on the platform. We also provided a comparison between the two open-source serverless platforms OpenWhisk and Knative in this blog post. In progressing this work, we shifted focus slightly to that other critical component of realistic serverless platforms, the services that they integrate with – so-called Backend-as-a-service – which are (arguably) more important. For this reason, in this blog post we look at how to integrate widely used databases with Knative and potentially OpenWhisk in future.
Our initial thoughts were to leverage database trigger mechanisms and write components which would listen to these events and publish them to a Kafka bus. Indeed, we started to write code that targeted PostgreSQL to do just that, but then we came across the Debezium project which essentially solves the same problem, albeit not in the same context, but with a much more mature codebase and support for multiple database systems. It didn’t make sense to reinvent the wheel so the objective then turned into how to best integrate Debezium with Knative.
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 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.
Our SPLab organised a full day workshop on cloud-native applications (see the web page and call for papers of the CNAX 2018) within the IEEE/ACM UCC/BDCAT 2018 umbrella.
The workshop was organised in collaboration with Ivo Krka from Google and also supported by Jorge Cardoso from Huawei. The blending of industry and academic research has always been a key point in cloud-native work which relies heavily on fast-paced innovation.
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.