The Seven Phases of PaaS
by John Wetherill

John Wetherill, December 19, 2013

Being a Developer Evangelist has many perks, my favorite of which by far is that I get to talk to tons of developers. Obviously PaaS (Platform-as-a-Service) is frequently a topic of conversation, and I've noticed an interesting trend among a surprising number of companies that have invested to some degree in cloud computing.

I call this trend "The Seven Phases of PaaS" and it goes something like this:


Phase I:  Agony

This phase, which can also be called "Misery" or "Pain" or "Extreme Suffering," can last for years, decades even, and is a direct result of the countless barriers that confront software developers when all they're trying to do is deliver great software.


Phase II: Discovery

The Discovery Phase frequently comes in the form of two blinding flashes of insight:

1. Wow! This PaaS thing solves so many problems and offers such incredible increases in productivity and overall success, how could we not use it?

2. Wow! We've been building PaaS-like components for years, and we’re really good at it!


Phase III: Desire

The Desire Phase kicks in now that the team understands the magnitude of savings that PaaS offers. This stage involves much research on the overall PaaS ecosystem, evaluation of existing PaaS offerings, interactions with other developers who are using PaaS, and often includes the creation of a proof of concept to demonstrate that the team is perfectly capable of building a PaaS in-house.


Phase IV: Resistance

The team approaches Management and presents the PaaS story, showing the POCs, and suggesting they should invest in building up their own PaaS; it's well worth the effort, and besides, they've been building PaaS-like functionality for years: all they need to do is glue everything together and they'll have a powerful PaaS that's customized to their specific needs. Management, of course, resists (that's their job isn't it?).


Phase V: Construction

Finally management acquiesces and allows the team to build their PaaS, providing that doing so doesn't interfere with their regular product development efforts. The team dives in with unbridled enthusiasm and starts building their own PaaS. Using existing public PaaS's as a baseline, they're able to design a powerful and custom PaaS that they can use on-site. Life is grand, and the future looks wonderful.

Over the next months, Management asks how things are progressing with their work. They're not asking about the PaaS, they're asking about progress on their core product, their bread-and-butter. The response is a variation of: We're making incredible progress on the PaaS, about 80% there, and once it's ready we'll be able to build apps so fast that we'll be essentially printing money. After hearing the same answer, and realizing that the remaining 20% of building a PaaS is in fact the hard part, Management finally has enough.

Phase VI: Abandonment

Management steps in and puts an end to this massive job of building a PaaS at the expense of their regular product efforts. The in-house PaaS project is terminated, to the chagrin of the developers working on it. Meanwhile the power of PaaS has made itself known to management and engineering alike, and now it's even more clear that the company's development prowess will be strengthened by using a PaaS.

Phase VII: Procurement... and Success

More research is done, PaaS vendors are identified, and finally an investment is made in a commercial-quality PaaS that, while not customized to the degree their in-house PaaS would have been, is enterprise-proof, reliable, supported, and importantly, available now. The company incorporates this PaaS into their workflow, with all engineers (dev, qa, deployment, test/release) having access to a unified, robust, secure, scalable environment to deploy their applications. Now life truly is grand, and development is able to flourish with many of the previous barriers completely eliminated.



It's surprising how often I see this scenario played out, but it makes sense given that PaaS is relatively new, and is clearly making itself known as an important and strategic tool. Also, due to the pain identified in Phase I, lots of effort has already been expended to build out many of the features that PaaS provides.

But PaaS is a complex beast, and building one in-house requires considerable investment. At the end of the day it makes sense to find a reliable PaaS built by a vendor who specializes in such things, freeing your team to focus on what they do best, which is building software for their market.

If you or your company is in a position where you're considering building out your own PaaS to ease your software delivery woes, I urge you to bypass Phases II through VI (you've probably been through Phase I already) and get yourself an enterprise-ready PaaS to greatly streamline your development efforts.

Subscribe to ActiveState Blogs by Email

Share this post:

Category: stackato
About the Author: RSS

John, ActiveState's Technology/PaaS Evangelist, spent much of his career designing and building software at a handful of startups, at Sun Microsystems, NeXT Inc., and in the smart grid and energy space. His biggest passion is for tools, languages, processes, or systems that improve developer productivity and quality of life. He now spends his time immersed in cloud technologies, focusing on PaaS, microservices, and containerization.