Application Deployment in IaaS & PaaS
The cloud industry is moving quickly from IaaS to PaaS, and then to iPaaS and SaaS. The motivation is to manage complicated distributed applications efficiently with less manual intervention during installation and maintenance.
The PaaS paradigm assumes a more or less uniform IaaS substrate (tools like JClouds help in this direction) and delivers service containers. Similarly SaaS is deployed on a combination of PaaS & IaaS.
There’s one common pattern in these: configuration starts from the top moving downwards. This means that the deployment of a cloud application becomes a multi-step operation any stage of which might fail causing the installation process to perform an equally complicated multi-step rollback at best or leave the system in an inconsistent state. Furthermore a top-level setup requires that the complete installation configuration is encoded into the entity performing the installation. Once deployed, the system remains sensible to changes in the service topology.
In this setup, dynamic reconfiguration becomes a requirement that is most often built into the application, rather than a reusable deployment aspect.
A decentralized approach to cloud application deployment
So what if the installation and maintenance of a cloud application becomes a decentralized process?
Here’s a simple case:
An application that needs access to an RDBMS will have to be configured with the access details to an RDBMS service (standalone or cloud-based).
The decentralized version of the above will have the application publish its requirement for an RDBMS service when it starts. In the case of IaaS, one or more containers (VMs or Docker containers) will react to the requirement by configuring themselves as RDBMS nodes collectively offering the required service. The offered service will be published to the interested parties which will bind to it. In the case of PaaS, a cloud-based RDBMS may provision a new database and configure authentication prior to publishing its availability.
Here’s a more involved case:
Fabric8 is an impressive software project that enables deploying multiple application containers (mainly OSGi containers, but more are on the way) which collectively provide a service. Using this approach it can e.g. provide a highly available message broker whose availability characteristics are configured centrally (the number of master and failover brokers, the supported messaging protocols, etc.).
The “inverse” version of Fabric8 would publish the requirement for a messaging service with specific high-availability (HA) characteristics. One or more containers would react to the requirement by self-configuring themselves and then connecting to each other to provide the expected level of HA. The containers could be plain VMs or preconfigured identically with a standard version of the software that will most likely be requested. E.g. in this case, spawning a few VMs from a CentOS image that has Apache Karaf would speedup the process of setting up the broker cluster.
The ideas around software autonomy and self-organizing systems are not new. However the current wealth of tools and cloud providers render this an exciting opportunity rather than a futuristic possibility.
Technologies such as Docker, Zookeeper, distributed OSGi and Mesos allow us to reason in such high-level terms.