It’s often a goal of enterprise software vendors to simplify the lives of their customers. After all, complexity is the source of enormous pain and friction in most enterprise environments. This is a fine goal, but too often, vendors make assumptions that simplify their life and pass complex issues on to the customer. Rather than eliminating the complexity, they simply ignore it.
In the world of enterprise Platform as a Service (PaaS), how the platform handles your application’s database is a good illustration of this point. Most enterprise PaaS solutions conveniently leave the data tier out of scope or simply provide a broker to create a database as part of an app deployment. The database needs to be a first-class citizen throughout the lifecycle of the application because that’s the reality for enterprise developers.
One of the consequences of not supporting the data tier natively is that it makes other features of your PaaS much simpler to implement (at the expense of developers, of course). Two good examples are “blue-green” app upgrades and fault zones.
The goal of “blue-green” app upgrades is to minimize downtime during app upgrades by effectively having the current version of your app and the new version of your app running simultaneously. Once you are ready to have users access the new version, you begin re-routing requests to the new version with the previous version remaining available but idle. You can swap back to the old version quickly if something goes wrong.
The tricky part of course, as any developer will tell you, is that data tier. How do you handle in-flight transactions? How do you synchronize the data and schema between the green and blue versions? Do the versions share a database or do they each have their own copy? Are the versions data-compatible? What happens to the new transactions if you roll back? The answers to these questions influence the deployment strategy and need to be considered as part of the upgrade orchestration.
On the other hand, if you just ignore the data, life is a lot easier as a vendor because all of this complexity is left for the developer to reconcile.
Redirecting to a maintenance page isn’t the hard part of app upgrades; handling the data is. The vast majority of Fortune 500 apps running on Apprenda (and most enterprise apps in general) have a database. This means that unless you handle the data tier, as a practical matter, any update that touches the data will still have downtime and / or complexity.
Fault zones are another popular feature that is significantly impacted by the data tier because of the latency that they threaten to introduce. For example, if a developer deploys multiple copies of an app across multiple data centers or fault zones for redundancy, she will pay a penalty on latency if the database is only in one location. For example, if the database is in data center A and the developer deploys an instance of her app components to data center B, each client request that gets routed to data center B will require the app to roundtrip back to data center A in order to service the request. An enterprise PaaS that doesn’t consider databases is able to be blissfully ignorant of this issue because the data is the customer’s problem to reconcile.
If a private PaaS is truly going to support existing applications and real-world enterprise needs, then it needs to deal with and accept responsibility for application complexity as it exists in the enterprise. The data tier needs to be part of the native application model and not left as “an exercise for the reader.”