Recently I gave a talk on helping to select PaaS from among the many PaaS out there and understanding the taxonomy of PaaS or simply how to categorize them to put them in useful buckets.   One person at the talk asked about use cases for PaaS.  I realized I haven’t blogged about the most common or interesting use cases for a PaaS’s or ECOSYSTEM PAAS’s.

If all the cloud terminology and cloud is confusing to you read this.

 

What is a PaaS?

 

A PaaS is a set of tools to help you build and deploy software applications that run in cloud(s).

The cloud could be your own on-premise hosted cloud you run yourself or it could be a public cloud or a combination (hybrid).   PaaS  helps you deploy to IaaS infrastructure automatically, operate the software, handle runbook scenarios automatically, help you manage the users and tenants using the applications in production as well as the developers, testers or others working on the applications.  A PaaS also performs some very important functions such as managing the isolation of different tenants, scaling up the instances of the application as load builds from any tenant or combination of tenants and distributing the demand from users to the right instances of the applications.   A PaaS can do many other things including services to support application development, allocating resources for each user or tenant instance. A PaaS can also help in the development process by including the Application Lifecycle Management tools and even IDE’s (Integrated development environments).

I call a PaaS which does the entire development process an Ecosystem PaaS.   See the diagrams above for a typical architecture of PaaS and Ecosystem PaaS. My article and powerpoint: understanding-the-taxonomy-and-complexity-of-paas   gives details on the types of PaaSs and what they include to help you select the PaaS best for your needs.  It explains the terms and features in more detail to help you figure out which features are important.

 

 

Why do PaaS at all?

 

Why do enterprises want to consider a PaaS?   Primarily because of the reasons they should consider any aaS.  See my article on understanding cloud computing Here are some really good reasons to consider whether it’s worth your time to read the Use Cases described below

1. Faster Time to Market – automating many previous manual steps reduces time to market dramatically (months to hours in some cases)

2. Lower Cost – helping to resource share applications saves infrastructure costs, automation reduces labor (at least 50% reduction)

3. Lower Capital Commitment – start with small deployments and grow automatically as demand builds  (90% reduction)

4. Manage many applications easier – Application, Tenant, user management, security, load balancing common helps systematize otherwise duplicative functions.

5. More Responsive – automated deployment means being able to deploy changes faster, automated scaling means responding to demand faster

6. Best Practices – PaaS incorporates best practices for application management that systematizes and professionalizes the operation of many applications

7.  Increase Reuse – PaaS facilitates reusing services through various kinds of multi-tenancy, load balancing and resource sharing.  Reuse facilitates cost reduction as well as faster innovation.  Changing a reused service results in improving all those applications using it.   An Ecosystem PaaS may include collaborative functions to enhance reuse.

 

The “Why?” boils down to lower capital commitment, faster time to market and lower risk in many cases dramatic reductions in these key performance metrics.   This is the new model of development and hard to imagine anyone involved in Enterprise Software is not seriously considering PaaS.

 

 

 Jumping the Chasm to Radical Change

Why doesn’t everyone use a PaaS?

There are lots of reasons enterprises aren’t implementing PaaS immediately which seems like something everyone would do given the dramatic improvements in cost, time to market etc… that I described in the previous sections.   Why aren’t they?   These are reasons I have heard:

1. What you have works today  and don’t want to spend more money to change it

2.. Taking legacy applications and making them work in a PaaS is sometimes very hard, possibly inappropriate.

3. Running your own PaaS can be complex.  Using a public PaaS  means making a decision and moving things to public infrastructure possibly involving many issues.  Need more time to figure it out.

4. Concerns about multi-tenancy, data isolation in the cloud lead people to worry about security of data

5. Have a preference for your own tools, don’t want to change one or more tools that can’t be integrated into a PaaS.  Implementing your own PaaS or DevOps.

6. Your application has hardware dependencies, performance requirements, networking complexity or other issues that there is no PaaS today that can deal with

Some of these are valid concerns but many are not good reasons.   The vast majority of companies should be looking at running as much of their application mix in PaaS as possible.   Another approach is to take an incremental approach which is to implement DevOps automation.   You can use tools like Chef, Puppet and write scripts to automate more and more of your process of deployment and operation so it is much like a PaaS.  However, building your own PaaS is not a good long term answer as the costs of maintaining this software far exceeds eventually the cost of a PaaS.   Companies usually implement application specific DevOps which means it doesn’t work with other applications and may need constant updating and cost to keep working with the current application.

Use Cases Overview

I highly recommend you look at this open source Apache project as a description of a good private PaaS

Here is a good Ecosystem PaaS you can use and examine to understand it

Each use case is broken into the benefit of the use case to the enterprise, the problems in the use case most companies run into, what you need to do at least as far as initial steps to go down this use case and then a breakdown of the kind of PaaS features you need to implement the use case.  Please consult my blogs powerpoint, talk on selecting a PaaS

These use cases represent problems almost all companies have.  If you look at these I believe you will find your company or group in one of these situations.  If not, let me know.  Maybe you have a missing use case or maybe you have a good reason not to use PaaS or maybe you need a PaaS that doesn’t exist yet.

I have not gone into excruciating detail on how to implement the use case.  This will require some engineering and it would not meet the concern for brevity.  So, I have described the general problem the use case addresses and the rough solution and requirements.  I may go into depth on several use cases in subsequent blogs.

Here are the 9 scenarios I have seen in the market for PaaS.

 

  1. Reduce Cost

Problem:  A company has many legacy applications that cost a lot to keep in operation.  They wish to reduce cost of operations but do not expect to change the applications much.

Many large companies face this scenario where they have large costs to run existing applications that they would like to reduce.  Frequently these applications are being phased out one by one over time but this could take years to transition and in the meantime you would like to reduce the cost of operating all these legacy applications.

The benefit:  Potentially cutting the cost of operating these applications by 50-90% depending on the ability to share resources and reduce specialized management.

The problem:  Many applications will not run easily in a PaaS like mainframe applications, some that depend on special hardware or can’t be encapsulated for one reason or another in a cartridge or virtualization container.  Many legacy applications cannot be changed even a little because the code is unknown, the original owner is gone or out of business. The solution is partial in most cases but may still be worth the cost savings.

What you need:  A Polyglot PaaS is critical.   Since the focus of this type of problem is operations you may want to focus on PaaS that have particularly good operational capabilities to monitor applications.   The PaaS may not be able to do much more than keep the applications running and give you sharing of some resources.

Public/Private tradeoff:  Moving the data to a public infrastructure may be difficult or impossible.

Hybrid: N/A

Polyglot:  Very Important.

Sophisticated Resource Sharing:  Not that important.

Vendor Specific:   You may need to look into specific PaaS that know how to handle the type of legacy applications you want to move

Lifecycle needs: N/A

Operations Capabilities:  Very important

 

  2. Move Fast

Problem:  A company has a new project for a SaaS application, API or mobile application that they wish to have the fastest best way to deploy it quickly, to grow it quickly and update it quickly.

The benefit:  Getting to market faster with a new application and ability to automate and do upgrades fast and frequently.

The problem:  Initial costs to learn PaaS and select.   Modifying your existing processes to work with the new PaaS may require effort.  If you select a public PaaS option you may be tied into that vendor for a long time.   A PaaS that is good for development may not be the best for operation.

What you need:

Since there is likely one language the new application will be written in there is the possibility to consider a language specific PaaS.  Some PaaS are good at Ruby or Java for instance.  Usually these PaaS are public and include public infrastructure to make deployment extremely easy.   The risk is by choosing a public PaaS you may tie yourself to a particular vendor and find it difficult to extricate yourself since they will give you a lot of fast time to market features, built-in services to make development faster they will also try to keep you locked in but the advantage of working in an environment which gives you all these things may be a significant time saver. Beware: If your application is not suited to the services or security of the PaaS you may find it awkward and slower to build in such a controlled environment.  For instance if you have data requirements or localization requirements, security requirements, integration requirements that exceed the PaaS capabilities you may find yourself working around them and taking more time, implementing a poorer solution than if you had not chosen that PaaS in the first place so be sure the entire requirements of your application fit the PaaS capabilities and roadmap. If your organization is venturing into PaaS for the first time then you may want to consider this a pilot project and using a more general PaaS that can solve a wider array of company problems.    In that case you may want to look at one of the problems listed elsewhere and the requirements for more general PaaS solutions.

Public/Private tradeoff:   A good use case to use a public PaaS

Hybrid: If you are limited to a single application you may not need this

Polyglot:  N/A

Sophisticated Resource Sharing:  Depends on your scaling needs and the potential for resource sharing of your application

Vendor Specific: You can consider this although always be aware such tie ins limit your future choices

Lifecycle needs:  You may want an Ecosystem PaaS that includes full lifecycle support to accelerate development processes the most.  However, if you are tied to your lifecycle processes you may find changing or integrating them with a Ecosystem PaaS is too difficult or costly.

Operations Capabilities:  Important for when you get to production

 

 

   3. Legacy and Disruption

Problem:  A company has similar application(s) it has built and runs for different customers.  Each application was built at a different time and few of the applications share some common code or services.  They wish to reduce the cost of operating all these applications and move to a new modern reusable architecture.

Many companies that have been in business for years have developed the same application over and over for different customers.  Sometimes they customized the application for that customer or they are stuck supporting a legacy application for a customer or set of customers that is no longer cost effective.  How do they get to reducing the amount of legacy code and applications and moving everyone to a more modern application? Frequently an event happens which forces everyone to consider upgrading.  Recently Obamacare, the affordability act for healthcare provided such a reason to many health care providers and payers.  This has caused a boom in health-tech.  Combined with recent advances in IoT (Internet of Things) and applicability of some of these devices to medical care, the general need of customers and providers to use the cloud to improve service and lower cost we have a sudden need for health care technology renovation.   This kind of disruption in the market caused by changing regulations, new technology can spur companies in this position above to have to  revisit all these applications and figure out how to rebuild them in a more cost effective way.

The benefit:   Consolidating applications, refactoring the applications to use common services, renewing technology can both drastically lower costs to build and deploy applications.  It can put your company on the leading edge of any disruption making you a leader in your industry or keeping you as a leader.

The problem:   It is usually not possible to do this in one big leap.   Need to find the right first steps.

What you need:

The first step to making progress on this use case is to build a prototype initial example of the application the right way, with the application built out of reusable services and common components as much as possible.   Usually you find a new application or a customer willing to take on the “new” version of an existing application.    This application becomes the template for bringing customers of the same application to the new version.  During this phase you should consider training many of your existing personnel in the new technology and learning the new paradigm of REST APIs, open source and PaaS.

Once you have a new well designed and implemented application working you put together a plan to move the older applications to the new platform.  This involves considering how much change may be needed in each one to add the features to the new application that the customer had in their legacy version of the application.  It may require integrating additional data sources, providing legacy ways to integrate or new interfaces to the application.  If you did the first version of the application well these migrations will go smoothly.  If major redesign is needed to take these legacy applications out then you didn’t do a good job in the first phase.

The next phase is to start to take other applications and following the same strategy.   Using the initial application components as much as possible build the next application with specific customers in mind.   If you are confident you may start moving multiple legacy applications at the same time.  As you do this the number of your common APIs and services will increase but not linearly.  You may have to change your original APIs and services.  The PaaS and API Centric architecture will make iterating on the services easy and fast.   

You may never successfully get all 100% of existing customers and applications into the new paradigm.   It is usually never cost effective to do 100% of anything.  Once you have done this you will find that your existing customer costs plummet and the agility you have to improve and upsell those customers improves dramatically as well.

 

Public/Private tradeoff:  It is unlikely a public PaaS is a good choice although use of Public IaaS may be a good option

Hybrid: Very important.  You may find you need to deploy in many clouds including customer specific clouds.   You need a PaaS with excellent capabilities in this area.

Polyglot: Depends on your application needs

Sophisticated Resource Sharing:  Very important as reducing cost of operation for all the customers is likely to be huge benefit with this use case

Vendor Specific:  Not a good choice as you will be building different applications you can’t be sure if vendor dependencies will become a problem for some applications

Lifecycle needs: A lifecycle PaaS will help a lot systematize the reusability and development methodology here.  You are looking to build a more consistent process for these applications and the lifecycle support will help you do this.

Operations Capabilities:  You want excellent operational capabilities here

 

     4. Spark Innovation

Problem:  A company wants to create an environment like the open source world where everybody inside the company can see the code of all the other projects in the company to increase internal innovation and reuse.  They are hoping that they will be able to leverage common code and services to greatly enhance their productivity, innovation and decrease time to market.

Forward thinking companies will realize the open source movement has been a tremendous boon to innovation and that larger companies can leverage the thousands of developers in their company to create an open source movement inside their company.  I have several articles you may find very interesting on this topic.   One is on Inner Source.  The other is on the revolution caused by open source and the new technology paradigm.  Such a move requires cultural change not just technology but it is a powerful way some companies are transforming themselves to being innovative growth companies and motivating their employees to be more creative. The posts I have written before document many of the issues for this use case.   Many leading companies are going down this road.

The benefit:  Creating common tools and exposing everyone in the company to all the assets of the other parts of the organization can be a tremendous cost savings and innovation boost.  Employees will see how they can make a difference.  They will be more motivated as they will see the benefits of their work promulgated around the company.   Having common tools means different groups can leverage each others work.

The problem:  Huge culture problem as most organizations have barriers between silos for a reason.  There is politics and concerns that some silos will suffer if they spend too much time working on common components at the expense of their silo’s profits or benefits therefore proper accounting and benefit must be made.

What you need:   First step is to socialize the idea of the benefits of open source technology approach to improving development efficiency.   Usually a big disruptive problem the company has to deal with may be good motivation.    Once there is buy in to the idea of making changes across the organization you need to pick some key projects to move to the new PaaS environment.   You may also provide incentives for groups or employees to move to the new PaaS.   An existing successful shared component that can be brought in may be a good starting point.    A key success criteria is moving as many people and projects to the new PaaS as fast as possible so that there can be sufficient mass to create the desired innovative and shared development benefits.

Public/Private tradeoff:  Since the purpose of this is to work on private code it is unlikely a public PaaS approach will be acceptable

Hybrid:  N/A : deployment of applications to production may happen in a different PaaS than the Ecosystem PaaS.

Polyglot:   In order to foster rapid migration to the new PaaS you want a highly flexible Polyglot PaaS

Sophisticated Resource Sharing: N/A

Vendor Specific: You should not have vendor specific PaaS as this will limit adoption

Lifecycle needs: You need maximum lifecycle capablity as this is crucial to the process of leveraging the inner source model

Operations Capabilities: N/A

 

  5. Increase Reach of Existing Relationships

Problem:  A company has a successful SaaS application and they want to extend that success to provide more services and capabilities to extend the connectedness and reach they have to their customers increasing revenue and stickiness in the process.

Salesforce has a very successful application.   As an application Salesforce had limited success potential.  Salesforce created Force.com as well as other applications and services.  Salesforce now makes a majority of their income from these add-on services.  Force.com is essentially a PaaS for Salesforce.  It enables you to extend the Salesforce application with your own applications that leverage services and data in Salesforce.  This has proven to answer a thorny question Salesforce had to answer early on which is how do I integrate with Salesforce so I can integrate it with my other Enterprise Applications.   As such Force.com gives Salesforce an ability to tie its customers more directly to its applications and services and generate additional revenue.   Salesforce generates more than 50% of its revenue from these spinoff capabilities for customers.

Any similar successful application can consider this as well.  Most of the successful applications are doing this.  A PaaS is a way for you to do this for your application.  Some PaaS are more suitable for building your application specific PaaS.  You need a PaaS which can be white-labeled but also needs to be an Ecosystem PaaS.    You need the ability to provide the full lifecycle of development services to a customer.    There are not many full PaaS solutions in the market that can help you do this out of the box.  Please check out WSO2 App Factory Some users of this use case are in a business where there is privacy or security regulation.   Financial firms and health companies may find it is inappropriate to provide APIs without the PaaS to provide additional isolation for the data and applications of the data.

The benefit:  Increase revenue dramatically by providing customers a way to leverage your applications and APIs better

The problem: You will want to provide a user interface that makes customers ability to leverage your services into their own applications or services easy.

What you need:   A good Ecosystem PaaS

Public/Private tradeoff:  You will run this PaaS in your existing application  environment whether it is public or private.

Hybrid: Not important as you will be controlling the deployment

Polyglot: Not important as you will be controlling the development environment

Sophisticated Resource Sharing:  Very important as you will want to make using your PaaS cost effective and cheap to start

Vendor Specific: You can choose a vendor specific PaaS which conforms to your existing infrastructure

Lifecycle needs:  CRITICAL.  You need this to enable customers to have the full lifecycle under YOUR control.

Operations Capabilities:   CRITICAL since you will be needing to figure out and handle problems customers create

  6. Develop a Community to Drive Growth

Problem:  A company has a successful service they believe can be incorporated into many other applications.   They wish to make it easy for developers, companies to incorporate their service in applications, web sites, mobile applications or other services.  They wish to create an environment that fosters community and creativity by their community.

This use case is similar to the prior one in that it is built on the idea a company already has a successful service or services.   Let’s take an example.  Let’s say you provide services to restaurants customers.  You realize that many restaurants could provide custom applications that leverage your service.  However, the cost of a typical restaurant or restaurant chain to build custom apps is large and most won’t do it without a lot of the work already being done.   With a PaaS you can provide to those restaurants or chains an easy way to build this application with the services you provide.   You work with other services to provide a general set of services useful to restaurant customers and you provide a way for restaurants and restaurant chains to customize the app (possibly as simple as drag and drop interface) so they can build their own custom looking and feeling mobile apps. You can take this example and substitute financial customers or construction customers or whatever business you are in.  If your services could be beneficially leverage-able  by your customers in this way then you want to provide a PaaS that gives your customers and innovators to find you, share ideas on how to utilize the services, help to build excitement in a community to build these custom apps and services.  You need to encourage a community to by creative in doing this and promote the excitement and value of people trying to find new ways to leverage your services to create value for themselves while at the same time increasing the use of your services. A PaaS is a good way to build such an encompassing environment and giving the developers and customers an easy way to build their custom uses of your services.

The benefit:  Increase revenue dramatically by providing rapid adoption and scaling of your services to new applications

The problem: You will want to provide a user interface that makes customers ability to leverage your services into their own applications or services easy as well as to be extensible to support new services your community may develop

What you need:  A good Ecosystem PaaS

Public/Private tradeoff:   It is highly likely you will need to use a public infrastructure and deploy your PaaS on public infrastructure but this is your PaaS and you will not find a public PaaS you can use

Hybrid:   Could be very important for community

Polyglot:  Could be very important for community

Sophisticated Resource Sharing:  Very important to keep costs low and community adoption as fast and broad as possible

Vendor Specific: Will want to avoid Vendor Specific PaaS as your community will probably find this a problem.

Lifecycle needs:  CRITICAL.  You need this to enable customers to have the full lifecycle under YOUR control.

Operations Capabilities:   CRITICAL since you will be needing to figure out and handle problems customers create

 

  7. Build an Application Factory to Foster Reuse

Problem:  A company wants to build a number of SaaS applications, APIs or mobile applications  wants do so as fast as possible reusing pieces as much as possible, using components, APIs and existing services that they have and some that are in the cloud

Usually this is a new company that can start from scratch to do things right.   They knew they are going to be building a number of applications and services and want a powerful infrastructure to do so.

The benefit:   Starting off with low cost, grow the usage as you succeed, maximize reuse and resource sharing, fast development and deployment.

The problem:  Getting everybody to agree on common technology

What you need: An Ecosystem PaaS

 

Public/Private tradeoff:  You may want Public PaaS to keep costs low initially

Hybrid: You will want this eventually and it is a mistake to think you can live with one IaaS vendor.  You will quickly become dependent on that vendor and find it impossible or difficult to change.  Numerous companies have made this mistake and paid for it.

Polyglot: Depends on your development philosophy.  If you want to enable developers to use whatever suits them you will need excellent Polyglot capabilities.  If you are going to be strict about how people build things then it may not be as important.

Sophisticated Resource Sharing:  Depends on your applications and needs to keep costs low in production or not.

Vendor Specific:  Similar to Polyglot this one can bite you later.  Consider not tieing yourself to any vendor technology as you will eventually find a customer or integration which will break your dependence and force some hard costs or decisions.

Lifecycle needs:  You might as well start with uniform lifecycle and enforce it with a good Ecosystem PaaS.  Very important.

Operations Capabilities:    Less important initially, growing rapidly in importance as you grow your applications and customers

 

 

 8. Renew Technology and Gain Adoption

Problem:  A company has many legacy people and technologies it wants to update to new technologies and the new paradigms.

The benefit:   Training people in new technologies and moving legacy to new technology allows agility and reducing costs over time, higher employee retention and growing opportunities as the company sees a growing ability to attack new problems it couldn’t imagine before

The problem:  Choosing the right projects to start renewing can be difficult and political.

What you need:  You have a choice of taking a common problem across all your business domains and renewing it or taking a specific project, group or division and renewing it.   Since your goal is to renew technology you should bring a complete solution so that people are trained on all the new technology and you get full benefits.

Public/Private tradeoff:  Private will give the most learning and experience in using the new technologies.  If you go public it may not scale across the organization leading to failed adoption and unsuccessful renewal.

Hybrid:  Important to be flexible to maximize adoption by all groups

Polyglot:  Important to be flexible to maximize adoption by all groups

Sophisticated Resource Sharing:  May be important if needed for success of the initial projects

Vendor Specific:   Important to be flexible to maximize adoption by all groups so you will not want to use vendor specific PaaS.

 

Lifecycle needs:  May not be important as you will want to gain maximum advantage of specific technologies and lifecycle is probably not the key improvement.  On the other hand lifecycle integration means you will be able to enforce the uniform adoption of the new technology and disciplines.

Operations Capabilities:   Important to insure successful adoption

 

9. Refactor your Enterprise

Problem:  A company wants to “Refactor the Enterprise.” which is to create a reusable set of services out of the existing services of the company.   They don’t want to rewrite existing services or applications much so they expect to build this new “refactoring” on top of the existing applications and services and require new applications to be built on the new layer of APIs and eventually migrate some of the existing applications and services to the new paradigm of software development.

Refactoring the Enterprise is a way to describe what a lot of companies are doing with APIs and mobile, cloud, bigdata.  The API revolution and mobile has made companies see that they have many services they would like to repackage in a RESTful way and provide so that they can build new mobile applications or other applications on this framework rather than the existing legacy interfaces and applications they have.  This has numerous benefits.

The benefit:   A set of RESTful APIs provides a way of monetizing in new ways existing assets as well as providing a reusable framework that can be used to build new mobile and other applications.  This gives the company profound new agility, a way to track usage of services better, new revenue sources and new ways to deliver value to partners and customers.

The problem:  Existing services may not be easily reframed as RESTful services.  Some may have to be broken into multiple APIs or multiple services including ones not currently existing may need to be combined to produce useful APIs.  The company may not have the insight to see how to refactor itself or the knowledge how to produce easy to use APIs.  There is an integration problem in connecting legacy applications and services.  There are security and management, production issues around providing these services as APIs.

What you need:   

The steps in this process are to examine your enterprise existing services, the needed services for near term usage in new mobile and other applications or customer needs for APIs.  A design step is needed to consider what these APIs should be, how to take the underlying technology in the company and present it.   After you have done this you need to have the integration technology and API Management software to help create these APIs and also a social API Store to promote the APIs whether for use internally or externally or both.    The next step is to iterate on these APIs as well as to bring more of the company existing services into the API store.  Eventually you may rewrite existing applications and services using these new APIs, replace some of the existing services with more efficient scalable services and even with other externally provided services.   Eventually you will have an extremely agile platform of services from which you can create new products and services quickly to meet customer and partner needs.  The new applications and services as well as API Management should run under the PaaS

Public/Private tradeoff:  Because most existing services are internal you will probably use a private solution

Hybrid:  This may be important depending on your customer requirements and growth requirements

Polyglot:  Initially not important but as you go forward you may want to have the flexibility to bring lots of pieces you didn’t expect and those may require a polyglot capability

Sophisticated Resource Sharing: You will want as much here as you can to enable very scalable leverage of resources

Vendor Specific: It is likely you have a variety of technologies which make any vendor specific technology inapplicable

Lifecycle needs:  you don’t need lifecycle technology for doing just this as you are dealing primarily with the deployment side of services and applications.  However, if you include the rapid new development of applications on this refactored infrastructure you may want a lifecycle Ecosystem PaaS to systematize and accelerate app development.

Operations Capabilities:   You need capability here to monitor both new services and integrate existing services operations management information.

 

Summary

These 9 use cases represent the cases I have run into talking to CIOs and CEOs, CTOs at companies all over the world for PaaS.   Let me know if you know of any others.

A PaaS is a powerful way to gain the benefits of the new technology in the cloud era, to leverage scalable services and reduce costs.  It is a key technology in the toolbox of the CIO trying to move his company forward.

 

Other Resources to Read about this topic:

Cloud Computing Definitions and Use Cases

Cloud Standards Customer Council 

WSO2 Cloud

Redhat Cloud

Apache Stratos Open Source PaaS

Cloud Foundry

Salesforce Force.com PaaS

Heroku PaaS