Cloud Foundry

Chapter 1. Introduction

“Nobody has ever built cloud-native apps without a platform. They either build one themselves or they use Cloud Foundry.”

Joshua McKenty, Field CTO of Pivotal Cloud Foundry

We live in a world where connecting information to actions via software is the lifeblood of business. To thrive in this world, you need the ability to deliver software quickly, repeatedly, and with regular feedback. Cloud-native platforms are a way of achieving this. However, companies with an established process, organization style, and culture often find it challenging to make the transition to cloud-native platforms.

This book looks at the changes required to become cloud native and explores how Cloud Foundry can help.

Cloud Foundry is a platform for running applications and services. Its purpose is to change the way applications and services are deployed and run by reducing the develop to deployment cycle time. Cloud Foundry directly leverages cloud-based resources so that applications running on the platform can be infrastructure unaware. It provides a contract to run cloud-native applications predictably and reliably.

The platform space is complex. Different offerings have divergent feature sets and value propositions. Comparisons between platform technologies can be difficult. This book aims to cut through the confusion by unpacking the current practices in developing and delivering software quickly and showing how cloud-native platforms are an essential piece of that story.

Greenfield Versus Legacy Applications

Due to the focus on cloud native, Cloud Foundry is best suited for greenfield development. Increasingly, however, enterprises have been adopting Cloud Foundry for replatforming, refactoring, and modernizing legacy applications.

The Competitive Advantage

Historically, the traditional way to deliver business value was to identify your competitive advantage and set up a process to make that advantage sustainable. This model has been transformed through software.

Marc Andreessen famously wrote an article for the Wall Street Journal titled “Software is Eating the World”. This phrase helped shape a generation that thinks differently about IT. It encapsulates an important concept: there will not be a market in the world that will not be disrupted in some way by software.

Over the past decade, there has been a shifting state of established market leaders from market dominance to—in some cases—extinction. Companies are now constantly challenged to compete at the pace of change of a startup, coupled with competing against the clout of “Internet scale.” Regardless of who said it first, if you are not embracing technology to deliver value to your customers, then you are losing out to someone who is.

Internet Scale

“Internet scale applications” have the characteristics of always being available. They can scale on demand, with cross-platform (e.g., OS X, PC, Android, and iOS) support and synchronization.

However, to disrupt a market, it is not enough to have software at your core. Many companies have some level of software at their core, but not all are disrupting their industry. What distinguishes market-disrupting companies is the way they deliver software. Companies such as Netflix, Uber, and Airbnb are frequently commended for their use of technology. Increasingly, however, longer established companies such as Philips, GE, Allstate, and Mercedes are changing their software development and delivery model to not only remain competitive, but to embark on new and innovative commercial offerings.

Market-disrupting companies differ from incumbents because they can repeatedly deliver software, with velocity, through iterative development cycles of short duration.

The Development-Feedback Cycle

Any development cycle must include a constant feedback loop from end users for continually refining your product.

This constant development-feedback cycle enables companies to react to shifting demand and focus attention on the key areas receiving the most customer traction. It has allowed companies to redefine and then refine new business models and markets that consumers have been enthusiastic to embrace.

Companies with an established development-feedback cycle often provide services that are a joy to use, offering ways of interaction that were previously unavailable. If an unsatisfactory release is shipped, it can be updated quickly in the minimum amount of time, often measured in minutes or hours. For example, if I use Uber to book a taxi in the morning, the application may have been updated by the time I use it in the evening. In short, a constant development-feedback cycle allows you to try out new ideas, quickly identify failings, acknowledge feedback, rapidly adapt, and repeat.

Once you start delivering value to your customers, a constant development-feedback cycle then paves the way to maintaining value. You do not stop when you succeed. Ongoing iterative development allows for continuous adjustment to match and exceed consumer demands.

Velocity Over Speed

In every marketplace, speed wins. However, raw speed alone is insufficient. With speed alone, it is possible to run in circles or random directions and achieve very little. You need velocity.

Velocity, as a vector quantity, is direction aware. In our case, direction is based on feedback. Put another way, direction is dictated by what resonates with the customer. Speed must be coupled with the aforementioned constant development-feedback cycle to ensure progress in the right direction. As discussed, feedback is essential for continually refining your product so as to resonate with user expectations. Speed coupled with the development-feedback cycle produces velocity, and velocity is the only way to move both quickly and securely.

The Critical Challenge

Now, step back and think about what you need in order to ship software at velocity. Ask yourself if any of the following statements are true:

• You prefer to deploy software in hours or days, but you actually deploy in weeks or months.

• You have a single large code base.

• You cannot update one software component without impacting and redeploying everything else.

• Product innovation is stifled.

• Developers seem unmotivated or have low morale.

• The management team cannot figure out why software releases do not ship quickly.

• Your code is “buggy” with too much technical debt.¹

If you currently identify with any of the previous statements, then the next question that needs addressing is: “How can I solve problems?” The reality is that these problems are solved by changing the current process, organization, and culture, in order to allow for fast and frequent deployments.

Many enterprises are aware of these current concerns. The enterprises that realize that process, organizational, and cultural changes are required to achieve a solution to these problems tend to quickly identify this as a critical challenge.

This challenge of addressing these three areas should not be underestimated. It is hard! For instance, consider provisioning new servers and middleware without a platform. Without preexisting resources and a self-service capability, handoffs occur between teams, which slow down the process. To change how servers are provisioned requires a change to the process, the organizational structure, and ultimately the delivery culture.

Cloud-native platforms provide a focal point that centers that change. They make it easier to do the right thing because everything you need to deliver software is already built into a platform. Without platform capability, you are required to slow right down as you adopt, integrate, and maintain more of the pieces of the technology stack.

Becoming Cloud Native

Cloud native is a term describing software designed to run and scale reliably and predictably on top of potentially unreliable cloud-based infrastructure.

Cloud-native applications are purposefully designed to be infrastructure unaware, meaning they are decoupled from infrastructure and free to move as required.

To not be cloud native means that applications need to be explicitly infrastructure aware, as they cannot reliably and predictably leverage cloud-based resources in a seamless manner. For example, consider running an application on a virtual machine (VM) in an IaaS environment. If your application is writing to the local file system, and the VM dies and gets recreated on a different storage device, then the application data is lost. In this scenario, the application is not cloud native because it is not leveraging the underlying cloud-based resources in a reliable way.

Becoming cloud native involves three fundamental tenets:

Automated Infrastructure Management and Orchestration

This is the ability to consume infrastructure elastically (scale up and down), on demand, and in a self-service fashion. This layer is often referred to as Infrastructure as a Service (IaaS); however, it is the automated self-service characteristics of the infrastructure that are important. There is no explicit requirement to use virtualized infrastructure.

Platforms

You should use the highest level of abstraction possible to drive the underlying infrastructure and related services. Service abstraction is provided by a platform that sits above the infrastructure/IaaS layer, leveraging it directly. Platforms offer a rich set of services for managing the entire application life cycle.

The Twelve-Factor App

Ensure that the application layer on top of the platform can scale and thrive in a cloud environment. This is where the concept of The Twelve-Factor App becomes key. Twelve Factor describes 12 design principles for applications purposefully designed to run in a cloud environment. These applications designed to run on top of a cloud-based infrastructure are typically referred to as cloud-native applications. Cloud-native applications are infrastructure unaware; they allow the platform to leverage infrastructure on their behalf. Being infrastructure agnostic is the only way applications can thrive in a cloud environment.²

By adopting these three tenets, everything you need to run and scale your applications—like your infrastructure, middleware services, user authentication, aggregated logging, and load-balancing—is already in place.

Becoming cloud native is an essential step in establishing a timely development-feedback cycle because it helps companies achieve velocity deploying software releases into production.

Undifferentiated Heavy Lifting

Most enterprises outside the information technology industry do not generate revenue from selling software; they leverage software to drive value into their core business. Non-IT companies have historically viewed IT as a cost center and have a hard time justifying the cost associated with developing and supporting software.

If you are spending significant time and effort building bespoke environments for shipping software, refocusing investment back into your core business would provide a huge payoff. A good cloud-native platform allows enterprises to refocus effort back into the business by removing as much of the undifferentiated heavy lifting as possible. Examples of undifferentiated heavy lifting include:

• Provisioning VMs, middleware, and databases

• Creating and orchestrating containers

• User management

• Load balancing and traffic routing

• Centralized log aggregation

• Scaling

• Security auditing

• Providing fault tolerance and resilience

If you do not have a platform to abstract the underlying infrastructure and provide the above capabilities, this additional burden of responsibility remains yours.

Platforms Benefit Developers

Developers are no longer required to deal with middleware and infrastructure complexity. The platform leverages middleware and infrastructure directly, allowing streamlined development through self-service environments. This allows developers to focus on delivering applications that offer business value. Applications can then be bound to a wide set of available backing services that are available on demand.

Platforms Benefit Operations

The platform provides responsive IT operations, with full visibility and control over the application life cycle, provisioning, deployment, upgrades, and security patches. Several other operational benefits exist, such as built-in resilience, security, centralized user management, and better insights through capabilities such as aggregated metrics and logging.

Platforms Benefit the Business

The business no longer needs to be constrained by process or organizational silos. Cloud-native platforms provide a contractual promise to allow the business to move with velocity and establish the developer-feedback loop.

Chapter Summary

Technology is used to achieve a competitive advantage, but technology alone has never been enough. The world needs to fundamentally change the way it builds and deploys software in order to succeed in the hugely competitive markets that exist today. Cloud-native platforms provide the most compelling way to enable that fundamental shift.

¹ Technical debt refers to the eventual overhead of any software system. The debt can be thought of as the additional work required to deal with system constraints, prior to completing a particular job. For example, if an application has made extensive use of application-server-specific APIs, then technical debt occurs in removing those API calls when the application moves between application servers.

² I like to recommend an ebook by Matt Stine on developing cloud-native applications: Migrating to Cloud-Native Application Architectures.