Guest View: The pitfalls of platform as a service
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
By David Abramowski
August 1, 2008 —
The news that search and ad revenue monster Google has decided to unfurl yet another tentacle, this time to grab a chunk of the application development platform world, comes as no real surprise.
Platform as a service (PaaS) is an attractive, exciting, rapidly evolving extension of software as a service (SaaS) application delivery that, if used correctly and intelligently, could support a complete end-to-end hosting and managed service environment for Web applications. PaaS gives developers a break from worrying about the costs and other overhead of managing complicated infrastructure, and leaves them with the peace of mind that a preconfigured environment offers to focus purely on building apps.
What is surprising is that Google would so flagrantly attempt to lock in a captive user community with such a clumsy PaaS offering. At first glance, Google App Engine seems an enticing proposition for independent application developers. After all, Google is a well-known and widely respected brand in other technology spheres. It could make sense to buy into the same systems that power Google’s own applications. On the face of it, the company is offering a fully integrated application environment for free. What’s not to like? Well, quite a lot, if you ask me.
The basic idea behind PaaS is to provide a physical place for Web application deployment, delivery and continuing management, without requiring developers to download, install and configure software on their hosting servers. Rather than thinking about machines that need configuring, servers and databases become simply connected places that make it all work.
PaaS must be reliable, fast, secure, managed and capable of running Web applications successfully in diverse modern environments. A true PaaS isn’t just software, or even a collection of powerful software and hardware; it’s also about a bunch of driven humans working to ensure the platform performs and responds elegantly to any problems.
Sadly, it now appears Google may be at the forefront of companies looking to use PaaS to create their own ecosystems, which lock in users to serve their own purposes. Superficially, they are promoting and providing a cool environment in which people can code, but drawbacks all arise from how proprietary these environments are.
If a PaaS forces its members to use non-standard APIs, vendor-specific libraries, unique account management tools and more, users quickly become locked into that environment and have few options as a developer. Instead of enjoying flexibility and autonomy, previously independent developers would be forced to create business models shaped by the ecosystem of the platform they signed up to and will, by definition, also be subject to third-party business constraints.
Currently it appears that developing an application to run on Google App Engine will require developers to build their application specifically to that platform, instead of creating applications that adhere only to industry standards and enjoy portability and flexibility between platforms. Sure, Google subscribers will get to take part in an ecosystem that undoubtedly will prove as vibrant as any developer community, but is being forced into an unwanted and unnecessary business model a reasonable price to pay?
Google is at least being reasonably upfront about the situation in some respects, acknowledging its use of Python and inviting feedback through a beta program, but its cursory dance with open source still creates conflict. If you take Python and layer proprietary technology on top of it, should it still be considered open source? Surely, the only genuine route would be to take standard open-source components transparently and use them across the whole environment. Google’s approach leaves no room for developers to take previously created applications and simply drop them into the platform.
It’s hard to regard Google’s standpoint as anything short of self-promoting. Effectively what it is saying to developers is: If you want to take part in this big ecosystem and become a cog in this global brand, you must play our game and use our toys. What repercussions will this have from a commercial angle once Google App Engine finishes its beta? Who would be the biggest beneficiary?
What developers really want from a PaaS is independence, the ability to create an app, deploy it, gain the benefits of an active ecosystem and retain development access and flexibility. The owner of that platform will still gain revenue through a long tail stream once apps are deployed and generating revenue, if it is built properly and for the right reasons. Sadly, a locked-in model often just wants application volume to drive other forms of revenue, notably from advertising.
Developers are already listing grievances against proprietary PaaS models. They don’t want to be locked in to inflexible APIs, libraries and non-standard versions of programming languages. They know through experience to be wary of non-standard databases that make it difficult to move their data around and naturally look for open relational databases, such as MySQL or PostgreSQL.
Working within a big proprietary system removes developers’ ability to maintain their own environment. A simple process like weekly cleanups would become impossible and would engender a loss of control that conflicts with the freedom a PaaS is intended to provide.
A well-intentioned PaaS will allow apps to be scaled as required, unlocking enough power and resources. It will support multiple development languages and always be looking to add more. It will be truly scalable, open and would avoid any route that could lead to vendor lock-in. From a developer’s point of view, it is very hard to see any advantage to a proprietary PaaS, such as Google App Engine, from a technical side. Are branding and reach really of sufficient benefit compared with such a significant potential loss of freedom?
In an a modern online world that offers no structured service-level agreement or long-term contract, the only assurance of continued service levels, support and pricing levels even on the most open PaaS models is a 60-day period of notice. Why would developers choose to actively limit the usable life of their application by locking them in to a proprietary world such as that proposed by Google?
David Abramowski is CEO of Morph Labs.
Related Search Term(s): SOA & SaaS, software development, Google
Share this link: http://www.sdtimes.com/link/32617