As presented in a prior post, Singer.io is a modern, open-source ETL (Extract, Transform and Load) framework for integrating data from various sources, including online datasets and services, with a focus on being simple and light-weight. The basics of the framework were explored in our last post on the topic, so we will refer you to that if you are unfamiliar.
This post is about our process for deploying Singer to the cloud, more specifically, to the Cloud Foundry open source cloud application platform. This was done in the context of researching the maturity of data transformation tools in a cloud-native environment. We will explore the options for deploying Singer taps and targets to a cloud provider and discuss our implementation and deployment process in detail.
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.
From September 15 to 20, TU Dresden’s GRK 1907 hosted the summer-school on “Development, Deployment, and Runtime of Context-Aware Software Systems”, with 3 days of invited talks and discussion among professors, students and experts in the field at the world-renown Schloss Dagstuhl, followed by 2 days of on-premises hands-on practical sessions. SPLab Team member Panos Gkikopoulos was there to attend and to present a poster of his PhD work based on MAO, though only got to experience the Dagstuhl part due to a busy schedule.
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.
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.
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
Migrating an application from one cloud to another is a challenging activity and one must be mindful of both potential incompatibility and data loss when migrating. It is also, however, often necessary, so a proper way to automate the process and ensure a working deployment on the other end is certain to be a handy tool to an administrator. Since we have been working with multi and cross cloud environments and application portability (see paper and blog), we present a tool to automate this process for Openshift.
As far as use cases for migration go, the easiest example to visualize is moving an application from the development environment to production. Minishift, the single node local development version of Openshift is a great way to develop and test a new application, isolated from the risks and expenses of exposing it to the outside world. But at some point, this application will need to be recreated on a production Openshift instance and while doing this ‘traditionally’ is easy for small applications, it can become cumbersome for larger cases, especially if parts of it were configured using the graphical dashboard.