MultiPaaS: three simple steps for your application

Dominique Clairac, Leader at onepoint’s South-West community and an OpenShift certified expert, helps companies to digitalize business processes and implement their DevOps strategies. He is also behind the idea of MultiPaaS, and in this article he explains what this project is all about.

How did you come up with the idea for MutliPaaS ?

We have been working with RedHat for several years now in order to implement OpenShift platforms for our common clients. Throughout this time, we have understood the importance of change management, since these platforms represent a dramatic break from traditional approaches to development, deployment, and even project management.

Many companies believe that they will achieve DevOps through technology, and subsequently end up with a continuous delivery platform that doesn’t actually meet their needs. For instance, we noticed that companies that deployed a container orchestration platform such as OpenShift or Kubernetes, but didn’t deal with it as part of a larger transformation program, often found themselves with a largely underused and technically complex tool. We wanted to avoid this by offering a simple way to use such platforms efficiently while taking into account the challenges posed by hybrid cloud.

We set out to create a demonstrator to find out the most adequate architecture to meet the existing needs and identify technical challenges. From the beginning, we decided to take into account the fact that the development and deployment chain would be spread across several platforms, regardless of their location (cloud, on premise, etc.). A native feature of containers is that they are easy to move from one platform to another as long as they don’t contain any data, and this opens new possibilities for companies that choose to evolve towards this deployment mode.

While we were developing the demonstrator, we realized that businesses could also use our solution for other purposes, for example to harmonize outsourced developments with those done in-house and automate their delivery. The demonstrator was first showcased at the Paris RedHat Forum in 2017, then at the Cloud Expo Europe. We received very positive feedback and several clients asked us to help them implement a similar tool in their IS. However, there’s some distance between a demonstrator and a reliable application, so in 2018 we decided to bridge the gap. We took some time to correctly identify, understand, and prioritize our clients’ expectations before setting up a project team and heading off on the adventure.

Could you explain how the application works ?

With MultiPaaS, you can create development chains easily and quickly, including the environments and tools required for developing, testing and releasing applications.

You can think of MultiPaaS as a service catalog intended for project managers. But, where typical catalogs would enable to deploy a container, MultiPaas generates all the environments needed to go from the idea through to the deployment of the application without having to tackle technical and repetitive tasks, like creating all the items, managing rights, or configuring triggers at all.

Only three steps are required to create a new project:

1. The user chooses the project’s quickstart and enters basic details (project name, description, etc.). A quickstart corresponds to a sample source code, like “hello world”, that respects the company’s rules and good practices. It’s enriched with metadata that indicate the build and deployment modalities on the target platform.
2. The user selects a workflow for deployment. A workflow is a template containing the different environments that need to be created (Dev, QA, Pre-Production, Production), the order in which they appear, and the rules that determine when to pass from one environment to another. Workflows can be customized, and it’s also possible to select a blank workflow to make it up from scratch.
3. The user can then choose the PaaS platform for each environment in the selected workflow. A PaaS platform is an OpenShift platform, wherever it’s hosted (on premise, hybrid cloud, web host…).

The application will generate the different environments in the selected PaaS platforms and prepare the GitHub repository using the sample code in the quickstart. The build function – creation of an image from the source code – is also integrated, and it’s linked to specific operations, such as a change in the source code.

In only a few minutes, both the environments and the whole machinery required for development are set up and delivered to developers. A change in the source code is enough to trigger a build and deploy it in the new environment. Then the application will be able to move from one environment to the following until production, regardless of the environment’s location (on the cloud or not).

The key point? The software factory is fully set up in a few minutes instead of several days, which is often the case so far.

What happens if the MultiPaaS service goes down ?

We need to keep in mind here that MultiPaaS doesn’t host projects or applications: we only use the APIs proposed by OpenShift and GitHub to automate all the technical and tedious tasks required to create and set up a project. Once the machinery is in place, the project is hosted on the OpenShift platforms on which it has been deployed and the code is stored in GitHub. If MultiPaas happened to be down, it wouldn’t have any impact on either the developments or the production environment.

In this scenario, only the possibility of generating new projects via MultiPaaS would be blocked, but even then it would be possible to go through the different steps manually. This would just take longer and require a technician having sound knowledge of OpenShift.

Who are your partners ?

We’ve been partners with RedHat for nearly a decade and have been implementing OpenShift platforms with them for several years now. We have a strong confidence in the product and its capabilities, which go well beyond those of a simple container orchestration platform.

Although our partnership with GitHub is more recent, they have already proved almost everything regarding their capacity to store Git repositories. Installing the on premise version is really easy, and running it it’s even easier. GitHub also offers a number of powerful tools that we’re not currently using in MultiPaaS, but that can be really interesting to manage developments beyond our application.

Summing up, we have chosen to rely on recognized players in the market.

What are the next steps ?

After the demonstrator, we took some time to reflect on what we had done and, above all, to understand what it was that our clients found interesting in our demonstrator. We also turned to our service center in order to identify project expectations regarding fast generation of development environments.

Then we launched the project on our incubation platform, Pier 39, and developments began. We opted for an MVP[1] approach because it allowed us to obtain presentable results quickly, and we have just reached the first level of viability of the application. We are working to implement it at onepoint’s South-West service center (Bordeaux/Toulouse) to use it on qualified pilot projects. We are also looking for clients that would like to participate in this pilot phase. Our goal is to collect feedback from them in order to add new items to our current list of improvements and then work together to prioritize new functional features.

[1] MVP: Minimum Viable Product – Development technique that gives top priority to the features that are essential to the operation of the product in order to reduce time-to-market. Improvements are then added on an ad hoc basis.