Platform as a Service is so much more than deploying apps

This is a guest post written by Dan Turkenkopf of Apprenda.

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":560027,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"cloud,","session":"A"}']

Platform-as-a-Service, or PaaS, has the opportunity to transform application development as we know it. Yet a piece in VentureBeat earlier this month did little to expand the definition of PaaS beyond deploying apps.

Focusing just on application deployment delivers an incomplete value proposition for developers, and very few providers have demonstrated any vision beyond this. The only one who suffers is the customer.

What is PaaS?

The most common definition for platform as a service describes a layer of technology that assists developers in the deployment and scale of their applications. You’ll see those two words, “Deploy” and “Scale,” echoed throughout the marketing of many of the prominent PaaS vendors.

Another familiar refrain you’ll hear with PaaS is, “if you have to touch the operating system, it’s not PaaS.” In other words, if Infrastructure-as-a-Service (IaaS) hides the physical machines, PaaS hides the virtual machines and operating systems. So one of the values of PaaS is eliminating the need for the application owner to maintain the underlying operating environment.

But remember, PaaS is supposed to cater to developers.

Removing some of the deployment headaches is certainly valuable to the application developer, and should be seen as the minimum bar a PaaS solution must clear. Smoothing those difficulties is going to make life easier.

How much easier are we really talking about, though? Are the application delivery concerns truly where developers spend most of their time and effort?

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":560027,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"cloud,","session":"A"}']

A brief history of developer productivity

Let’s take a slight detour to explore the ever-improving life of the developer. Since the first cards were punched, there’s been an inexorable march toward allowing programmers to focus on solving the business problems at hand.

Eric Knipp, a vice president at Gartner, drives home the importance of productivity.

While today, we often consider syntactic sugar a meaningful advantage, historically the biggest gains have come from removing whole areas from the concern of the coder. For example, when Java and C# popularized automatic memory management, developers could stop figuring out how much space to allocate and instead figure out how to add that cool new shopping cart feature (hey, it was the 90s). Similarly, the application server handled the heavy lifting of component location, brokering database connections, etc.

[aditude-amp id="medium2" targeting='{"env":"staging","page_type":"article","post_id":560027,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"cloud,","session":"A"}']

The cloud is a different place

Developing for the cloud is not an entirely new experience. The transition is almost certainly less traumatic than moving from client/server to the Web. But it’s not totally seamless either.

The change that gets the most coverage, because it’s the sexiest, is the need to run at quote-unquote “Web scale.” Supporting huge numbers of concurrent requests across a highly distributed environment creates too many challenges to even list. Companies like Amazon, eBay, Netflix and Etsy all have tremendous success in this space and their stories are the current chronicles of the cloud.

But most applications don’t have to worry about that kind of scale. Most application developers are not working at the hot new startup. Most developers are coding within an enterprise. They might be building trading applications at JPMC, or package tracking software at FedEx. And they have a very different set of concerns.

A “cloud” application to these developers means supporting mobile consumers, who may or may not have access at all times. It means mashing up a bunch of REST APIs from SaaS applications. It means poring through and analyzing the huge amounts of data collected by their companies and turning it into actionable information. It means figuring out how to store data for multiple consuming organizations in a cost-effective manner.

[aditude-amp id="medium3" targeting='{"env":"staging","page_type":"article","post_id":560027,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"cloud,","session":"A"}']

These are new concepts; hard concepts. And any time spent on figuring out the plumbing is time that’s not spent on solving the business problem. Sure, you could build it yourself, but why waste effort on difficult, non-strategic activities?

What PaaS should be

Platform as a Service should be the provider of those cloud application architectural patterns. Your platform should serve as the base for your next generation of applications, and should remove the burden of building, maintaining and improving these capabilities from your developers.

After all, don’t they spend a lot more time coding and maintaining their applications than they do deploying and scaling? Can deployment and scaling ever save 18 months of effort and time to market like a platform injecting SaaS-like characteristics can?

Yet, almost no PaaS vendors plan to go that route. If, as James Governor of Redmonk says, “developers are the new kingmakers,” shouldn’t we be giving them the tools they need to be at their creative and productive best?

[aditude-amp id="medium4" targeting='{"env":"staging","page_type":"article","post_id":560027,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"cloud,","session":"A"}']

Dan Turkenkopf is the lead architect for customer solutions at Apprenda, where he is instrumental in enterprise PaaS implementations. Follow Dan on Twitter, @dturkenk, for an equal dose of PaaS vision and baseball rhetoric.

Web services diagram: Shutterstock