Why PaaS Should Move Beyond the ‘Twelve-Factor App’

By Atos Apprenda Support


Inspired by Martin Fowler’s writings on application architectures and poor application development practices, a group of Heroku developers wrote a template for developing modern web apps called “The Twelve-Factor App.” This methodology suggests 12 best practices that modern apps should follow during development to make them easy to design and run as “as a service.”

As CEO and co-founder of a PaaS startup, I’m fully behind the ideas described in The Twelve-Factor App. It provides practical guidance for building elegantly decoupled, scalable, and easy-to-deploy applications. It’s a recipe for building applications that are cloud and PaaS compatible. What’s not to love? In fact, if all apps were built adhering to the principles in The Twelve-Factor App, the development world would be a much better place.

Unfortunately, that’s not the world we live in. Within the walls of the average enterprise—each home to thousands of applications built by thousands of different developers—architecture variance from the Twelve-Factor App approach is wide. These existing applications shouldn’t be ignored despite their architecture inferiority: they are the applications that power today’s world.

Developers have used many lackluster patterns in .NET and Java applications during the past 15 to 20 years. Some applications are server-side HTTP apps that are monolithic, while others might be componentized only to find a stray non-HTTP daemon sprinkled into the fabric that defines the logic of a distributed app. Still others cram large chunks of the application logic into the stored procedures of a relational database. None of this is Twelve-Factor friendly, but this is what we must deal with each day.

PaaS in the enterprise cannot thrive if it doesn’t account for the footprint of existing, non-Twelve-Factor apps. Although PaaS can’t help all custom applications, PaaS vendors need to invest in R&D that helps enterprises run as much of the existing app portfolio as possible. Any PaaS that says it’s “just for new apps” needs a reality check. Enterprises are under pressure to deliver cloud, cost savings, additional value across the existing application portfolio and advanced capabilities to boost developer productivity. It’s impossible for a PaaS project to be successful in the enterprise if it focuses only on new application patterns.

PaaS needs to go beyond the Twelve-Factor app. Although it will be challenging for R&D teams, it is 100% possible for PaaS services to take non-Twelve Factor apps as input and inject cloud characteristics into their not-so-clean architectures, giving enterprises the ability to run non-cloud apps on their hybrid clouds for even the ugliest of application patterns.

The Twelve-Factor approach should be the baseline for modern application development: the “native PaaS architecture” for full-value fidelity, if you will. But supporting wide-architecture variance and giving non-Twelve Factor apps new life in the hybrid cloud—even if it isn’t the full value that a PaaS can offer—is the only option enterprises should entertain. It’s the only approach to achieving real ROI in a meaningful time frame.


Atos Apprenda Support

View Comments
  1. Mike ColsonNovember 19, 2014

    My comment is more of a question I suppose, the monolithic applications that you are referencing typically aren’t designed as micro-services. But isn’t the industry accounting for those in the ITaaS or SaaS marketplace? Why should PaaS play there as it’s more of an iterative release cycle vs the traditional “Enterprise” applications? The support structure behind those monoliths are more likely vendor controlled vs homegrown and the dev cycles to recreate a mail service would far outweigh the time to value wouldn’t they?

  2. Sinclair SchullerNovember 19, 2014

    I think whenever possible, leveraging a PaaS provides more value to an app than IaaS. Yes, IaaS *can* account for anything that isn’t twelve factor, but that doesn’t mean it should. Ultimately, IaaS is a bit of a catch all, but with some engineering inginuity, a PaaS can support more monolothic apps and provide some cloud basics like availability, elasticity, deployment, and authentication. If PaaS can do that for a broader set of applications, the question is really “why not?”

    Now, I don’t think PaaS is a good home for Commercial Off the Shelf Software (COTS) like existing mail systems, so I agree with you on that. But there are lots of monolothic, SOA, and hybrid architected custom apps that can work on PaaS. That’s what I’m focused on in this blog entry.

Comments are closed.