Newer PaaS and cloud-ready NoSQL options are making PaaS a particularly cost effective option for dev, test, and staging, with room to grow on the production side.
Maintaining and even funding an adequate dev, test, stage, and production environment or a reasonable subset requires lots of resources and discipline. A lack of resources in particular has often put developers in a bind. Even if you can afford to have a cluster of 128-core boxes for production, you may not have (or be willing) to find the funds for an environment that is used only once per quarter or however frequently you issue your releases.
IaaS (infrastructure as a service) changes this equation. With IaaS in the public cloud, you can "fund" a scaled-out environment for a day or two of load and QA testing before each release. In larger companies, the cost advantage tips toward private cloud IaaS because you can share the hardware among multiple groups so long as their releases are not scheduled at the same time.
Moving up the stack to PaaS (platform as a service) offers additional advantages. In very traditional shops, you have all developers hitting a shared dev environment, and near the end of the project, they deploy to an integration environment. With agile development, most of the time each developer has his or her own environment, and integration is done continuously through Jenkins or a similar tool. For staging and testing, there is still a resource contention problem. This isn't the case if the environments can be created on the fly completely and in parallel, in true PaaS style.
Recently, while working with a client on an unrelated issue, we devoted a significant amount of time to discussing and waiting for an RDBMS with a divergent schema to be provisioned. This had to be paired with a complete environment, including the application server. While everything was virtualized, provisioning wasn't even automated with Puppet. I calculated the costs in my head, including my bill rate, the rate of a number of involved consultants, and the estimated per-hour rate for their internal staff. Based on this issue alone, I was able to mentally fund a small commodity server farm running Cloud Foundry or OpenShift.
Finally, PaaS has a major benefit for production deployment: Even with dev, test, stage, and preproduction, small differences between stage/preproduction and production tend to cause big outages. What if there isn't production or preproduction, but the software is deployed and fully tested, and the new version becomes the "active" version when it's time? Meaning: What if you just swap a DNS entry and preproduction becomes production? With newer, cloudy, NoSQL-ish databases, it may even be possible to replicate and migrate more seamlessly. Marking staging "production" doesn't have to involve much -- if any -- outage.
Red Hat and other vendors are looking to this future. I spoke with Ashesh Badani, general manager for Red Hat's OpenShift, who had this to say:
Development and testing is a requirement in the public data center and public cloud. Often, large enterprises find it easier to leverage the cloud as a preproduction environment than to set up internal infrastructure. OpenShift's strategy of using a common code base for both public and private clouds means enterprises can take advantage of a quicker turn thru dev/test stage and chose the environment that is most attuned to their business security and governance requirements.
Not everyone is going to a new, more agile future, Ashesh adds:
Public PaaS offerings such as OpenShift Online do offer the ability to quickly move directly from development to production with the push of a button. However, we are also seeing our enterprise customers implementing our OpenShift Enterprise private PaaS in a more traditional multi-environment manner with traditional checkpoints used to validate applications before pushing to production. The nice thing about PaaS is that it provides the flexibility to support multiple different operational models.
I'm frequently asked about enterprise adoption of "the cloud." Despite the silly conflation of multiple cloud varieties in that question, I usually answer something like: "They will. They have to."
The greatest percentage of downtime has long been held by planned outages for upgrades and deployments. As computing has become nearly ubiquitous and business has globalized, the window for acceptable planned downtime is shrinking even for brick-and-mortar shops. PaaS -- especially but not exclusively with NoSQL technologies like Couchbase and MongoDB -- is our best chance to change this. When we scale seamlessly in the cloud without long deployment windows, things can only get better.
This article, "Why PaaS? Dev, test, staging, no waiting," was originally published atInfoWorld.com. Keep up on the latest developments in application development and read more of Andrew Oliver's Strategic Developer blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.
This story, "Why PaaS? Dev, test, staging, no waiting" was originally published by InfoWorld.