The CloudBees Platform: Technology Foundation for Java Platform as a Service

(1)

The CloudBees Platform:

Technology Foundation for

Java Platform as a Service

(2)

Summary

Java has evolved from a programming language to a true platform for developers. This evolution has targeted desktop, mobile and enterprise environments, building on the basic foundation of the Java virtual machine (JVM). The Java platform provides a set of libraries and establishes contracts that developers can rely on to work consistently across hardware and operating systems. The Java platform has succeeded over time because it has both driven and been driven by the fast changing pace of technologies being used by software developers of all kinds.

The emergence of the cloud today presents a new set of challenges to the Java platform. These challenges require that the platform to be extended beyond its current application-centric limitations to encompass not just the needs of developers, but also to support the demands of delivering modern Software as a Service (SaaS) while embracing the flexibility and power of underlying Infrastructure as a Service (IaaS). For Java and JVM-based languages to continue to be the preferred choice in the cloud, the Java platform itself must become a Java Platform as a Service (PaaS). In this paper, we describe the technology foundation CloudBees has established to meet these demands and how the CloudBees Platform addresses the new challenges the cloud brings to lifecycle management, security, ecosystem and business continuity.

Audience

This paper is intended for use by developers and enterprise architects, as well as IT operations personnel engaged in managing Java applications. It assumes the reader has a basic familiarity with the Java platform and with cloud providers of Infrastructure as a Service.

(4)

1.0 Introduction

In this section, we address the following questions:

 What is a platform?

 What is a Platform as a Service?

 How does the cloud impact the concept of platform?

 How does the cloud impact the Java platform and its evolution?

 How does the CloudBees Platform address these issues?

Platform and Platform as a Service Defined

For the purposes of this paper, we define a platform as the set of APIs, tools and libraries used by developers to build and test an application and by operators to manage and monitor an

application. Let’s take a quick tour of how developers and operators interact with the platform when building, deploying and managing an application today.

When Java developers build and test an application, they typically use one of the standard Java platforms – Java SE and Java EE – along with a set of frameworks. They may make use of the native facilities of the operating system and tooling to measure performance, debug and manage the application within their development environment. Developers may rely on QA teams to sign-off on production readiness, to ensure the product passes regression tests, system tests, cross-platform tests and stress tests. Continuous Integration (CI) is often used to automate and coordinate these processes, especially for distributed teams and complex projects. It usually is the job of an IT operations person to place the application into a

production environment, adjust load balancers and firewalls as required to allow access to the new application and to configure the application to interact with databases and other systems and services, such as messaging and existing backend infrastructure. IT operations personnel also ensure that enough excess or standby capacity is available to handle load, that systems are constructed to be resilient in the face of failure and that auxiliary systems can be brought online quickly with minimal interruption in the event of disaster.

The platform used by Java developers today generally is different than the one used by the IT operations personnel charged with keeping the application running. The two overlap, but traditionally, developers do not think of themselves as systems administrators and few system administrators or data center operators would call themselves developers. A Platform as a Service (PaaS) brings these two worlds much closer together, providing a common set of tools

(5)

and APIs. PaaS empowers developers and lines of business to go from concept to delivery more quickly, to transform agile development practices into agile delivery practices. As we will see, it empowers IT operations people to deliver new business value, reduce cost, to trade off operations and capital expenditures more intelligently and to more easily and deeply engage with development teams.

With the introduction of cloud Infrastructure as a Service (IaaS), like Amazon EC2, IT resources such as machines and operating systems, load balancers and firewalls are available through an API or a simple self-service tool. An application that is declared or built to be “elastic” can make use of these resources on-demand. Java web applications – and the distinction between a “plain old web application” and Software as a Service (SaaS) is near-zero for all practical purposes – both are built to be resilient on failure and to scale-out, but the task of configuration and deployment to support these characteristics is an exercise left to IT operations people. Cloud IaaS provides a huge boost operationally, because of formal guarantees on availability, isolation, security and even geography in support of legal

constraints and disaster recovery. Still, enterprise class applications often require transaction continuity, state recovery and consistency and intelligent load balancing in the face of shifting or elastic infrastructure resources. These are problems solved today by a combination of architectural and operational practices.

A PaaS is a new platform delivered as a service – in effect, the cloud generation of middleware. Traditional middleware runtimes are used within the platform, so existing applications “just run” – but the new platform augments and may modify them to take advantage of the

underlying IaaS. Most importantly, the new platform by design forces the application – not the operating system and machine – to be the level at which developers and operations personnel interact. The machine and operating system, like the load balancer, network connectivity, and so on, are IaaS-based services used by the PaaS, not by developers and operations personnel. Instead of delivering software that is installed by a developer or IT operations, the new

platform is delivered as a service hosted on cloud IaaS. Thus, delivering the platform as a service requires that the scope of the platform expand beyond a machine to encompass

capabilities traditionally handled in the data center. These capabilities include the way in which the PaaS provider interacts with the platform and with users, or tenants, within the data center. In effect, the cloud is the new foundation for an application, not the operating system and

(6)

Let’s identify some of the differences from last generation (last-gen) middleware by comparing the CloudBees Java PaaS with a typical last generation commercial Java server offering that is simply “hoisted” onto Amazon EC2:

Concept Last-gen Middleware on EC2 CloudBees PaaS

Unit of management Machine Application

How external functionality is accessed

API Service Configuration

(through a web UI or API)

Scale Thread Management Instance Management

How services are used SPI Service Binding

Provisioning Software Install Service Selection

Augmenting capability Third-Party Tools Open APIs, extensibility in

support of Ecosystem and other user services

Platform maintenance Manual patching of the OS, JVM, AS,

drivers, etc.

Transparently handled by the CloudBees PaaS

Business continuity Custom monitoring and handmade

bootstrapping of new servers in case of failure

Transparently handled by the CloudBees PaaS

The Java Platform and Cloud Considerations

The Java platform provides a uniform means to use the file system, threading model, I/O subsystem, arithmetic, database access and other subsystems of the underlying operating system and CPU your code is executing upon. Within Java EE, it expands to include

transactions, messaging, connections with other programs and sophisticated container models for server-side code execution and presentation. Even as the proliferation of mobile devices and their power has caused new languages and presentation models to be considered by developers, Java usage has expanded because of its strength in the back-end data center. Mobile application development will continue to be a key driver in IT spending, and many of these applications will interact with, and be glued to, backend systems in Java. Java platform capabilities are presented within a set of constraints to ensure solutions can be delivered in a reasonably reproducible manner by most programmers and that those solutions scale and perform well. The constraints, for example, prevent indiscriminate use of threads and state sharing in ways that inhibit scale-out. In this manner, the Java platform has traditionally imposed both simplification and constraints on developers in the interest of delivering more expressiveness and power into the hands of a broader audience.

(7)

It’s important to note that while Oracle and the Java Community Process control the definition and delivery of the three formal Java platforms (Java SE, EE and ME), we use the term here in its broader context to include the broad ecosystem of frameworks and tools that are so

incredibly important to Java’s success. Frameworks like Spring, and the huge selection of tools and runtime capabilities available through the Eclipse Foundation and other open source communities, all share the common goal of improving Java development capabilities and delivering more power to a broader audience in a platform-independent manner.

The cloud brings a new set of challenges to the Java platform:

 The cloud is increasingly enabling applications to be delivered as a service, not as traditional packaged software. The ease with which developers and companies large and small can make use of on-demand infrastructure from IaaS vendors like Amazon, Rackspace and others means that the cost of labor and capital associated with setting up and running a data center become just another budgeted item on a monthly

expense report, not a strategic investment. Servers, load balancers, networks, disk are available on-demand and can be scaled up or down very quickly based on need. These simple facts, when coupled with the rise in mobile solutions and the efficiencies of the SaaS delivery model, are causing a huge shift away from traditional packaged software solutions for enterprises and ISVs, and into SaaS.

 Delivering software as a service in the cloud enables fundamental changes in the way a software development organization behaves and the way in which a development organization interacts with corporate IT. Product lifecycles can be drastically shortened, with faster delivery of new capabilities and improved responsiveness to business and customer demands. Learning how to harness these capabilities will be as fundamental and critical to enterprises and to the emergence of new companies as learning to connect your business to the Internet once was.

 Developers and lines of business are demanding more from IT. Long procurement and planning cycles to deliver infrastructure are simply unacceptable compared to the self-service responsiveness of modern cloud infrastructure providers. The overused band-aid of virtualization has resulted in IT management nightmares because of virtual image proliferation, while the very real need for IT to enforce corporate security and other requirements on development organizations has only increased.

(8)

Today’s Java platform is missing key elements to help developers and enterprises address these changes. Some of the missing elements will need to be addressed in the core Java SE and EE platforms, and the roadmaps for those platforms are advancing in the right direction. For example, Java EE 7 will expand from the traditional Developer, Deployer and Container Provider roles to encompass Tenant and PaaS Provider. Core underlying specifications, like JMS, will be revised to reflect the new roles and their implications in cross-cutting concerns, like security. Still, when these changes formally arrive, they will just be the beginning of what is needed to address portability and for a comprehensive Java PaaS offering.

The CloudBees Platform

Figure 1 – The CloudBees Platform

As shown in Figure 1, the CloudBees Platform consists of:

 A set of core shared services for fundamental interaction with the a) underlying IaaS and b) native and ecosystem services hosted on the platform.

 A set of native CloudBees services to support the full Java application lifecycle from development through deployment and operations.

(9)

 AnyCloud™ deployment manager that abstracts the underlying IaaS to provide a single view into applications and services hosted on public and private cloud resources.

 A set of Ecosystem partner services that are integrated with the underlying core

services using the same mechanisms CloudBees uses for its native services and that can also be used by end-users to integrate custom services.

 An API surfaced through a command line, RESTful interface, and a web-based user interface to access and manage all aspects of the platform services and applications running on it.

 Integrated capabilities to use continuous integration and continuous delivery within the platform to accelerate delivery of high quality applications while maintaining proper operational control over their release.

2.0 Architecture

 What are the basic architectural principles underlying the CloudBees Platform?

 How has the use of IaaS and a deep commitment to Java and JVM-based languages influenced the architecture of the CloudBees Platform?

 How does the architecture of the CloudBees Platform enable key capabilities for end users and partners and lay the foundation for future expansion?

The Cloud Provides a Different Starting Point for Architecture

Much of today’s Java platform was designed to make building a scalable Internet-facing Java application a comparatively manageable, predictable task by non-systems programmers. In the cloud, we still expect the underlying Java runtime to deliver the same kinds of capabilities and libraries it has traditionally supplied on a desktop or server computer. However, being able to rely on an underlying IaaS layer enables fundamental layering of constraints and

simplifications in the architecture, which could not previously be relied upon. At the same time, knowing that you can rely on an underlying IaaS provides a key opportunity to expand the scope the platform addresses to encompass data center concerns. This expansion of Java PaaS scope beyond the application and into the data center is critical to understand. Let’s look at an analogy to drive home the point.

Before the advent of hypervisor-based virtualization, middleware and management software vendors spent a huge amount of effort to “virtualize” endpoints between

(10)

systems in a data center – eliminating direct references to specific machines, ports and hardware resources. Entire template-based, vendor-specific and operating-system-specific products were designed around laying down packaged software and

configuring the wiring between systems in ways that enabled flexibility in deployment, scale-out and reconfiguration. When hypervisor-based virtualization arrived, it brought the level of abstraction to a very different point. Software could

rely on the virtualization layer to provide isolated, secure access to a specific port, even though it was actually sharing a limited set of resources across a machine. Had the middleware and management vendors been able to rely on hypervisor- based virtualization at the beginning, they would have designed their systems

differently. The virtualization vendors gained a huge advantage in the ways they could simplify operations, while the traditional vendors had to support the physical

deployments, too.

We can see the same phenomenon happening when transitioning the traditional Java platform to a world in which we use a Java PaaS that builds on IaaS. For example:

 Your application is guaranteed isolation. Previously, you had to rely on deployment choices, physical hardware or a specific virtualization solution to deliver on this guarantee. Conversely, if your application depends on not being isolated, it should fail.

 You have no idea or way to know what physical hardware your application will execute on within the resources of the IaaS, other than the knowledge that the constraints you imposed based on quality of service considerations will be met.

The PaaS guarantees you have the resources for the quality of service you specify.

 All resources are accessible only as services. Look up the service, dereference it and use it. You can never make assumptions about the specific physical resources being used to host the service, or that the same physical resources will be used to satisfy different service invocations.

 The PaaS guarantees that resources you consume are served up in an integrated fashion. There is no software installation process that can conflate install and configuration, or that relies on operational best practice to deliver consistency.

 Much like virtualization has been used to provide some of the basic underpinnings of availability and disaster recovery solutions, IaaS provides the right conceptual model on which to base multi-datacenter support. The IaaS marketplace can compete on

efficiency, cost, speed, locality and service. IaaS providers offer multi-region data centers. Whether you configure the PaaS to use Amazon, local resources or a regional

(11)

IaaS hosting provider should be a choice you can make and reconsider routinely, like any other vendor choice.

 Java has delivered reasonably well on application portability as a means to avoid vendor lock-in, and a PaaS should support standard runtimes for the same reasons. Open source is not itself a solution to this problem; open APIs, a commitment to open standards and the use of standard runtimes are the keys to avoiding vendor lock-in.

 The PaaS provider is typically delivering service for the platform, in the form of patching, maintenance, upgrades and monitoring. The platform therefore has to service the needs of the PaaS provider as much as it does the developers and tenants using the PaaS.

CloudBees Architectural and Implementation Choices

Bearing in mind the different starting point CloudBees had compared to traditional middleware vendors and the larger scale issues of platform evolution, we made some key architectural and implementation choices that are reflected in the CloudBees Platform today.

Depend on the IaaS, Don’t Build It

While a PaaS can be implemented without a dependency on a “proper” IaaS layer, formalizing such a layer was essential architectural goodness from a CloudBees perspective. This choice enables the CloudBees Platform and end-users to benefit from the rapid improvements and competitive marketplace that exists in the IaaS market.

Abstract the IaaS to Enable Portability and Hybrid Solutions

Formalizing CloudBees’ internal usage of IaaS doesn’t mean we are locked into a single IaaS vendor, though. Through our AnyCloud architecture, we abstract out the IaaS layer internally to allow portability between vendors. And perhaps more importantly, this approach enables AnyCloud to treat the choice of public cloud or private cloud targets (including basic virtualized environments) as deployment choices. Enterprises will always have a huge investment in important “legacy systems” that new applications need to access. Security or latency concerns will dictate requirements to use local behind-the-firewall systems. So, having an architecture that supports hybrid deployments, such as AnyCloud, was a must-have at CloudBees.

(12)

Be Runtime-Independent

Getting quickly to market is all about making choices. So while we chose Java runtimes that we felt would be most useful to the broadest possible audience, we architected the solution under the covers to be able to plug-in multiple runtimes easily. To go even further, we provide

extensibility mechanisms that let you adapt the platform to your special needs or type of application.

Use Reproducible Base Images and Packaging as Atomic

Building Blocks

To deliver a hosted platform as a service, you really have to choose the right atomic building block that everything else sits on. And you need to be able to build everything from scratch without resorting to folklore or specialized knowledge that only a few people understand. Under the covers, our atomic building blocks are a small set of Linux images we use to bootstrap everything else in the CloudBees Platform.

Automate, Automate, Automate

All of our operations are automated, using tools like Chef to serve up consistent meals based on well-documented recipes. Everything is scriptable. Our entire PaaS can be re-built in an automated fashion from source code, in a test or production IaaS environment. For example, at all times a complete clone of the CloudBees offering is running in a dedicated test

environment, including all of the back-office services. CloudBees leverages the power of the cloud to our own advantage.

Use Jenkins as the Backbone for ALM

Since CloudBees is delivering the CloudBees Platform as a service, we decided to use Jenkins

and continuous integration and delivery as the backbone for our own software lifecycle. This dog-fooding means the CloudBees engineering team is using the same services as you, an essential ingredient for success in a developer-driven world.

Commit to an Open Platform, Open APIs and Extensibility

The CloudBees Platform is our major investment, but for it to be successful, it has to be adopted, used and extended by orders of magnitude more people than we can invest in, ourselves. It has to be simple for people to connect to their services and software, so that people use and consume it, adapt it for their purposes and by doing so drive us to make it better. So everything we do is exposed and consumed as a service, and we use those services ourselves.

(13)

3.0 Application Lifecycle Management

in the Cloud

 What is Application Lifecycle Management (ALM)?

 How does the cloud impact ALM?

 How do agile development practices relate to cloud ALM?

 Why can’t traditional middleware be “hoisted” into the cloud and then used just as effectively as a PaaS?

Application Lifecycle Management in a broad sense encompasses managing the artifacts and the relationships between artifacts used during design, development, testing, staging and operation of a software product. There are a number of impacts on ALM that the cloud brings. Specifically, when you deliver SaaS that itself relies on an underlying IaaS, you find that:

1. Cycle times from concept to delivery can be drastically reduced because infrastructure setup and procurement times are effectively eliminated.

2. As the infrastructure bottleneck is eliminated, continuous integration and continuous delivery become must-haves to maintain quality. Optimally, software must be kept in a state where it is always ready to be delivered.

3. Elasticity in underlying infrastructure simplifies operational issues previously constrained by limited resources.

4. Delivering software as a service coupled with CI techniques provides new freedom to deliver capabilities incrementally, bringing better, quicker insight into end-user adoption and reaction.

5. Rapidly changing software enabled by the cloud requires confidence in operational processes surrounding updates and rollback.

6. Last generation Java middleware added value by driving into the management and operations realm; however, IaaS fundamentally changes that equation, just as virtualization has.

(14)

PaaS must be designed to address these issues directly. In the absence of PaaS, you must solve the problems yourself; likely in a way that is IaaS-vendor specific. Further, a Java PaaS can rely on the underlying SE/EE contracts and abstractions to provide more capability and

predictability for Java applications in the cloud than can a PaaS solution aimed at all languages. “Hoisting” of existing packaged Java middleware onto a IaaS (or worse, on a big piece of

hardware with no formalized IaaS layer) and wrapping it up with a nice UI is not delivering Platform as a Service. Hoisting of existing packaged Java middleware onto IaaS is just another form of a hosting service. It can deliver some efficiency improvements, but it will produce an incomplete Java PaaS solution at best. The difficulties arise because of: operational issues and complexity caused by existing middleware on elastic infrastructure; the need to automate integration with other hosted services; the suboptimal or brittle result when “service” must be bolted on top of a platform that was designed to be administered and operated in production by non-developers. Delivering PaaS requires fundamental consideration of the platform itself, not just a thin layer of operational icing.

Figure 2 – Typical Jenkins Continuous Integration Actions in Cloud ALM

The CloudBees Platform integrated Jenkins as a hosted service as its primary tool for cloud ALM. The Jenkins service makes use of the underlying runtime platform capabilities, just like the application, database and partner services within the CloudBees PaaS. This means that as you use Jenkins to drive and coordinate builds and the resulting artifacts are made available to other teams or for staging to production, the CloudBees Platform is taking full advantage of elastic resources and keeping track of your usage on a continuing basis. Hosted Jenkins as a Service can therefore become a much more cost-effective solution for developers than the

(15)

“normal” practice of statically allocating build machines. In addition, the CloudBees Platform mechanisms for slicing workload across larger machines and distributing it among smaller ones means that the IaaS resources are used more efficiently, further reducing costs.

The tight integration of the Jenkins service across the platform makes a continuous delivery strategy simple to adopt. Larger projects can layer tests and automate or formalize handoffs between teams. New feature/function can easily be tested in the same environment as the production system, either kept private or by using “dark launch” techniques, A-B testing and in controlled rollouts. This single-system view between development and deployment,

completely without the need for traditional IT ops involvement, provides the missing piece to transform an organization beyond agile development to agile delivery.

4.0 Business Continuity

 What do we mean by business continuity?

 How does the CloudBees Platform use IaaS to solve availability, disaster recovery and other critical operational headaches faster, with better confidence and with lower cost?

 How does the CloudBees PaaS provide better IaaS independence for business continuity solutions and why should you care?

 How can your existing investment in business continuity be integrated with applications hosted on the CloudBees Platform?

Business continuity encompasses the ways in which your business deals with a broad range of threats, including unplanned infrastructure outages or loads, security problems and natural disasters. In a way that is analogous to PaaS unifying the tools of developers and operations people, formal adoption of PaaS helps your company achieve business continuity goals more quickly. It does this both by formalizing the role of IaaS, as we have discussed, but also by pushing much of the hard, complex work associated with disaster recovery and continuous availability solutions into the PaaS layer.

(16)

The CloudBees PaaS uses proprietary provisioning technology to ensure that consistent, secure, validated Linux-based system images are always available for its native hosted services. During your development or runtime usage of the CloudBees PaaS, then, CloudBees can provision and de-provision servers automatically or at your specific request. CloudBees AnyCloud then supports provisioning across availability zones, between security groups you define and across multiple regions.

(17)

Unlike a private PaaS model, the CloudBees AnyCloud architecture takes a fully-serviced hybrid model approach. The automated infrastructure resource management and ecosystem support are still directly serviced by the centralized CloudBees PaaS, not by the datacenter provider. Thus, the datacenter operation costs and expertise are isolated to the datacenter operation itself – the IaaS layer – and on managing existing systems, such as databases of record, not on platform management. This approach lets CloudBees AnyCloud use its PaaS technology and operational investment to optimize use of infrastructure resources within an on-premise datacenter. At the same time, it lets the datacenter operator maintain control over local resources and use existing security policy enforcement mechanisms over them.

This kind of local-control-with-centralized-management approach should be familiar and comfortable to many enterprises, since it is similar to the Red Hat Operations Network approach, but applied to PaaS. The design approach used in AnyCloud also ensures that local systems continue to operate in their existing configurations even if the connection to

CloudBees is interrupted. It has the added advantage of presenting a consistent platform-level API and face to developers and operations personnel, regardless of whether applications are running on public or private cloud infrastructure. The business can make more granular decisions to trade off operating and capital expenditure, knowing that the “service” component of PaaS remains the responsibility of the PaaS provider, CloudBees.

Some companies will look to the PaaS to help them create new solutions as their business grows and continuity concerns become more critical. However, many companies have extensive investments in their own business continuity plans, their implementation and the operational investments surrounding them. These companies require flexibility and detailed deployment planning to be able to embrace the advantages of the cloud and PaaS. The CloudBees Platform and its AnyCloud architecture provide the right building blocks to deliver the enterprise-level solution demanded by such customers, as well as by system integrators. In such situations, CloudBees delivers a custom CloudBees Engagement Plan that is developed in close coordination with the customer.

You may be familiar with the terms “tenth floor test” and “truck index”. The former refers to your ability to bring up a new server if someone dropped the old one from the tenth floor of your data center. The latter is a measure of how well you have distributed the detailed

knowledge required to keep your critical systems functioning in the event a key person is hit by a truck. As IaaS has served up infrastructure on demand, it has not stepped up to the service and technology investment required to properly address these operational issues. In fact, PaaS is the key in this area. The CloudBees Platform provisioning and deployment technology assures that the operational processes to address the tenth floor test and truck index are scalable by providing a reproducible, self-service and automated process that does not depend on specialized knowledge. The CloudBees Platform investment ensures this is just as true for

(18)

standard applications deployed to public cloud resources as it is for hybrid deployments and for dedicated cloud resources covered by a CloudBees Engagement Plan.

5.0 Security

 What is the role of PaaS vs. IaaS with respect to security, overall?

 How does the CloudBees Platform address isolation and multi-tenancy, and how do they relate to security?

 What mechanisms does CloudBees use and offer for auditing and security assurance?

 How can you enforce your existing security policies when using the CloudBees Platform?

 What kind of security issues should you be aware of using the public cloud, and how does the CloudBees platform address them?

While it’s possible to build a PaaS without depending on a formalized IaaS, the CloudBees platform has been architected to make use of the IaaS layer and to isolate you from direct access to the underlying infrastructure. One reason for this approach is so that the CloudBees PaaS can take advantage of the huge investment in IaaS that is emerging in the marketplace, and as a user, you also inherit that benefit. While PaaS must address security within its own scope, being able to leverage vendor investment in IaaS security and draw clear lines of responsibility between these layers is a key benefit.

(19)

Figure 4 – Layered Security and Management in an -As a Service World

Amazon provides a good example of IaaS vendor security investment and formalization. When you use the CloudBees PaaS on EC2, whether using shared or dedicated resources, or in

different regions, CloudBees can take advantage of EC2 constructs like security groups to ensure access to running applications is isolated to the proper individuals. You may be using IaaS cloud resources on a hosting service that deploys vSphere. In this case, the hosting provider manages and secures your resources and the CloudBees PaaS makes use of vSphere to manage its services in that environment. In both cases, the native IaaS environment offers security guarantees you and the CloudBees PaaS depend on.

Support for multi-tenancy is a basic aspect of IaaS and PaaS – the ability of the infrastructure and platform layers to be able to host multiple end-users in a resource-efficient but isolated manner. The CloudBees PaaS guarantees that your application is isolated from others that are executing in the cloud environment. Isolation is important from a security standpoint as well as a quality of service standpoint. CloudBees guarantees isolation by deploying a limited number of Linux base images from which your application is bootstrapped in the cloud environment. These images are tightly controlled and updated aggressively against security issues identified using CVE security scanning. Systems are provisioned with these base images, and then services are provisioned and configured on top of them. CloudBees’ provisioning subsystem itself is highly secured and all of the PaaS shared services are isolated behind a Virtual Private Network. Encrypted channel-only access to all running instances within the PaaS environment is limited to employees whose access keys are time-limited and whose access is logged for auditing purposes. As a CloudBees user, you are not provided direct access to specific

(20)

instances on which your application is built or running. CloudBees employees may be granted debugging access to one of your instances for a limited time and may engage directly with you in those activities. All access is logged for auditing purposes.

Many companies have formal security policies and it is critical that cloud-based deployments be capable of working within these policies. For example, during development, such policies can encompass processes to scan for security vulnerabilities or to enforce code review. The CloudBees PaaS development services allow you to use Jenkins continuous integration as a tool to plug in those requirements and monitor their enforcement. Security policies can also dictate deployment requirements – firewall configurations, encrypted connections between services, authentication and authorization enforcement and auditability. While the CloudBees PaaS will meet many of these requirements immediately, a CloudBees Engagement Plan offers the mechanism for ensuring that customized deployments will meet the strictest

requirements. The CloudBees Platform provides the basis on which such flexibility can be offered with confidence, securely and at scale.

(21)

6.0 Extensibility and Ecosystem Integration

 How does the CloudBees Platform actually provision underlying IaaS resources, and what benefits does this provide to extending and customizing functionality?

 How does the CloudBees Platform support multiple Java runtime platforms?

 How does the CloudBees Platform enable you to customize its base Linux and runtime environment for your own purposes?

 How does the CloudBees Platform support JVM-based and non-JVM-based language development and deployment in an integrated fashion?

 How does PaaS impact traditional approaches to building and supporting an ecosystem of partner software and services?

 How does the CloudBees Platform enable efficient integration of ecosystem partner services?

Extensibility is a central design focus of the CloudBees Platform and it is reflected in a number of ways, internally and externally. Internally, CloudBees uses Linux base images that can be deterministically and simply reproduced along with your applications and the services they consume. Thus, new instances can be quickly and reliably provisioned with no specialized knowledge. When used in conjunction with the underlying runtime-agnostic CloudBees Platform infrastructure, this approach allows CloudBees to extend the platform to support additional runtime infrastructure with minimal investment.

(22)

CloudBees’ extensibility design focus is also a heritage from Jenkins, where an open API for plug-ins and the community surrounding them adds tremendous value and serves to make Jenkins the most popular continuous integration server. This sensibility is, for example, reflected in the extensibility of the CloudBees SDK. Using the extensibility mechanism, partners and even end-users can add command line capabilities to the SDK to augment the existing ones CloudBees provides. This open API approach is a central value proposition for the CloudBees Platform that will improve over time based on both CloudBees’ and the user

community’s investment.

The CloudBees Platform depth is focused on JVM-based languages (e.g., Java, JRuby, Scala), and the Java community is busy providing new capabilities and languages at a rapid pace. At the same time, many developers are choosing whatever language and libraries best suit their purposes, regardless of whether the runtime is JVM-based. The CloudBees Platform uses an extensibility approach to simplify building, deploying and managing of JVM-based applications regardless of language, and at the same time to support launching any managed process in a very flexible, parameterized fashion.

For consistency with its broad adoption in the Ruby community, the CloudBees Platform uses the procfile mechanism popularized by Heroku. We refer to application processes whose runtime environment is hosted and managed by CloudBees as CloudBees Native applications. Examples of CloudBees Native applications include those running on a JVM directly regardless of language, JBoss- and Tomcat-based applications. For CloudBees Native applications, we support two process types: web and worker. The standard Heroku-style for naming and launching all other processes defined in a procfile we call Application Injection. In contrast to CloudBees Native applications, when you use Application Injection to create CloudBees-managed processes, you must package, support and maintain the required runtime components yourself. You can use the procfile approach to launch a CloudBees-managed process supporting, for example, an application that a) uses a specific Java runtime that is not part of the curated CloudBees services; or b) uses a non-JVM-based runtime and associated libraries. Application Injection and procfiles offers enough flexibility to meet virtually anyone’s needs, and CloudBees makes use of the extensibility internally to bring new capabilities online more quickly. Note that CloudBees provisioning, deployment and scaling mechanisms are applied consistently between Native and Injected applications, with the expectation that Injected applications will handle the details properly when the CloudBees PaaS terminates and relaunches processes, just like Native applications do.

(23)

Ecosystem as an Extension of Platform

In a traditional hardware/OS combination, a broad ecosystem of packaged software and online services has often been the most important factor in purchasing decisions. This is just as true today, as mobile applications and app stores are seeing tremendous growth and influence. The Java platform’s portability lifted the level of ecosystem further, as multiple vendors of EE offerings and subsystems, like messaging, could deliver a single product binary that could execute on top of the Java platform across hardware/OS combinations without change.

The equation changes dramatically in the cloud. PaaS provides the formal integration layer for plugging in services that support development and deployment in the cloud. The integration point cannot reside at the same Service Provider Interface level found in the existing Java platform, because cloud services must be integrated in ways that account for a) multi-tenancy; b) identity; c) billing/metering; and d) vendor-specific access and service models. These issues must be accommodated in the PaaS layer not just because the existing Java platform today lacks the proper constructs, but also because the solution must support operations on a IaaS layer. As infrastructure resources come and go, and as new tenants and applications come and go, the PaaS must ensure that ecosystem resources accompany the changes without loss and with consistency.

In most of today’s data centers, the equivalent of ecosystem support involves IT deploying and maintaining shared libraries and providing careful operational processes to ensure updates have no unintended consequences. Alternatively, application developers often package third-party software with their applications, causing costly downstream consequences as IT people have to deal with the versioning and updates and security issues over time. Given the pace of change and competitive advantage that can be gained when building SaaS on an IaaS

infrastructure, it is critical that the PaaS step up to solving the problem natively. Capabilities like extensibility of the CloudBees SDK and Application Injection are examples of ways the CloudBees Platform addresses these issues. Deep commitments to extensibility, open APIs, open standards and standard runtimes are ultimately key, as they avoid lock-in and foster broader adoption and community involvement.

(24)

Conclusion

In this paper, we have examined how the cloud drives changes to the platform we have traditionally used to develop and deploy software. The platform changes require a

fundamental shift in the level with which we interact with applications and services, as our vantage point shifts from a single process on a single machine to a cloud of resources. The changes impact architectural choices for the way the platform is delivered – as a service, not as packaged software. They impact the way we address security and how we operationalize secure practices. They affect the value and implementation of extensibility points, as the delivery model for the broad Java ecosystem transforms from a packaged software model to a service-based one. And, one of the biggest challenges the platform changes must address surrounds the delivery and maintenance of service in a scalable, reliable and continuous manner. The platform technology investment must eliminate or minimize the labor and operational expertise required to operate systems at scale, as much as it must improve developers’ ability to deliver software more reliably and quickly using the power of the cloud. To do this, the platform must address the entire application lifecycle, from development, through deployment and into operations and maintenance.

These changes require a new generation of middleware platform that is delivered as a service – a Java Platform as a Service. The CloudBees Platform embodies the kind of deep investment in the technology and architecture needed to take advantage of the cloud, to speed time to market and to deliver business value more quickly than ever before.

CloudBees, Inc.

289 South San Antonio Road, Suite 200 • Los Altos, CA 94022 • USA

www.cloudbees.com • [email protected]