Continuous Delivery and Platform-as-a-Service: A World of PaaSibilities
So called "continuous integration" (CI) was originally born of extreme programming as developers sought a way to merge code into the mainline and overcome integration conflicts. Regular check-ins, automated unit testing and build automation enabled developers to find and fix problems earlier in development, and deliver software more quickly.
CI is a best practice of agile development, which is the prevailing methodology today. However, there has been a renewed push in recent years to speed up software delivery even more by extending CI through to continuous delivery (CD). Dictating the need for continuous delivery is both the explosive rise of mobile applications plus the pressure to quickly deliver new features into live software, such as Software-as-a-Service (SaaS) applications. Fold in automated acceptance and user testing, and it’s possible to build, fix and enhance software rapidly and reliably. But how can you speed up deployment and quickly deliver applications into production – that is, how do you achieve CD?
A natural step to accelerate CD processes is to take advantage of cloud services, such as Platform-as-a-Service (PaaS). PaaS provides a rich set of development and deployment services that developers can tap, as needed, for projects of any size. By freeing developers from the IT maintenance chores they traditionally end up owning – installing and provisioning hardware, software upgrades, tool implementation, patches, middleware updates – they are able to focus completely on development. Imagine how much more productive a development team can be, if all of the infrastructure maintenance is abstracted away, they have instant access to all of the resources they need, and only had to pay for services they actually use!
Not ready for PaaS? A lot of people start with Infrastructure-as-a-Service (IaaS), thinking it will solve many of the maintenance and productivity issues. Let’s find out why that isn’t true.
From IaaS to PaaS
The adoption of IaaS has been booming. Many companies initially thought that by moving infrastructure to the cloud, they would shed the maintenance duties that go along with on-premise data centers. Instead, what they have quickly realized is that they are simply replicating remotely what they’ve done on-premise all along. Not only do most of the former infrastructure maintenance chores remain, but now IT personnel also need some fairly deep experience with cloud technologies. True, you only pay for the infrastructure capacity that you need, but cloud services can offer so much more than just infrastructure.
Just as continuous integration (CI) gives way to CD, so IaaS naturally leads to PaaS. This is echoed by IDC’s predictions for 2014 which include the assertion that value will start to migrate “up the stack” from IaaS to PaaS.
Let’s now turn our focus to PaaS and talk about what can and can’t be done with CI and CD on PaaS.
Falling Into the Trap of Shadow IT
There are many flavors of PaaS available. Some are used for deployment only. Some utilize public cloud and some are installed more like packaged software, on-premise, in a private cloud. To truly offer maximum productivity and cost efficiencies, PaaS should be able to support the entire application lifecycle (build, test, deploy to production) with a mix of cloud and/or on-premise resources, or hybrid cloud. With full-lifecycle PaaS support in the public cloud, your developers no longer have to spend time building, maintaining and monitoring the stack that your application is based on. They are free to work on software delivery, where they add the most value. You can also cut through the bureaucracy, negotiation and wasted time required to secure IT resources, which paves the way for greater innovation. What we are talking about here, is removing barriers and distractions so that your engineering team can focus on developing truly great applications.
The simple truth is that the appetite to adopt CI and CD is so strong right now that many developers are falling into the trap of serving as “shadow IT” and trying to do it all. With PaaS, they don’t need to. The burden of setting up CI and CD environments, maintaining hardware and overseeing migrations is no longer on the shoulders of the IT department or the developers themselves.
For start-ups with no legacy systems, PaaS is a logical choice and the value is obvious. True agility and faster innovation is enabled by CI, CD and PaaS.
Limitations kick in when we look at the existing enterprise. Organizations may have legacy hardware that requires specific drivers to run, or perhaps there’s a unique network topology or legacy software deployed within an application server that can’t operate in a managed PaaS environment. Implementing CD through on-premise automation will still be beneficial, but just because you can’t fully adopt PaaS doesn’t mean that you should discard it. PaaS is still a viable option and organizations have started to incorporate it into existing IT architectures where it delivers value. There are plenty of ways to utilize PaaS amongst your existing on-premise systems to enable CD. Many innovative enterprises are realizing they can evolve to push some workloads to the cloud, while keeping others on-premise. PaaS and the cloud do not have to be mutually exclusive.
Take an Evolutionary Approach to Tapping PaaS
Think of PaaS as an a la carte prospect. It is rapidly evolving to become modular, offer complete application frameworks and support many development languages. There is a range of capabilities that PaaS provides – from initial CI all the way through to a comprehensive continuous delivery process complete with infrastructure elasticity and transparent deployments of new functionality into production.
It’s important to remember that it’s not an all-or-nothing proposition. In fact it’s best to avoid a high-risk, “big bang” approach to implementing PaaS. If you pick the most complex use case, one perhaps with political ramifications, and embed all the specific exceptions that you can find (in order to get a rock-solid proof of concept), then you’re setting yourself up to fail.Take baby steps towards CD and PaaS and show what can be done with a small project, first. Get a feel for the ease with which development and deployment can be done allowing you to get buy-in on that initial success.
By working through something less ambitious you can also begin to create some awareness of the processes involved and build bridges between team members. In larger companies, where resistance to change can be strong, this kind of cautious approach is far more likely to succeed and consequently create a positive perception that resonates with the right people.
The IBM study,Exploring the frontiers of cloud computing: Insights from Platform-as-a-Service pioneers, shows predictable improvements in efficiency and resiliency, but also shows how PaaS can impact positively on data management and leveraging human expertise. As the report points out, “PaaS can make the company more nimble and cost-effective, with consistent performance and faster roll-outs.”
Evolving From CI to CD, and From IaaS to PaaS
We have a tendency to oppose change. Duality obviously appeals to humanity, but conflict is often manufactured. A narrative that seeks to pitch CI versus CD, IaaS versus PaaS or the private versus the public cloud is disingenuous. The lines between these approaches and solutions are blurring. You don’t have to choose one or the other to make huge gains.
In the real world, we are seeing CI grow into CD, IaaS paving the way for PaaS and dramatic growth for the hybrid cloud. At the heart of it all is a desire to streamline and accelerate - but that’s a mindset and an ongoing process, not an endpoint, in itself. If you’ve started on the path with CI or IaaS, then you can already see the potential value of CD and PaaS. Finding exactly the right blend of services is a unique challenge for every business and it will evolve over time, but the tremendous rewards justify the initial effort.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)