Understanding Platform as a Service

PaaS is an abstracted and integrated cloud-based environment that supports the development, running, and management of applications. Application components may exist in a cloud environment or may integrate with applications managed in private clouds or in data centers. A primary value of a PaaS environment is that developers don’t have to be concerned with some of the lower-level details of the environment. We expect that most organizations will use a combination of some PaaS with traditional on-premises development environments.

If you look at a software stack as a pyramid, as shown in Figure 7-1, Infrastructure as a Service (IaaS) is at the foundational level and includes capabilities such as operating systems, networks, virtual machines, and storage. In the middle is the PaaS environment that includes services for developing and deploying applications. Software as a Service (SaaS) is at the top of the pyramid representing the actual applications offered to end users.

PaaS vendors create a managed environment that brings together a combination of components that would have been managed separately in a traditional development environment. Services integrated in PaaS include middleware, operating systems, and development and deployment services to support software development and delivery organizations. There are also some large enterprises that become, in effect, a PaaS provider to their own internal developers. These organizations follow a similar process of applying best practices to standardize the services developers require to develop and deploy applications. In all situations, the goal of the PaaS provider is to create an abstracted environment that supports an efficient, cost-effective, and repeatable process for the creation and deployment of high-quality applications. These applications are designed to be implemented in public or private cloud environments.

PaaS enables an organization to do the following:

Leverage key middleware services without having to deal with the complexities of managing individual hardware and software elements.

Access a complete stack of development and deployment tools via a web browser, a middleware environment where APIs can be used to plug into selected development and deployment tools. A developer might also leverage a full desktop development environment.

Overcome the challenges of managing lots of individual development and deployment tools by providing a suite of integrated and standardized tools — operating systems, security products, and the like — that meet company requirements.

Platform as a Service (PaaS) can be viewed as having two fundamental parts: the platform and the service. In this chapter, we focus primarily on the platform — the actual software that’s delivered to your organization. The service, however, is what really sets PaaS apart. The PaaS vendor doesn’t just deliver the software making up the platform; it also continuously services the software. As new updates and new configurations become available, the PaaS vendor can immediately push them to its customers.

One of the decisions you need to make when beginning to use a PaaS is whether you want to maintain the software or if you want the vendor to be the administrator. If you choose to maintain the software yourself, you must set up, configure, maintain, and administer the PaaS yourself (either on a public or private cloud). Alternatively, you can allow the vendor to provide services that handle these tasks. The result is reduced friction between the development and deployment teams. There will, of course, be situations when it’s critical for the internal team to control and manage complex software environment.

Managing the development lifecycle

It’s always been challenging to coordinate processes between those developing applications and those deploying them. Each of these groups has different objectives and often uses different platforms to achieve its individual goals. The process of collaboration becomes even more complicated when teams are spread across multiple time zones. For example, the team in one country may be working on interface design while the team in another country is working on developing one set of business services. A third team in a different location may be working on a completely different set of components.

Although each part of the application might work as intended, when it’s time to integrate, build and test problems can arise, often because developers are working on different platforms with a different configuration than operations is working on. Or the latest version of the code isn’t all in one place. In some cases, each team is using a different set of tools. Making matters worse, it’s difficult for management to get a concrete idea about the state of development across the organization or even across a single complex project.

Managing a fast-paced development environment

In order to respond more rapidly to changing business application needs, companies are moving to an agile development and deployment process. Companies have begun implementing processes that strive to continuously deliver new features and functionality. In the traditional development and deployment model, each new application build contains numerous code changes. These large builds are time-consuming, prone to errors, and may require significant time and money to implement. What makes these problems so troubling is the expectation that software development and deployment must be dynamic to support constantly changing business requirements. This demand to ensure that software models are “always working” is coming from customers who expect their partners to add new capabilities and features in near real time. Competitive pressures are mounting for companies to make their software an important part of their persona in the market.

Managing middleware complexity

Middleware is the software that allows independent software components to communicate with each other. Middleware enables application services to exchange data, implement business rules and processes, and manage transactions in an orderly and secure manner. Without middleware, each program would sit in isolation and not be able to share data or other messages.

Supporting a variety of middleware platforms

In a perfect world, there would be a single middleware stack to support the development environment for an entire company. But in the real world, an organization’s IT infrastructure is typically made up of dozens of different middleware components and development tools purchased over a long period of time. As a result, skilled individuals are required to maintain and manage a complex stack of software and platforms. Companies often find themselves relying on developers who have deep knowledge of a tool or script. Development can move only as fast as those developers.

In a hybrid cloud environment, applications often need to interoperate with other software running on-premises, in a private cloud, or in a public cloud. Without the right middleware, this can get complicated pretty quickly.

Supporting the hybrid of middleware platforms

When you begin to implement a PaaS environment, you will most likely have to deal with a combination of some public cloud-based PaaS and some private PaaS services, as well as traditional application development models. In reality, most organizations will have to combine various platforms and development and deployment services to create the type of business services that customers demand.

Obtaining compute resources

As projects grow in size and complexity, development teams often push the limits of their organizations’ compute or storage resources. It is often hard and slow to get machines and configurations to support (often cross-platform) development and testing. Teams sometimes lose weeks while waiting for a centralized procurement organization to allocate the systems they need to complete a project. Because of this procurement bottleneck, developers often hold on to their resources so that they always have the resources they need. This situation ties up unused resources that could be supporting other projects.