We are happy to announce the public release of the first open source Ceph object storage service broker that is compliant with the Open Service Broker API V2, now available on GitHub.
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.
At ICCLab, we have recently updated the Openstack OVA onboarding tool to include an exporting functionality that can help operators migrate and checkpoint individual VMs. Furthermore, researchers can now export VMs to their local environments, even use them offline, and at any time bring them back to the cloud using the same tool.
The OpenStack OVA onboarding tool automatically transforms selected virtual machines into downloadable VMDK images. Virtual machines and their metadata are fetched from OpenStack’s Nova service, and made packed as OVA file. The tool offers a GUI integration with OpenStack’s Horizon Dashboard, but can be also deployed separately.
ICCLab is announcing an integration of the Openstack OVA onboarding tool into OpenStack’s Horizon dashboard. To deploy the OVA file to Openstack all images are extracted from the file and uploaded to the Openstack cluster, all necessary file format transformations are automatically performed, glance images get created and the tool creates a heat stack out of them. As we mentioned a couple of weeks ago, uploading your local VMs into OpenStack was never easier.
Cloud Platforms allow development teams to bring application to production very fast.
In Cloud Foundry a simple ‘cf push’ can be used to deploy your application and bind it to the required services. This works incredibly well for small applications. But as the trend in Cloud Native Applications is going towards microservice architectures, which easily can grow to a large number of decoupled components, it is hard to keep the overview of all the applications and dependencies. It also can get cumbersome and expensive to maintain the deployment scripts and configuration of the applications and very often deployments will get slow and unreliable.
When dorma+kaba was developing exivo, their new trusted, on-demand access control solution for small enterprises, they where exactly facing these challenges, because they had to run and maintain more than 70 apps and 60 services on the Swisscom Application Cloud. Continue reading
We are proud to announce that the ICCLab has released Hurtle!
What is hurtle?
With Hurtle, you automate the life-cycle management of any number of service instances in the cloud, from deployment of resources all the way to configuration and runtime management (e.g., scaling) of each instance. Our motivation is that software vendors often face questions such as “How can I easily provision and manage new instances of the service I offer for each new customer?”, this is what Hurtle aims to solve.
In short, Hurtle lets you:
offer your software as a service i.e. “hurtle it!”
In Hurtle terms, a service represents an abstract functionality that, in order to be performed, requires a set of resources, such as virtual machines or storage volumes, and an orchestrator which describes what has to be done at each step of a service lifecycle.
A “service instance” is the concrete instantiation of a service functionality with its associated set of concrete resources and service endpoints.
On top of this, Hurtle has been designed since its inception to support service composition, so that you can design complex services by (recursively!) composing simple ones.
Hurtle’s functionality revolves around the idea of services as distributed systems composed of multiple sub-applications, so the services offered are also ones that can be designed with the cloud in mind, based on the cloud-native application research of the ICCLab.
What does it mean to offer software as a service?
A bit of history first. Traditionally software has been ran locally, then was centralised and shared through intra-nets. All of this was still on company-specific infrastructure. This made hosting, provisioning and managing such software difficult and the full time job of many IT engineers and system administrators.
This quickly brought about the argument that IT in a SME or an enterprise was a cost centre that should be minimised and lead to outsourcing of such tasks to 3rd parties.
Now today with the ever growing acceptance and use of cloud computing the cost equation is again further reduced, but more interestingly, cloud computing reverses the trend of outsourcing operations to third parties if you consider the movement of devops.
In this new world organisations that create software don’t want nor need third parties to manage their software deployments. They have much of the tooling needed, developed in-house. If they don’t, yet still want to follow a devops approach they’ve quite an amount of work ahead of them.
It is in this scenario where hurtle can help!
What can hurtle do?
- Complete orchestration of your software
- Resources it uses (e.g. virtual machines, networks)
- External services it needs
- Multi-dc/multi-region support
- including inter-DC connectivity
- Easy implementation of your service API – See how to write your Hurtle Service
- Guided implementation of your service instance manager
- Many languages supported including Python, Java, Perl, PHP
- Demo applications available
- Scalable runtime management
- Complete end-to-end logging of your software
- Integration with OpenStack, ICCLab’s Joyent SDC contribs
- Handle potential incidents of your software
- Integration with ICCLab’s Watchtower (Cloud Incident Management)
- Bill for your software and services
- Integration with ICCLab’s Cyclops (Rating, charging & Billing)
- Leverages Open Cloud Standards (OCCI, OpenStack)
What will hurtle do?
- More examples including the cloud native Zurmo implementation from ICCLab
- Enhanced workload placement, dynamic policy-based
- Support for docker-registry deployed containers
- Runtime updates to service and resource topologies
- CI and CD support
- safe monitored dynamic service updates
- TOSCA support
- Support for VMware and CloudStack
- User interface to visualise resource and services relationships
- Additional external service endpoint protocol support
Want to know more?
Today the ICCLab introduces a new way on how to interact with your notes.
What is powdernote?
Powdernote is a note-taking, cloud-based application for the terminal.
Because we never leave the terminal, not even to read our notes or create new ones.
This tool is for busy engineers, developers, power users, devops, …
Our target is to have an un-cluttered, distraction-free application to solve the simple task of taking notes and having them available everywhere (storage is on the cloud)!
- Create, edit, delete, print, tag notes
- Search content
- Browse versions of notes
- Export/import to/from powdernote files
“The autoscaling cloud monitoring system that requires no manual reconfiguration”
“Nagios OS autoconfigurator” (N_O_conf) is a cloud monitoring system that automatically adapts its monitoring behavior to the current user-initiated VM infrastructure. N_O_conf works by installing a cloud environment change listener daemon which is repeatedly polling the OpenStack API for changes in the VM infrastructure. As soon as a VM destruction is detected, it initiates a reconfiguration of the Nagios monitoring server. Nagios OS autoconfigurator can be installed on top of every OpenStack-based cloud environment without interfering with the cloud providers infrastructure, because it can be installed inside virtual machines so cloud consumers can use it as their own monitoring system. N_O_conf monitoring system monitors all VMs that are owned by the user that installed it.
“Measure and benchmark reliability of your OpenStack virtual machines.”
“VM Reliability Tester” is a software that tests performance and reliability of virtual machines that are hosted in an OpenStack cloud platform. It evaluates the failure rate of VMs by performing a stress test on them. VM Reliability Tester installs OpenStack virtual machines, uploads a test program to them, runs this test program remotely and then captures program execution times to determine reliability of the virtual machines. If the test program takes a significant amount of time to complete, this is considered to result in a VM failure. Such deviations in execution time are an important benchmark for testing performance and reliability of your OpenStack environment.
Why VM Reliability Tester?
Cloud computing (or to be more precise: virtualization) is providing virtual resources instead of physical ones. The performance of virtual resources is hidden from the user, because virtual resources are abstracting form the physical hardware layer. As a system administrator you still might want to know how your virtual machines react under heavy load and you want true performance measurements – instead of promises by your cloud vendor. Therefore it might be an advantage to test the reaction of virtual machines that you have created in your OpenStack cloud and measuring the VM performance before creating a productive infrastructure and deploy productive applications on them. VM Reliability Tester delivers you estimates on how your VM performs when it is running applications. With the data produced by VM Reliability Tester you will be able to:
- Check if your VM is performing well enough to serve your performance requirements.
- Benchmark VM images in terms of application performance.
- Benchmark OpenStack platforms from different vendors.
- Acquire data that helps you to shape SLAs and underpinning contracts.
How does it work?
VM Reliability Tester uses a “master” VM which serves to create test VMs and upload test programs to them. The master VM first configures the test VMs and then runs the uploaded test programs. Test program runs are repeated in a (configurable) batch of several program runs. The test programs executes for the configured number of times on the test VMs and logs execution time of each test program run. After a batch of test program runs has finished, the master VM captures the logged execution times and calculates the mean and standard deviation of execution times in the batch. If a test program run took longer than the batch mean plus 3 standard deviations, it is considered as a failure and logged by the master VM in a file called “f_rates.csv”.
Based on the numbers of batches and test program runs per batch as well as the number of failures, VM Reliability Tester computes a failure rate sample. This sample is then used to predict failure rate estimates in productive VM infrastructures.
Setup and Installation
Prerequisites for installation of VM Reliability Tester are:
- You must have valid OpenStack authentication credentials and provide them in the setup file “openrc.py”.
- You have to provide a private/public keypair for authentication with the VMs that you own. Local path to your public and private key file must be added to a “config.ini” and “remote_config.ini” file.
- You must own a PC or labtop and have Python and some Python libraries installed on top of it.
Installation of the tool is done easily by cloning the Github repository and changing the contents of the files openrc.py, config.ini and remote_config.ini. Once you have cloned VM Reliability Tester repository and performed the configuration file changes, you must only run vm-reliability-tester.py. The script will create some csv files that contain failure rates of the VMs and the possible distributions of the failure rate.
VM Reliability Tester is available on the following Github-Page: