Many companies are starting to implement PaaS (platform as a service) solutions. There are obvious benefits such as easy patching, scaling, pay per use, etc. There are also challenges when implementing a PaaS solution. In this post I will describe some of the challenges and provide some suggestions to allow you to enjoy your PaaS solution to the fullest.
The post is based on my presentation of a customer case on the Oracle Cloud day the 6th of October in the Netherlands this year.
This customer had implemented a private PaaS solution and had faced several challenges. In this post I would like to present some of my findings (mainly based on interviews) in order to help customers who are considering a PaaS solution to make a good start with their implementation. The challenges / benefits are valid for private PaaS and public PaaS solutions.
Start with PaaS, then application
Why migrate if you can have it from the start?
Choose your timing for implementing your PaaS solution. When you already have a running project and all environments including production are more or less running ok, who is going to take responsibility for the migration to the PaaS solution? It is better to have your PaaS ready before your project starts (or as start of your project) and require your project to use it. This avoids the responsibility discussion and additional migration cost.
Automation from the start is easier than automation in retrospect
Using PaaS features such as providing new environments, should be done regularly (when it hurts do it more often). For example after every sprint in Scrum to recreate the test environment. This makes sure there is a drive to automate everything from the start. It is a lot harder to determine what has been done to an environment in retrospect and automate that than to start with a clean slate and automate as you go.
Automate configuration
There is a grey area between provisioning and application deployment; namely the application specific environment configuration. For example data sources, JMS queues, etc. It greatly helps if your provisioning software allows you to treat configuration as code, version it and automatically deploy it. MyST is an example of such a tool. This avoids issues like configuration drift.
Image borrowed from http://www.rubiconred.com/eliminating-configuration-drift-for-oracle-soa-and-bpm-projects/
Development has PaaS requirements
Development and operations need to work together on this. The PaaS solution is maintained by operations. Changes to the environment (patches, configuration), whether initiated by operations or development need to be incorporated in the PaaS template to ensure this is propagated to new environments. Developers have requirements. Those requirements should be taken into account by operations when creating or implementing your PaaS solution.
PaaS and Continuous Delivery
Continuous Delivery and PaaS go well together. Automated environment provisioning and an automated release and deployment process of course allow you to quickly get a new environment up and running or to refresh/reinstall an environment from scratch.
Your continuous delivery process needs to make sure that the complete set of software to be deployed on the PaaS solution, is known. This is required to recreate an environment from scratch. There are of course several ways to achieve this. One method is described here.
For a service or a web application this is easy. You can in most cases just deploy the latest version. For database software however, this can be a different story. Usually you have to work with a certain set of tables and data which can not be ‘overridden’ by a new version. There are tools which help you create incremental database releases such as Liquibase. Many customers also create custom scripts to achieve similar functionality. What you shouldn’t do for database software is to try and maintain a complete set of scripts at a separate location from the ‘releases’ and not regularly test these scripts. Developers can (and will) forget to update them. If you can’t trust the scripts, it is no use having them. It helps if your database scripts are rerunnable.
Standards, consistency and few artifact types
Your development standards can take into account that for every type of artifact you want to deploy, automation is required. For example, there are several ways to use properties in J2EE containers. Choose one and be consistent in using it. More consistency makes automation a lot more easy. If every team uses their own property file deployment method / artifact structure, things will get messy. Less types of artifacts require less automation.
For databases, it helps if you deploy through a single user or schema since every schema you want to deploy to, requires several properties (such as host, port, sid, user, password) which need to be configured for every environment.
PaaS often requires specific automation tools
A PaaS solution requires some different methods of automation the operations department in most cases is familiar with. You need unattended installation scripts for example and usually the scripting languages used, differ. If for example the customer uses shell scripts to do automation and the PaaS solution does not give you access to the OS (it is a PaaS solution, not an IaaS solution), you need to rewrite your shell scripts to for example WLST scripts. Tools like Puppet and Chef are regularly used for provisioning. You might need to gain (or hire) some experience with them also.
Don’t repeat past mistakes. Dare to change!
Last but certainly not least, do not make the same mistakes you made with the ‘do-it-yourself’ environments on the PaaS solution. This is a chance to start anew. I suggest you take it, learn from mistakes made in the past and do not repeat them.
