[zz]Styles of Platform as a Service (PaaS)

http://blogs.msdn.com/b/enterprise_application_architecture/archive/2011/04/08/styles-of-platform-as-a-service-paas.aspx

let's go through common styles of Platform as a Service, where Google App Engine, Windows Azure and Force.com are the big players in this space, talking about strength and weaknesses in each style.

· Instance aPaaS: Developers deploy application code to instances of virtual machines. Windows Azure is the canonical example of instance aPaaS. Windows Azure supports worker and Web roles that map directly to VM instances. Engine Yard's AppCloud and Amazon Web Services' Elastic Beanstalk are other examples of instance aPaaS.

· Framework aPaaS: Provides an abstraction at the code or programming model level. Developers deploy code conforming to the framework and let the platform worry about deploying it onto compute nodes. Google App Engine, Heroku, and VMforce are examples of framework aPaaS. App Engine abstracts server instances away with Servlet or Common Gateway Interface (CGI) HTTP request model and asynchronous task queues.

· Metadata aPaaS: Developers create metadata in visual programming environments that is interpreted by the aPaaS at runtime. Force.com is the canonical example of a metadata aPaaS. Force.com abstracts away the concept of server and physical database instances using metadata. WaveMaker, Cordys Business Operations Platform, and Microsoft Visual Studio LightSwitch are other examples of metadata aPaaS.

Strengths and weaknesses of framework aPaaS and Google App Engine include:

· Platform and sandbox restrictions require significant application redesign, but the restrictions guidedevelopers to scalable, cloud-friendly design patterns.

· In Google's current offering, the non-relational data storage model requires a significant development mind-shift. However, existing Java/Python skills and (some) familiar APIs are leveraged.

· Framework PaaS is easily extended by adding new/alternative frameworks (e.g., adding a Structured Query Language (SQL) database to App Engine services to give developers choice).

· Platform components are chosen and optimized for Google's infrastructure platform. Application server instances autoscale automatically in response to demand.

· App Engine features a low entry price point and fine-grained billing for over-quota resource consumption, but no SLAs (in the current offering).

· Weaknesses in App Engine's development experience include the lack of live debugging (though debugging using a local development environment is possible).

Strengths and weaknesses of instance aPaaS and Windows Azure include:

· The most familiar and flexible programming model of the three, Windows Azure allows developers to leverage existing .NET Framework programming language and API skills. Windows Azure supports relational data on SQL Azure, thus providing an easier on-ramp than framework aPaaS for mainstream developers.

· As an instance aPaaS, Windows Azure supports arbitrary Windows executables, including programming language runtimes (e.g., VMs for Java, PHP, or Ruby). This flexibility is a double-edged sword — developers can skewer themselves by deploying cloud-unaware code that consumes metered resources inefficiently due to traditional anti-patterns and bad practices.

· Windows Azure provides a rich development life cycle environment that supports debugging and multiple test staging environments.

· Windows Azure makes SLAs available for its compute, storage, Windows Azure AppFabric, and content distribution network services. Microsoft offers access to Windows Azure with a complex set of pricing models, including a medium-level entry price point.

· Windows Azure provides the thinnest abstraction over virtual machines. Developers need to manage VM instances explicitly. But more direct interaction with Windows OS and VMs offers more leverage of third-party code than is possible with other aPaaS types. Windows Azure does not autoscale resources automatically in response to demand; Microsoft engages partners to provide autoscale functionality using Windows Azure instance management APIs.

Strengths and weaknesses of metadata aPaaS and Force.com include:

· Force.com applications can easily leverage salesforce.com customer relationship management (CRM) data.

· Point-and-click programming and customization tools can be used by non-professional IT developers, thus making professionals more productive. But the rapid application development (RAD) model can create quality risks by circumventing software development life cycle (SDLC) governance processes. Force.com mitigates access control risk by managing access privileges at the level of user/data type permissions rather than leaving this to the discretion of individual applications.

· AppExchange is a mature marketplace for applications and extensions

· Lock-in to proprietary technologies is available at many levels (language, framework, container, and hosting lock-in). Proprietary technologies mean the programming model and customization skills are non-transferable to another platform.

· Access to fine-grained resources is impossible in the current Force.com offering, thus making a true price-by-consumption model infeasible. Service-level agreements are not provided (beyond "Termination for Cause" provision) for the Force.com environment.

Organizations evaluating aPaaS should consider the following recommendations:

· Match aPaaS style with your application platform strategy. Understand the competencies, restrictions, and business model for each platform before adopting. Each platform has a sweet spot; don't try to shoehorn an unsuitable use case into an aPaaS offering.

· Extend your legacy software modernization program to include cloud adoption. Significant modernization to an application is an opportunity to rethink its platform and architecture. This provides an entry point to prototype PaaS offerings.

· Start prototyping with aPaaS now. In this early-stage market, the devil is in the details. Pick an application and discover how the details affect your development processes.

· Innovative PaaS vendors have reformed platforms around cloud architecture characteristics. With new programming models and patterns, developers can approach problems that are resistant to traditional application architecture practices. Teams should invest in learning application patterns suitable for distributed, unreliable, and asynchronous systems.

Conclusion: Organizations should choose aPaaS providers in the context of their cloud adoption and application platform strategies. More importantly, they should choose the style of aPaaS that fits their project and architecture goals. aPaaS comes in instance, framework, and metadata styles that increase in abstraction and increase in programming model changes required to use them. Google App Engine, Windows Azure, and Force.com are leading examples of each style. If developers adopt cloud without adopting programming model changes, their applications are not going to fully exploit the power of cloud platforms.