PaaS is the least mature of the three cloud service models. The first generation of PaaS solutions, like Google, Force.com, and Microsoft Azure, required that the buyers use a specific programming language and run on the service provider’s infrastructure. For start-ups and small businesses these constraints may have been acceptable, but for enterprises it is quite a different story. Enterprises are complex organizations with many different architectures, technology stacks, and application needs. The lack of flexibility for both the programming language and the infrastructure turned off many enterprises and slowed the adoption of PaaS. Over the past few years a number of second-generation PaaS service providers have emerged. These service providers saw an opportunity to address the enterprise customers’ needs. Many of these new PaaS vendors now support multiple stacks and some allow the PaaS software to be deployed on the infrastructure of the service consumer’s choosing. In addition to the newer PaaS service
providers, many of the original PaaS service providers now support multiple languages like Ruby, PHP, Python, and Node.js. Cloud Foundry and OpenShift are two open source projects that are gaining traction and can be deployed on any infrastructure. One of the advantages of open source cloud-based solutions is that with commercial vendors, if they go out of business, the service consumer has no choice but to quickly move to another platform. With open source the service consumers have control over the software and stay on the platform for as long as they wish.
Public PaaS service providers manage the underlying infrastructure, networks, storage devices, and operating systems. Tasks like monthly security patching, logging, monitoring, scaling, fail over, and other system administration-related tasks are provided by the vendor so the developers can focus on building cloud-ready applications. Private PaaS service providers do not provide the abstraction of the infrastructure services like the public PaaS providers do. Private PaaS offers the capability to deploy the PaaS software on both a private and public cloud (hybrid) but at the sacrifice of requiring the service consumer to manage the application stack and the infrastructure.
PaaS vendors provide a platform that is shared by many customers. In order to manage the performance, reliability, and scalability of each customer and to ensure the heavy loads from one customer do not impact the performance of another customer, the PaaS vendors have various limits that they enforce on developers. These limits, sometimes called throttling, protect the platform from getting overloaded by an individual customer, thus protecting all customers in the
process. Most PaaS vendors throttle an individual user’s bandwidth to protect against network collisions and congestion. Some PaaS vendors throttle CPU utilization to reduce the amount of heat generation in the data center and to conserve power. Other PaaS vendors that price based on fixed amounts of consumption such as blocks of storage will throttle the customer when the customer has consumed all of the resources that they have paid for. Developers must understand the limitations of their selected platform and design accordingly.
Many PaaS service providers protect their platform and its customers by throttling the database activity of customers. Developers must account for this in their designs. One way is to trap for these types of errors and retry until successful. Another method is to break units of work into smaller chunks before calling the database. This trick can be used to design around bandwidth limitations, as well. For some applications, designing around throttles creates unacceptable delays in processing time or it may impact the quality and reliability of the application. If this is the case, then PaaS may not be the right service model and IaaS should be used instead. Websites with extremely high volumes or highly distributed applications that crunch through enormous amounts of data are typically poor candidates for PaaS.
But not every application or service has the extreme processing requirements of a streaming video company like Netflix or a popular social media website like Twitter. Many workflow-driven B2B-type applications are prime candidates for PaaS. In a typical workflow, a product starts with an order and flows through a repeatable process flow until the product is built, sold, shipped, and invoiced. Dell uses
Salesforce.com’s platform called Force.com to deliver $1 billion in deal registrations with over 100,000 channel partners, so it is safe to say that PaaS solutions can scale admirably.
AEA Case Study: Use Case for PaaS
Now that Jamie has identified which components within the architecture are candidates for SaaS, the remaining components all require development. He now looks at the remaining components to determine which components can leverage a PaaS so that they can get to market quickly without having to manage infrastructure and the application stack. Jamie assessed the current web traffic and predicted future web traffic. Based on these numbers he feels that a PaaS can support their web traffic for the next two years, but by year three the load may be too great. Of course, these are just assumptions because no vendors have been selected yet and this hypothesis would need to be tested. However, Jamie needs to balance the short-term goal of getting to market quickly against the long-term goal of scaling to eBay levels. Jamie decides to leverage PaaS for seller components because the seller activity drives much less traffic than buyer activity. Sellers create content and manage their inventory, while buyers generate millions of transactions while interacting with auctions and browsing products. Jamie jots down the components that are candidates for PaaS:
Seller services. Lower volume, moderate number of customers.
Mobile touchpoint. The team has very little mobile experience and is required to develop for many different types of phones and tablets. A mobile development platform would
accelerate the development process and reduce the amount of overall development.
Social touchpoint. Measuring the impact of the various social touch-points could be a major project. Leveraging a social marketing platform eliminates a large amount of work and provides the team with deep analytics and campaign management capabilities.
Utility services. The PaaS likely provides services for security, event triggering, notifications, and APIs to connect to the popular social sites. One thing to consider, though, is that the buyer services will be run on an IaaS and will be leveraging utility services provided on the IaaS platform. The team will need to perform some due diligence to determine if they should leverage a single set of utility services from the IaaS vendor or if they can also use the utility services from the PaaS vendor.
Jamie determines that if the PaaS and IaaS utility services are compatible and the user experiences of the buyers and sellers are the same when it comes to security, notifications, social, and so forth, then leveraging both PaaS utility services and IaaS utility services is acceptable. After all, some sellers are also buyers. If, for whatever reason, the differences of the IaaS and PaaS utility services create different user experiences, the applications built on top of PaaS will have to leverage the underlying IaaS APIs. Keep in mind that Jamie has not yet determined if they are using public, private, or hybrid clouds. If they are using public clouds, then this is not an issue because the public PaaS also is responsible for the IaaS layer. If they are using a private PaaS, AEA is responsible for the IaaS layer.