I’ve looked at the historical implications of app servers and what that says for the category of Platform as a Service (PaaS).
What we know is that developers invent new architecture patterns all the time. The invention of new architectures is generally motivated by trying to accomplish more with less. Take multi-tenancy, for example. In its current form, multi-tenancy in the software layer can be attributed to ingenuity of Salesforce.com architects who found a way to efficiently deliver SaaS to a huge customer base.
Typically, developers build apps from the ground up using new architecture patterns. Once they find those patterns to be generally applicable by having to use them more than once, developers then try and find ways to create leverage in future work by capturing the pattern in an abstraction.
Initial abstractions are usually captured as passive libraries or standards. If we think about web applications, one of the first things that happened after developers had to manage sockets and browser HTTP conversations was the creation of libraries to encapsulate some of that logic and the creation of standards like the Common Gateway Interface (CGI). After some time and more demand, developers find that passive libraries just aren’t enough because it requires explicit interaction which dilutes the available leverage.
To fix this, developers build app servers
The ultimate abstraction that can properly inject an architecture pattern into code that isn’t architected with the pattern in it already. For the web app era, it meant that instead of libraries and CGI, we could write Java or .NET code in a way that conforms with certain expectations, run that logic on an application server, and the app server would instrument the architecture into the app.
The use of new architecture patterns is the motivation behind creating a new application servers. The result? Developers who didn’t even know how to deal with browsers and web app architectures could now build apps.
I looked at the history of software and what implications it may have on developers creating future cloud applications.
Historically, app servers have held the role of catalyst in the software space. Each time a new class of application server was introduced in support of a new architecture era, an explosion in application development resulted. There is no mystery as to why: app servers commoditize the complexity and lower the bar for developers by orders of magnitude. Once more apps are built, companies need new ways to manage those applications, so management systems are created as a tactical point solution.
The infographic below captures this across key eras in computing: mainframe, client/server, web apps, SOA, and now, cloud. Our argument is that when it comes to cloud applications, PaaS is the new app server:
Unfortunately, in both public and private cloud models, most PaaS vendors have a very tactical view of PaaS. They have not achieved the realization that the purpose of PaaS is much grander than “deploy and scale.” We have a very different view and are passionate about the idea that history will repeat itself. Every ounce of energy we invest in Apprenda’s R&D is around making it easier for developers to build cloud enabled application architectures. Deploy and scale, and application management are important, but they don’t define us.
We believe that PaaS needs to fill that role of catalyst in cloud and cause an explosion in the number of web scale, distributed, mobile and multi-tenant apps that developers write.
My only issue is that it may be best to start making the case for PaaS as a replacement, not add-on to other IT spend.
No matter what business model a client may be using to bring software to market, the full picture of PaaS in the right form with the right attributes make sense architecturally and more importantly, economically as a software construct and worth the investment.
Simply stated, dynamic scale coupled with controlled isolation and multi-tenancy is a far more economical way to deliver software and by using an openPaaS model you are insuring your software investment by having options as to how you can bring your application to market today or in the future.