Docker images have become the valuta franca in the cloud and container platform world. Although on the path to vendor-neutral standardisation (e.g. with OCI also being in Docker Hub for a year now), developers for now have settled on plain Docker as de-facto standard due to the vast ecosystem of base images and dependency images which speed up the rapid prototyping of complex scalable applications. From a production-grade DevOps perspective, a key concern is then to be assured that the containers used are of high quality, not infected by security vulnerabilities, and still containing the latest features available. In this blog post, a novel approach to visualise the situation around a particular container image is presented.
The MAO-MAO research collaboration aims to provide metrics, analytics and quality control for microservice artefacts of all kinds, including but not limited to, Docker containers, Helm charts and AWS Lambda functions. As such, an integral part of prior research has been the various periodic data collection experiments, gathering metadata and conducting automatic code analysis.
However, the ambition of the project to collect data consistently, combined with the need for the collaborators to be able to use each other’s tools and access each other’s data, have created a need for a collaboration framework and distributed execution platform.
In response to this need, we present the first release of the MAO Orchestrator, a tool designed to run these experiments in a smart way and on a schedule, within a federated cluster across research sites. As a plus, there is nothing implementation-wise tying it to the existing assessment tools, so it is reusable for any use-case that requires collaboratively running periodic experiments.
When cloud application developers are working with docker-compose to combine multiple microservices into a single manageable entity, they can make some easy mistakes. To prevent these mistakes, they can rely on internal validation logic, which however does not catch many of the typical issues. Therefore, researchers at the Service Prototyping Lab at Zurich University of Applied Sciences wrote a dedicated quality check and assessment tool targeting developers, but also students trying to learn the technology, which has a wider range of checks. The DCValidator tool is available as a web application (see demo instance) or command-line interface. This blog post describes how to check that docker-compose files are free of issues.
The occasion of the 3.3.2 release of the rating-charging-billing solution for cloud software and platform providers, Cyclops, is a good opportunity for a deep dive into the new forecasting engine, the how and the why of its functionality and how to use it.
First, a bit of news. Active maintenance and further updates to Cyclops will now be found under the repository https://github.com/serviceprototypinglab/cyclops. The primary new addition is the forecasting engine. It helps SaaS/PaaS/CaaS/…XaaS providers to not only charge customers for their services, but also predict a revenue flow for deciding about future investments.
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.
The latest update to the open source Cyclops Framework, part of our ongoing work to advance metering and monetization across cloud platforms, brings yet more new features and improvements:
Small fixes to the versioning/rollback features
New estimation and forecasting engine
The new forecasting engine is now built into Cyclops’ UDR service and can generate individual or global usage forecasts and cost/revenue estimates based on the existing usage data and be used to evaluate new pricing models.
A full-featured CLI client for the forecasting engine was also created to make using the new functionality more intuitive.
Looking into a possible post-cloud world, we see mentions of different computing paradigms, many of them based on decentralised structures to overcome scalability and user control limitations. Among them is blockchain-as-a-service (BCaaS or BaaS), mimicking the platform-as-a-service (PaaS) user experience for both application providers and consumers. In PaaS, providers first sign up and subscribe to the platform, then design and build their applications and deploy them to the platform where it is executing either permanently or upon incoming network requests or other event triggers. Additionally, developers may advertise their apps at technology-specific hubs such as AWS SAR or Helm Hub. Consumers then adhere to the application terms, which might require a sign-up at the provider site, before being able to invoke and make use of the application.
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.