This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - A closer look at private PaaS offerings: Read more in this section
Explore other sections in this guide:
Infrastructure as a Service (IaaS) products are typically easy for companies to apply to their computing needs because they provide only a virtual machine and perhaps some added database features. Unfortunately, IaaS users find themselves facing new operational challenges in deploying and integrating their cloud applications and their internal IT, and few companies expect to migrate everything to the cloud.
Decision makers may find that the best PaaS choice is actually several different PaaS platforms, each aligned to support a set of requirements.
A new breed of private Platform as a Service (PaaS) tools is emerging to help. These tools are aimed not at providing all the applications needed in operating systems and middleware, but instead at providing a form of "operationsware." The right private PaaS offering can make an organization's cloud experience much more positive -- and help the company better meet its business goals.
In the past, the term PaaS typically referred to operating systems and middleware. Today, though, the term is applied to any set of tools that are installed in (or on) the public or private cloud and that provide application services through software application program interfaces (APIs). Modern PaaS platforms offer security, mobility, compliance, governance, operations, orchestration, database and even application-development services. They can be run in the company's own data center and, in most cases, in a public or private cloud as well, making PaaS a curious -- but valuable -- mixture of traditional middleware and the cloud.
Choosing the right PaaS offering
The first step in making the best private PaaS choice is determining each contender's compatibility with the rest of the organization's technology. Not all hardware, software and cloud environments will be supported by any given PaaS product, so companies should inventory their IT environments and determine what they're running and where they'll want to apply the new PaaS choice. IT teams can eliminate packages that don't support their mix of IT components or that have only immature support for some of the important systems or software they run. Ideally, companies should look for packages with considerable field use to validate their provider's stability and support.
Using PaaS tools generally requires making at least modest changes in applications, application lifecycle management and software practices and processes. For that reason, companies should be wary of simply finding and applying the most comprehensive tool available; taking that approach can cause them to waste time integrating features they don't value or waste money by paying for and then dropping them. The best approach: Look at the current pain points (most companies' lists start with security or compliance and governance) and identify PaaS offerings that address them most effectively.
On the other hand, IT teams should look beyond their current requirements, making sure their PaaS choice has the features they're likely to need in the future. Otherwise, they may find themselves forced to change approaches in only a year or so.
When reviewing the list of pain points and PaaS offerings, IT teams may find that their issues divide between operations and development. That means they'll need to create a consistent and effective operating framework for applications and concurrently support application development to address mobility and other issues. PaaS tools tend to divide along functional lines, and decision makers may find that the best PaaS choice is actually several different PaaS platforms, each aligned to support a set of requirements. Ultimately, the ability to integrate easily with other PaaS elements is a highly important factor in choosing the right private PaaS product.
Most companies find that only three or four PaaS offerings will pass the initial stage of screening. That short list should then be subjected to formal auditing/testing, a process that is best handled in two steps: field review of use and pilot testing of applications.
Narrowing the field of PaaS choices
Nearly all PaaS providers are happy to make references available from former customers, and a field review of the packages installed and running in one or more of these accounts can be very helpful. That's particularly true when one of the PaaS objectives is to systematize security or governance. It's nearly impossible to review features and capabilities in these areas by simply reviewing documents; instead, it requires talking to users to see how they’ve integrated the PaaS features into their own operations and how well that particular PaaS choice has worked for them. During a field review, the IT team should take note of any situations where further examination is indicated. These will be key focus points for their own company's pilot application.
A surprisingly large number of companies fail to pilot-test PaaS tools. Some will negotiate a trial period with vendors, but even these often fail to uncover the real problems with a platform because the trial process isn't organized to expose the software to the full range of requirements. Build a pilot test plan by starting with the requirements and assumptions recorded in the early assessment phase, adding in the results of field review, and passing the sum of these points past operations and internal governance experts for validation. That internal review should also establish how long the pilot testing will have to be run to be confident that all relevant issues have been explored.
The pilot test is an excellent place to learn about the ideal order of a new PaaS deployment. A good product will have mutual coordination and cooperation among its features; in most cases, that will group features into classes of capability that should be deployed as a unit to avoid confusing operating personnel by continually changing procedures. Security and governance controls are often the first to be deployed, followed by integration and management/orchestration. The pilot test will help uncover dependencies that could cause problems if some functions aren't rolled out live at the same time.
PaaS offerings create what's effectively a "super-middleware" layer whose strengths and limitations will impact everything that runs on them, which might be everything in an organization's IT world. Best advice: Make your PaaS choice carefully; going back and picking an alternative approach will be difficult and expensive.