Platform as a service occupies the vast gray area between raw infrastructure, things like virtual machines, object storage or various flavors of databases, and packaged software delivered as a subscription service. This ambiguity largely explains why there are so many PaaS variants. With a number of options, it's difficult for enterprises to know which kind of PaaS technology they should procure when trying to modernize their legacy applications.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
When evaluating platform as a service (PaaS) providers for legacy application modernization, the most important criteria to consider are deployment models, product features, language and integrated development environment (IDE) support, ease of integration with existing on-premises applications, and the security features of both the development platform and the resulting applications.
PaaS overview and deployment models
Due to the ambiguous definition of PaaS, there's much disagreement about what true PaaS is. Some PaaS stacks take a bottom-up approach, building on infrastructure as a service (IaaS) technology with developer-oriented services; while some are top-down, extending software as a service (SaaS) products with programmability and exposed APIs. One thing all PaaS products have in common, though, is that they are made for application developers, not IT administrators or application users. They provide developers with the tools and flexibility they need to build applications successfully. Indeed, many offerings from PaaS providers resemble cloud-era versions of client-server IDEs.
Private versus public infrastructure
The IaaS versus SaaS orientation isn't the only way to categorize and understand PaaS products. They can also differ by means of deployment. Some are distributed as traditional software products, like IDEs and software development kits (SDKs). These are installed locally and run either on an internal cloud infrastructure, like OpenStack, or as a standalone commercial product, like Apprenda, Mendix or Stackato.
The more familiar option entails using PaaS as an online, pay as you go service -- like a SaaS for developers. Here, the PaaS provider operates the infrastructure and platform stack, stores data and runs jobs on shared infrastructure. Since major PaaS providers like Amazon Web Services (AWS), Microsoft Azure and Google also operate IaaS, they can provide tight integration between software development services and applications built on their PaaS stacks and lower-level infrastructure, like storage, databases, identity management systems and cloud service management portals. Although tightly coupling the application runtime environment with a particular IaaS can simplify the development and deployment of complex, multi-tier applications, it can also hamper portability, since features and APIs aren't compatible across the major IaaS providers.
Some PaaS products embrace a hybrid model by offering both public and private implementation options. Notably, Microsoft Azure Stack, currently in preview release, promises to bridge the deployment gap between private and public PaaS by allowing organizations to run a subset of the Azure public cloud on internal servers. Red Hat uses a similar strategy for OpenShift by offering both a cloud-hosted service and downloadable software sharing the same features, as well as providing full compatibility to run applications developed on either infrastructure.
The obvious difference between private and public PaaS is the former's need for investment in capital equipment and software licenses, along with higher overhead in ongoing software maintenance and system administration. In contrast, public PaaS operates like other public cloud services, with no upfront costs and a usage-based billing model. As with the public versus private cloud decision, the choice of PaaS deployment model requires that you build a cost model comparing the amortized cost of equipment and software and ongoing support and maintenance (generally a cost associated with private PaaS) with total service usage over a given project lifecycle.
Pricing for private and public PaaS
Pricing for on-premises PaaS technology does vary vendor to vendor. This price is on top of the cost of the systems used to run the environment. But with today's testing and development systems hardware, that is probably less than the software -- $20,000 buys a lot of server or workstation capacity. Deploying an application where the back-end system requirements are dependent on the mix of compute, storage and network workloads is another matter, and costs can vary widely. For example, a four-node, two sockets per node hyper-converged appliance with local storage will run around $50,000-$100,000.
The price for developing and deploying on public PaaS is highly variable; this is a function of resource usage for both PaaS development and IaaS runtime resources. For example, a basic Azure installation with one single core instance of App Service, a single SQL database, 50 GB of Azure Blob storage and 50 GB of file storage, a single D1 virtual machine (VM) with 50 GB of local solid-state drive, all running 24/7 will cost $170 per month, or just over $2,000 annually. Given that it's unlikely you would operate these 24/7 unless doing a globally distributed, follow the sun development project (in which case, each would be shared by several developers), it's entirely possible to run at least 50 of these Azure configurations for the price of, for example, a small private PaaS installation.
SaaS-based application development environments often have an even simpler subscription pricing model, albeit one that can get expensive, since it is based on the number of application users, not developers. For example, Salesforce App Cloud costs $75 per month, per end user for a package that includes the use of up to 100 Salesforce data objects per user. The upside to the expense is that Salesforce, like other customizable SaaS products, doesn't require any programming to produce an app, since piecing together app objects is done via a GUI.
PaaS product features
Of all the criteria to evaluate when researching PaaS technology, the most fundamental are the choice of programming languages and IDEs, because it's important to fit a PaaS to a development team's expertise and work style, not the other way around.
Online services shine in areas requiring a lot of back-end infrastructure, most notably big data storage and analysis. For example, Azure has relational, NoSQL and distributed big data (Hadoop) databases to suit a variety of application needs. It and other similar PaaS providers can be paired with services like Azure HDInsight for data analysis using various tools, including Apache Hadoop and Spark, the R statistics language or even Excel. IaaS-based PaaS stacks from the big three mega cloud players, AWS, Microsoft Azure, and Google, also support application containers that provide lightweight, efficient application isolation without the overhead of a full VM.
PaaS products also provide a variety of mechanisms for integrating with legacy, on-premises infrastructure and applications, including database connectors using Java Database Connectivity (JDBC), Open Database Connectivity or .NET, API gateways and management services, message queue, and federated identity management.
PaaS provider and product considerations
Potential PaaS customers should consider how the technology will connect with their existing applications, infrastructure and identity management directories. PaaS technology lets businesses develop new apps, but it's also important that a PaaS match up well with your existing apps and infrastructure. Businesses should ensure that PaaS stacks can access legacy APIs and data either through standard protocols (like server message block, network file system or JDBC) or custom-developed API calls.
Platform openness and the ease of migration are also important. Migrating to and from the platform, the availability of source code and documentation, the completeness of APIs, and support for different access methods (RESTful API calls, scriptable command line interface, etc.) are vital to modernizing legacy software. Application development inherently entails a degree of lock-in (i.e., you are committed to a particular language and target client); however, buyers want to minimize the friction of moving data and code to another PaaS stack. In fact, lock-in is one of the primary reasons organizations opt for PaaS stacks running on an open, portable platform like OpenStack.
Buyers should also look into vendor stability and what they offer for support for cloud services, extending to the performance, reliability and security of their infrastructure. Those in regulated industries will also need to investigate a cloud service's compliance with relevant regulations (e.g., Heath Insurance Portability and Accountability Act, Payment Card Industry, Federal Risk and Authorization Management Program, Federal Information Processing Standard and local data privacy sovereignty laws).
Before using locally installed PaaS software based on open source projects like Cloud Foundry, OpenShift or Apache Stratos, an enterprise should consider its development team's ability and inclination to use a do it yourself product. If it makes more sense to opt for a commercial implementation, consider the vendor's commitment to the open source project by looking at the number of developers contributing, timely support of new releases and product support services.
Container technology advances and improves PaaS offerings
APIs are a key component to a microservices architecture
When choosing an IaaS, consider your apps' requirements