Advantages of PaaS

It doesn’t matter if you are a three-person start-up or a well-established multinational; using PaaS provides many benefits such as:

• Cost-effective and continuous development, testing, and deployment of applications
• High availability and Scalability
• Straightforward customization and configuration of an application
• Reduction in development effort and maintenance
• Security policies simplification and automation

AWS also offers a variety of tools to simplify the migration from an on-premises model to a PaaS model. While you learned about PaaS model pros, let’s look at some cons.

Disadvantages of PaaS

PaaS solutions have some limitations as well:

• Integrations: Having multiple parties responsible for the technology stack creates some complexity in how integrations need to be performed when developing applications. That becomes particularly problematic when legacy services are on-premises and not scheduled to be moved to the cloud in the near future. One of the reasons enterprises like to minimize the number of technology vendors is not to allow these vendors to be able to point fingers at each other when something goes wrong. When something invariably goes wrong, enterprises know precisely who they must contact to fix the problem.
• Data security: The data will reside in a third-party environment when running applications using a PaaS solution. This poses concerns and risks. There might also be regulatory requirements to be met to store data in a third-party environment. Customers might have policies that limit or prohibit the storage of data off-site. For example, China recently passed regulations that require Personally Identifiable Information (PII) generated in China not to leave China. More specifically, if you capture your customer’s email on your site and your site is available in China, the servers that store the email must reside in China, and that email cannot leave the country. Using a PaaS approach to comply with this regulation requires standing up full-fledged infrastructure mimicking your existing infrastructure in other locations.
• Runtime issues: PaaS solutions may not support the language and framework that your application may require. For example, if you need an old version of a Java runtime, you might not be able to use it because it may no longer be supported.
• Legacy systems customizations: Existing legacy applications and services might be difficult to integrate. Instead, complex customization and configuration might need to be done for legacy applications to integrate with the PaaS service properly. The result might yield a non-trivial implementation that may minimize the value provided by your PaaS solution. For example, many corporations rely on mainframes for at least some of their needs. If they wanted to move these mainframe applications to the cloud, they would have to rewrite the applications that do not require a mainframe since mainframes are not one of the types of hardware that most typical cloud providers support.

Operational limitation: Even though you have control of some of the layers in the PaaS stack, other layers are controlled and maintained by AWS. If the AWS layers need to be customized, you have little or no control over these optimizations. For example, if you are required to use a certain operating system but your PaaS provider does not support it, you are stuck with choosing one from the list of available operating systems. Let’s look at more details about when it makes sense to use the PaaS model.