If you’ve spent any time around the SAP Cloud Platform space, you’ve likely heard the term Cloud Foundry thrown around. In recent years, SAP has gone all-in on Cloud Foundry, investing considerable time and resources in becoming a platinum and heavily contributing member of the Cloud Foundry Foundation. This involvement has had a wide impact on not only the future of SAP Cloud Platform, but also for SAP HANA 2 and SAP’s software-as-a-service (SaaS) product lines. 

I introduce you to basic Cloud Foundry concepts and look at how Cloud Foundry influences the way apps are developed on SAP Cloud Platform going forward. Along the way, I also review some benefits that Cloud Foundry brings to the table for developers outside the current SAP-development ecosystem.

Introducing Cloud Foundry

One of the more difficult things to grasp about Cloud Foundry technology is that it intersects with several layers of the cloud-technology stack. As a result, the term Cloud Foundry can mean different things depending on your role. With that in mind, let’s attempt to unravel some of these nuances and shed some light on what Cloud Foundry is really all about.

Up until very recently, platform-as-a-service (PaaS) solutions such as SAP Cloud Platform, Amazon Web Services (AWS), and Google Cloud Platform (GCP) have had a somewhat narrow and proprietary focus when it comes to application development. This is to say that while each PaaS offering has supported several popular programming environments, the environments themselves have been somewhat limited, and there are considerable proprietary restrictions in place that prevent developers from having the kind of freedom they need to truly innovate.

What’s been missing is a set of standards that imposes a strict contract between the underlying cloud infrastructure layer (i.e., infrastructure-as-a-service [IaaS]) and the applications/services that run in the PaaS layer. This separation of concerns is crucial for allowing cloud providers and developers to play to their respective strengths. Enter Cloud Foundry.

Cloud Foundry is an open-source cloud platform that exposes all the functionality you need to build and run a PaaS in terms of a comprehensive set of services. These services abstract everything from low-level hardware infrastructure concerns and run-time container management to higher-level application services, such as identity management and persistence management. Collectively, these core services provide everything both PaaS providers and developers need to manage every step of the cloud-native-application development cycle.

To put all this into perspective, let’s explore some of the common frustrations developers may have when working with legacy PaaS environments. As an example, let’s say that a legacy PaaS provider offers a Java programming environment. Currently, developers leveraging this platform are only allowed to deploy Java web apps on a Tomcat 7 web container, but there’s a huge demand for Tomcat 8. To make matters worse, developers are also complaining that there’s insufficient access to the web container for installing shared libraries or configuring container-level security.

Though this example is specific to Java, it’s very common to see similar complaints raised for other programming environments. From the PaaS provider’s perspective, the bottom line in all this is that they’re never going to be able to keep up with all the requests they’re getting from customers—at least, not if they continue down this same path.

Rather than trying to guess how developers might want to configure/deploy their applications, PaaS providers leveraging Cloud Foundry can get out of the business of building programming environments altogether by leveraging the standard- and community-defined buildpacks provided with the platform. Besides providing a framework and run-time support for applications built using various environments (e.g., Java, Python, and Ruby), buildpacks also supply the infrastructure details Cloud Foundry needs to package up applications at deployment time into containers using container technologies such as Docker. With this extra layer of abstraction, both sides win big:

• PaaS providers no longer must worry about keeping up with requests for new/updated programming environments or fret about the implications of what it might mean to expand access to these environments
• Developers can effectively program in the language/environment of their choice. For a developer, all that’s required is to package up his or her application into a container image and ship it off for deployment. From an application perspective, the container environment looks the same whether it’s run locally on a laptop or run remotely in a clustered-cloud environment.

To the PaaS provider, a container image is very much like a black box in that it doesn’t really know or care what’s inside. The overarching container management/scheduler tools (BOSH) make sure that the container applications run in a safe and secure environment. Best of all, this is all neatly abstracted from the developer whose focus can return to solving business problems as opposed to worrying about compute units, virtual networking, or elastic scaling.

Of course, while containerization is a big part of the puzzle, Cloud Foundry doesn’t just stop there. On top of its infrastructure-level abstractions, Cloud Foundry provides the tools and services needed to develop cloud-native applications from scratch. Here, the platform is rather opinionated in terms of how applications are deployed, how they integrate with core services, and how the entire development flow fits into modern practices around continuous integration/deployment (CI/CD).

What Does Cloud Foundry Bring to the Table?

To understand the value of a cloud-native platform like Cloud Foundry, it’s important to realize how the development process in Cloud Foundry differs from the more proprietary process flow we’ve seen up to now with first-generation PaaS providers. In the upcoming sections, I highlight several unique benefits of the Cloud Foundry development experience.

The Cloud-Native Development Experience

An interesting thing to note about Cloud Foundry is that, while it’s opinionated about how deployments and integration should work, it’s very careful not to get in a developer’s way when it comes to application development. You don’t have to install and configure a proprietary software development kit (SDK) or work in a certain type of toolset. Instead, developers are free to jump right in and do what they do best—code.

With Cloud Foundry, developers are basically free to develop in any environment where there’s a Cloud Foundry buildpack. This could be Java, Python, Node.js, or Ruby. When developing cloud-native apps using Cloud Foundry, developers can also use their preferred source code repositories (e.g., Git), build tools (e.g., Maven or Gulp/Grunt), and integrated development environments (IDEs). To the developer, it’s business as usual.

When a developer finishes the initial development, the process of integrating with Cloud Foundry is remarkably simple. Basically, the developer creates a manifest file (based on the YAML standard) and then uses the Cloud Foundry command-line interface (CLI) to push the app to the target Cloud Foundry instance using the cf push command.

From here, Cloud Foundry takes over, picking up the code, containerizing it, deploying it, and scaling it out infrastructure-wise where necessary. As you might expect, there are a lot of lower-level infrastructure machinations going on here, but the great thing for developers is that these details are conveniently abstracted within the Cloud Foundry platform itself. Underneath the hood, the IaaS layer could be just about anything: AWS, OpenStack, Azure, Google—you name it. To that end, it’s worth noting that this level of abstraction implies that Cloud Foundry works equally well in both public-cloud, private-cloud, and hybrid-cloud environments.

Integrating with Services

One of the more unique aspects of the Cloud Foundry approach to cloud-native development is that it puts some formal boundaries around service consumption. To understand what this means, let’s compare a cloud-native app to a similar app running in an on-premise environment. Most often, apps that are deployed on premise run on an application server (e.g., the Application Server [AS] ABAP for on-premise SAP installations). Here, the application server usually provides access to one or more resources: a database (relational or otherwise), a file system, or connections to other systems within the landscape. When running in an environment like this, developers consume these resources without giving much thought to how they’re provisioned, expecting resources to be there when they need them within their programs.

Compare this to cloud applications running in containers—the major difference is that the containerized apps don’t automatically have resources like this at their disposal. For example, since access to the file system of the host operating system (OS) is forbidden in a container environment, developers can’t arbitrarily start reading and writing files within their apps. Instead, they must tap into a cloud-based service to provide these resources. In the case of SAP Cloud Platform, we’re talking about things such as the Persistence Service, Document Service, and Connectivity Service.

Without a platform like Cloud Foundry to govern access to services, developers face a couple of challenges when it comes to service consumption:

1. It’s extremely difficult to abstract access to these services and avoid vendor lock-in. Regardless of how flexible the platform might be, it’s difficult to develop an app that consumes one or more of these services on one cloud platform and moves it to another.
2. The provisioning/scaling of service resources typically happens outside the normal development flow. Here, developers and administrators usually provision resources using some type of web-based cockpit or proprietary CLI tool.

With Cloud Foundry, services are positioned as first-class citizens within the platform. This means that developers can declaratively bind their apps to Cloud Foundry-managed services and configure/provision resources from within the same CLI used to deploy applications. This approach greatly simplifies access from a developer perspective as services hosted via Cloud Foundry come in packages that are easy to consume. For example, if you need access to a relational database such as PostgreSQL, a Cloud Foundry service provider offers intuitive packages such as small, medium, or large that you can bind to. As a developer, this is much easier than going into an IaaS price-calculator tool and trying to figure out if you need a db.r3.2xlarge instance with cross-region replication, sharding, or virtual private cloud (VPC) network configuration.

It's also worth noting that Cloud Foundry’s service-abstraction concept also extends to areas such as security and identity management. One of the major benefits to this approach is that it makes it possible for PaaS providers to offer more general-purpose services like this without having to reinvent the wheel every time a new programming environment is added to the platform. This also benefits developers since it streamlines the implementation approach such that the process of securing a web app is largely the same within the platform regardless of whether you’re building with Java or Node.js.

CI/CD

One of the primary benefits of working with a structured platform such as Cloud Foundry is that it provides a fast, efficient, on-rails development and deployment experience. At the end of the day, the objective is to streamline development so that you can get your latest innovations into the hands of your users as soon as possible.

Recognizing this, the Cloud Foundry development process integrates very nicely with modern practices around CI/CD. Using containerization techniques and microservice-based architectures, the Cloud Foundry development approach eliminates many of the barriers organizations usually encounter when trying to achieve CI in the large enterprise space in general, and in the traditional on-premise SAP landscapes specifically, by:

• Streamlining deployment. There’s less fragmentation in the CI/CD workflow (e.g., having manual post-deployment steps or custom interfaces with proprietary technologies such as SAP’s Change and Transport System).
• Abstracting dependencies to the surrounding environment/services. Less time is wasted with tedious consolidation efforts (e.g., migrating code from development to quality assurance). When developed correctly, cloud-native apps should not be subject to typical dependency problems such as missing library files or OS system-level differences.
• Being self-contained, it’s much easier to use test-driven development (TDD) practices throughout to automate unit and integration tests and reduce the manual handling of changes as they’re promoted through the landscape

Outlook

Now that you have a general sense for what Cloud Foundry is all about, let’s look ahead at how the full-scale support of Cloud Foundry impacts the future of development on SAP Cloud Platform. In the near term, it’s appropriate to think of Cloud Foundry as a new programming environment that’s supported by the platform. This is to say that Cloud Foundry complements existing programming environments such as the Java, HTML5, and native SAP HANA environments.

In the long run, it’s very likely that SAP will consolidate all its programming environments within Cloud Foundry. This approach enables SAP to simplify the overall SAP Cloud Platform architecture and get out of the business of having to waste time and resources building out new programming environments. By tapping into the rich open-source community that contributes to the development of Cloud Foundry buildpacks, SAP will be able to really open the platform in new and exciting ways—and you won’t have to wait months or years for the innovations to show up at your doorstep.

From a user’s perspective, the movement towards Cloud Foundry further unlocks the platform to bring in developers from lots of different backgrounds to satisfy ever-increasing business demands. Historically, this kind of integration is challenging as there were always SAP-proprietary nuances that made it difficult to plug in developers without a strong SAP background (SAP NetWeaver Java is a notable example). Cloud Foundry eliminates many of these barriers, making development with SAP Cloud Platform much more plug-and-play.

Besides expanding the pool of available developers, Cloud Foundry also makes it easier for users to be more selective about the programming environment and tools they use to build specific solutions. For instance, if there’s a requirement for complex-text processing, it might make sense to build a particular API on top of some of the text-processing libraries available with Python, as opposed to trying to reinvent the wheel with ABAP or Java just because those are the only tools available.

Hopefully, this article gave you a sense for what’s on the horizon with Cloud Foundry and SAP Cloud Platform. For developers, these are exciting times as SAP continues to provide more tools to increase productivity and development velocity. If you haven’t looked at Cloud Foundry yet, you may want to check it out because it’s going to be coming to a data center near you very soon. You can find a comprehensive set of resources online at https://www.cloudfoundry.org.

James Wood

James Wood is the founder and principal consultant of Bowdark Consulting, Inc., an SAP NetWeaver consulting and training organization. With more than 10 years of experience as a software engineer, James specializes in custom development in the areas of ABAP Objects, Java/J2EE, SAP NetWeaver Process Integration, and SAP NetWeaver Portal. Before starting Bowdark Consulting, Inc. in 2006, James was an SAP NetWeaver consultant for SAP America, Inc., and IBM Corporation, where he was involved in multiple SAP implementations. He holds a master’s degree in software engineering from Texas Tech University. He is also the author of Object-Oriented Programming with ABAP Objects (SAP PRESS, 2009), ABAP Cookbook (SAP PRESS, 2010), and SAP NetWeaver Process Integration: A Developer’s Guide (Bowdark Press, 2011). James is also a contributor to Advancing Your ABAP Skills, an anthology that holds a collection of articles recently published in SAP Professional Journal and BI Expert.

You may contact the author at jwood@bowdark.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.