Managing Heterogeneous Applications

When your application is on your premises, you control it. This means you control the whole stack — the infrastructure, the operating system, the middleware, the data, the application, and the runtime environment. In a PaaS environment, the PaaS provider manages everything up to the application and possibly the database. The provider is dealing with installs, updates, and patches to the production environment. It’s a self-managed environment. The issue becomes this — how can you manage cloud applications together with those developed on-premises? You need to measure the impact of IT performance on the business that, by definition, now includes the performance of the cloud provider.

Here’s a simple scenario that drives home this point. Assume you have contracted with a PaaS provider to build and deploy your application. The application starts to have a problem. When something goes wrong, figuring out the source can be tough. The key is to be able to trace the source of the problem quickly. Did the platform provider just upgrade the operating system? Is there a power outage? Was there a security breach on the provider’s end? Or is it something on your end?

Gaining visibility

The bottom line is that you must be able to gain visibility into at least three areas:

Security: To monitor security, you need to scan networks, operating systems, and applications in order to prevent intrusion or denial of service attacks.

Performance: You need to ensure that the cloud’s performance doesn’t go below the agreed-upon service level.

Service availability: You need a tool that can help you determine the availability of your services. You can use this tool to monitor whether your cloud provider is up or down and is meeting its service level agreements.

Negotiating these service levels is often a dance between IT and the provider. You should ask your service provider how it monitors security, performance, and availability. Make sure you’re comfortable with the approach. Additionally, your provider should furnish a dashboard to give you visibility into those services that you’re using on a regular basis. Ideally, you want a dashboard that gives you uniform visibility across your own resources and those of your PaaS provider.

Tracking service level agreements

A service level agreement (SLA) is a contractual obligation between you and your cloud provider. IT and the service provider must work together to establish these SLAs. Typical SLAs include the following:

Response times

Availability on any given day

Overall uptime target

Agreed-on response times and procedures in the event a service goes down

The agreement theoretically gives you some assurance that the provider will meet certain service levels. However, you need to determine what levels of downtime and other parameters you’re willing to accept. For more about SLAs, see Chapter 17.

Considering access and integration

Another issue to think about is access to your services and integration between the application you want to deploy to the cloud and other services it depends on. For example, you need to determine what kind of access control services your provider offers so that only those people who are supposed to access your application during development and deployment can do so.

What about after the application is deployed? This is related to the security question mentioned in the previous section. Does your vendor provide the level of authentication and authorization you feel comfortable with? Additionally, what about the data? Traditional access control usually assumes that the owner of the application and the data are located in the same place (that is, on your premises). This is not the case in the cloud. Say that you’ve decided to move your application to the cloud, but you don’t want to move your database or even replicate your data there. You will need to ensure that the right level of security exists between your on-premises data and your cloud application.

Additionally, there can be many points of integration with an application in the cloud. The application may integrate with a customer relationship management application in your organization. The application may integrate with other services in the cloud. A key criterion for a PaaS provider is to provide well-documented and well-defined interfaces for your use. In other words, at the center of integration capabilities between applications in the cloud or on-premises are Application Programming Interfaces (APIs). These APIs, which are part of the PaaS platform, enable companies to quickly integrate their services into a wide variety of applications on a diverse set of platforms. Before choosing a PaaS vendor, make sure it can support the applications and services you need to integrate together.

Avoiding lock-in

Although the PaaS approach has many benefits, it can have some disadvantages. One drawback of PaaS is that it may lock you in to use a particular development environment and stack of software components. PaaS offerings usually have some proprietary elements (perhaps the component libraries). Consequently, you may be wedded to the vendor’s platform and unable to move your application elsewhere without rewriting it to some degree. If you become dissatisfied with your PaaS provider, you may face substantial expense if you suddenly need to rewrite applications to satisfy the requirements of another PaaS vendor.

The fear of vendor lock-in has led to the emergence of a new variety of PaaS: Open Platform as a Service. This service offers the same approach as PaaS, except there’s no constraint on choice of development and delivery software. If lock-in is important to you, then ask questions before signing a vendor’s contract.