Platform as a Service

Home - Platform as a Service

Platform as a Service

Platform as a Service is often the most confusing classification of cloud computing, because it can be difficult to identify, often being mistaken for either Infrastructure as a Service or Software as a Service. In this second of a three-part article series, learn what makes PaaS unique and how it can be leveraged in your business.

The defining factor that makes PaaS unique is that it lets developers build and deploy web applications on a hosted infrastructure. In other words, PaaS allows you to leverage the seemingly infinite compute resources of a cloud infrastructure.

Of course, what appears to be an infinite amount of computing resources is an illusion, where the limitation is based on the size of the infrastructure. However, as you learned from the first article in this series, Google's infrastructure is estimated to contain more than 1 million x86-based computers. In addition, because the infrastructure for PaaS is elastic—a concept also discussed in Part 1 - the cloud can be expanded to provide even more computing resources as needed, so the illusion of infinite resources isn't entirely imaginary.

PaaS for developers

A common misunderstanding for developers is that cloud computing applies only to network administrators. But this misconception overlooks the many possibilities that cloud computing brings to development and quality assurance teams.

Consider some of the things that are often problematic during the software development life cycle. In my experience, the process of setting up the server environment that will host the Web application the development team has been assigned to build can be a huge hassle. Even in the largest enterprises, there is typically a single network administrator resource assigned to several developments teams. When PaaS is not being used, setting up a development or test environment typically requires the following tasks:

  • Acquire and deploy the server.
  • Install the operating system, run time environments, source control repository, and any other required middleware.
  • Configure the operating system, run time environments, repository, and additional middleware.
  • Move or copy existing code.
  • Test and run the code to make sure everything works.

More times than not, the administrator resource is already stretched thin, so getting a new environment deployed can be a painful process. Another major problem for web application developers for both the client and server side is duplicating the run time environment locally for your own testing purposes.

Now imagine that you're part of a development team where you are using PaaS. In such a situation, you would have a virtual machine (VM) that contained the entire server environment and could literally be passed around on a USB flash drive.

The main ingredients of PaaS

Perhaps the best way to understand PaaS is to break it apart into its main components: platform and service. Now, consider the service being provided, which is referred to as a solution stack. That said, it is logical to assume that the two main ingredients of PaaS are the computing platform and the solution stack.

To illustrate these two "ingredients," let's look further into their definitions. A computing platform, in its simplest form, refers to a place where software can be launched consistently as long as the code meets the standards of that platform. Common examples of platforms include Windows, Apple Mac OS X, and Linux for operating systems; Google Android, Windows Mobile, and Apple iOS for mobile computing; and Adobe AIR or the Microsoft.NET Framework for software frameworks. The important thing to remember is that you're not talking about the software itself but rather the platform on which it is built to run.

Choosing a provider

The solution stack also sets the different PaaS companies apart, which is something you will need to explore in greater depth before making a decision to jump on board the PaaS train.

Here are a few of the basic questions you may want to ask prior to committing to a specific PaaS provider:

  • What frameworks and languages does it support? Ideally, a PaaS should support any frameworks that are based on the language of choice for that platform. .
  • How many applications can I create? Most PaaS providers limit the number of applications you can build based on the plan or package you signed up for. Make sure the provider offers a plan or package that meets your needs.
  • What type of content is allowed? The infrastructures that support PaaS offerings typically involve a concept known as multi-tenant computing, where many "tenants" share "residencies" on a single server, separated by VM instances managed by a hypervisor. A PaaS provider may have certain restrictions regarding the type of application and content you plan to host.
  • What kind of databases are supported? This answer is very important if you have data that you will be moving over as part of your application. You must make sure that the database on offer from the provider is compatible with the format you intend to use for importing your data.
  • Does it support SSL (HTTPS)? This is another important factor for security reasons. You're going to run into major problems if you plan on conducting transactions through your applications and you find out that SSL is not supported.

Paas Anatomy

Now that you've come this far in learning about PaaS, let's explore what features you should consider when comparing PaaS providers:

  • Application development framework. A robust application development framework built on technology that is widely used. Ideally, you should beware of the potential for vendor lock-in here. Open source platforms such as Java technology are usually a safe bet in this regard.
  • Ease of use. A PaaS should come with easy-to-use WYSIWYG tools that have pre-built widgets, canned UI components, drag-and-drop tools, and support for some standard IDEs. It should facilitate rapid, iterative application development.
  • Business process modeling (BPM) tools. You need a strong BPM framework that allows you model your business process and build the application around it.
  • Availability. The platform of choice should be accessible and available anywhere, anytime.
  • Scalability. The platform should be smart enough to leverage the elastic capacity of an underlying infrastructure to handle the loads the application will be put under.
  • Security. To effectively combat threats, the platform should address things like cross-site scripting, SQL injection, Denial of Service, and encryption of traffic and make it ingrained into the application development. In addition, the platform must support single sign-on capabilities for you to be able to integrate it with your remaining on-premise applications or any other cloud applications.
  • Inclusive. The platform should provide the ability to include, embed, and integrate other applications built on the same platform or others.
  • Portability. The platform should be agnostic to the underlying infrastructure and allow companies to move the application from another IaaS to another.
  • Porting tools. To facilitate an easy and quick migration of data from the legacy on-premise application to the application based on the new platform, bulk import transformation tools are a necessary part of the platform's toolkit.
  • API. To perform tasks such as user authentication and storing and retrieving files (for example, Web application files and assets) and sometimes even making calls directly to a database, the platform should have a well-documented API. This will allow your business to have the flexibility of creating and customizing a software application to interface with the platform that meets the specific needs of the company.

Managing vendor lock-in

Vendor lock-in means that a customer is dependent on a vendor and unable to use another without being subjected to substantial switching costs. The opportunity to create an environment that supports vendor lock-in arises with technologies that are relatively new and growing in popularity, just like cloud computing. Early adopters must be aware of what they are getting themselves into before signing any long-term IaaS and PaaS agreements right now.

One way of avoiding lock-in is through standardization of APIs and platform technologies. Organizations such as Simple Cloud have started working with vendors of all sizes to participate in this open source project to bring consistency to PHP in the cloud. To create Simple Cloud, Zend Technologies, Microsoft, IBM, and Rackspace teamed up with a goal of providing an abstraction layer across different platforms.

The Simple Cloud API objective is to create common interfaces for file storage, document storage, and simple queue services. This would allow you to write applications that are portable across major cloud vendors. Vendors who are taking initiatives like this to standardize cloud computing should be commended for doing so and encouraged to continue in these efforts. When choosing a vendor to provide your company with PaaS services, I strongly recommend taking a good, hard look at providers who support standardization. Standards make life easier for all of us in the IT sector, and most importantly, they save businesses money.

To rid the PaaS marketplace of vendor lock-in opportunities, service providers who support the same underlying API are needed. The answer is simple: Service providers who are stuck on proprietary technologies must agree to support standardization initiatives such as Simple Cloud.