Cloud Infrastructure and Platform as-a-service (IAAS / PAAS) at Cersat

Why using IAAS / PAAS at Cersat ?

Infrastructure and Platform as a Service (IAAS, PAAS) are useful feature for a satellite data center like the Cersat : providing a multi-OS environment following projects requirements allows a lot of flexibility compared to constraining projects to use existing environments or deploy specific hardware environments for unique usages.

For example, for many ESA (European Space Agency) reprocessing campaigns, we have to integrate Processor executables to perform bulk processings. These executables can run on ten years old OS as well as recent OS for new Processor generations.

Being able to mutate our platform dynamically is a great benefit, and we can also take advantages from one big shared platform instead of several dedicated smaller ones. This is why we investigate IAAS and PAAS ways.

Using (private) IAAS

In order to automatically provision Virtual Machines (prepared for processing purposes), we deployed open-sources solutions to manage our own private Cloud :

• Eucalyptus (may 2011): Good feedback, we quickly had a working IAAS environment and could validate the proof-of-concept. Management was simple et administration tools efficient. But after a few months, we changed for OpenStack (forked from Eucalyptus), since it looked more promising to us.

• OpenStack (april 2012): Promising, but not mature enough... We spend a lot of time with many issues : reliability, complexity, performances etc... Even after several new versions, it was complicated to have an operationnal platform. Read more about this in OpenStack at Cersat

Main conclusion was that idea was sexy, but implementation too much complicated and not well suited to our "cluster on demand" processing needs. We then started to think about a basic Platform-as-a-service design, to cope with our needs.

Using (private) PAAS

Main idea driving this switch to PAAS instead of IAAS is that we don't need to instanciate clusters of virtual machines, but rather some "chroot-ed environment" where to run some executables. Moreover relying on baremetal OS layer avoids network and performances issues encountered with OpenStack and VM.

• Homemade "chroot-on-steroids"

• Docker : still at the stage of early development on the platform, we expect to switch soon on this solution instead of our "homemade chroot"

TODO : développer les raisons ? + article sur le chroot on steroids ?