cf push

That's it. That is the essential answer to the question Why Cloud Foundry?, Anti-climatic, right? At least, until you understand the revolutionary leap that application development has taken as a result.

Without cf push, the typical application development cycle is convoluted and complex because often, much of the development activity is consumed by finding a place for your application to live and serve the world securely, reliably, and robustly. There are three problems that have impeded development:

• It is difficult to deliver applications that are valuable to you, your organization, and/or the world if you aren’t able to focus on building the application itself. In some large organizations, developers have said that 80% of our efforts are getting infrastructure ready. Imagine a day in which you only have to build your application, not assemble middleware; install application runtimes; or fiddle with an operating system (OS), virtual machine (VM), servers, storage, or networking.
• Application developers are not system administrators or system operators, nor should they be compelled to be. If you ask operators to develop code that one would expect from an application developer, most would likely decline. There are boundaries from their perspective. Both disciplines fall under IT, yes. Both are extremely technical roles, requiring deep expertise to be sure. Both do the heavy lifting required to ultimately make an application of some value available to an audience who needs it. However, the Dev versus Ops divide is wide and deep. There are fundamental specializations, concerns, and risks that drive behavior in both roles that creates an obvious and quite natural fracture line to follow when dividing the workload of getting applications up and running in production. Of course, both should work together, share, and learn techniques that are cross-functional and relevant to how to be more efficient and agile in their respective roles, such as continuous integration and continuous deployment (CI/CD). In the end, application developers thrive if they focus on developing applications and solving problems in that very difficult space, without the concerns of being a shadow platform engineer or operator.
• It is hard to build a consistent, reliable, secure, and highly available production environment. Much more so by stitching together compute, storage, and network capacity into a cohesive system that meets the demands of modern enterprises and the expectations of application consumers. All the while, providing the rigor and flexibility that enables developers to focus on developing applications with ease. VMware revolutionized the IT world with server virtualization in 1998. They abstracted away the boundaries of physical hardware into pools of virtual servers. This enabled us to make better use of the underlying hardware by distributing and fitting large, complex workloads over the physical boxes.

These are the problems that Cloud Foundry was made to address: ending the eternal battle of the developer's focus on apps versus operating and engineering the platform that those applications are run upon.

Cloud Foundry does this by bringing about enterprise-grade application virtualization. It does this by harnessing and orchestrating a symphony of containers into an elastically scalable distributed system comprising all of the components a given application needs to serve the world. This changes the game much the way VMware did with VMs and server virtualization. Cloud Foundry is a proven application virtualization platform that gives control back to the developer, allowing developers to focus on developing applications, instead of infrastructure operations.

Platform as a Service (Paas) is one of a number of terms in the taxonomy of cloud computing including Infrastructure as a Service (Iaas) and Software as a Service (Saas).

While, generally, IaaS is server focused and SaaS is user focused, PaaS is developer focused. PaaS enhances developer productivity by enabling application virtualization, so there is a significant reduction in the need for developers to perform the undifferentiated heavy lifting associated with the plumbing that detracts from the actual work on application code and concerns. Often this is called yak shaving. For instance, it may include everything from installing application runtimes, dependencies, app packaging, staging, and deployment, to configuring deeper down the stack into infrastructure concerns such as configuring load balancers, networking, security, provisioning VMs—nearly anything that takes your focus off building a great application.

Heroku (https://www.heroku.com) is the name of one of the original trailblazers in PaaS. Available since 2007, Heroku is a cloud platform that enables developers to push applications into a hosted service on the internet. The idea was to focus developers on building applications, not infrastructure. Using insights gained by the Heroku team from operating a large platform with diverse applications running on it, Adam Wiggins and team formed the basis for what are now called cloud-native applications through their original Twelve-Factor App (https://12factor.net) patterns. They were motivated to raise awareness of some systemic problems seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. We will discuss cloud-native apps, and further developments since the original Twelve-Factor App methodology was written, in future chapters. Additionally, Heroku's buildpack model is used for Cloud Foundry and will also be discussed a bit later in the book.

In the cloud era, the application platform is delivered as a service, often described as PaaS. PaaS makes it much easier to deploy, run, and scale applications. Some PaaS offerings have limited language and framework support, do not deliver key application services, or restrict deployment to a single cloud. Cloud Foundry is the industry’s open PaaS and provides a choice of clouds, frameworks, and application services.

In April 2013, Dell EMC and VMware formed a new company called Pivotal. Each parent company contributed people, software, products, and collateral that were not core to their own business to this new entity. This included 11 companies that had been acquired by the parent companies at one point or another. Soon after, with further investment from additional companies, such as General Electric, Ford, and Microsoft, Pivotal's mission focused sharply on transforming the way the world makes software.  

Cloud Foundry, along with several other notable projects like the Spring Framework for Java (https://spring.io) and RabbitMQ (http://www.rabbitmq.com) for message brokering, were included in the Pivotal origin story.

Soon after its creation, Pivotal, together with other enterprise leaders, sought to create the Cloud Foundry Foundation to ensure the ongoing stewardship of the Cloud Foundry community and its open source software. The foundation was created as an independent non-profit under the Linux Foundation. Since its founding in January 2015, over 70 companies (https://www.cloudfoundry.org/members/) have joined the Cloud Foundry Foundation and continue the mission to drive the global awareness and adoption of the Cloud Foundry open source project, to grow a vibrant community of contributors, and to create coherence in strategy and action across all member companies for the sake of the project.

The Cloud Foundry Foundation exists to:

• Establish and sustain Cloud Foundry as the global industry standard PaaS open source technology with a thriving ecosystem
• Deliver continuous quality, value, and innovation to users, operators, and providers of Cloud Foundry technology
• Provide a vibrant, agile experience for the community’s contributors that delivers the highest quality cloud-native applications and software, at high velocity with global scale

Cloud Foundry is a platform for developing and running cloud-native applications. It is a polyglot platform that allows you to deploy a myriad of applications written in many different computer languages — Java, Python, Node.js, Ruby, Go, .NET languages, and many more. Simply use the best language for the task at hand with the freedom of knowing that Cloud Foundry supports it.

Cloud Foundry is IaaS agnostic and open source. It abstracts away the underlying IaaS whether you run on VMware vSphere, Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, OpenStack, or others. This means that true application portability is possible regardless of the infrastructure choices and it enables a consistent multi-cloud strategy — public, private, or hybrid.

Cloud Foundry application development requires software engineers to understand how to build and deploy cloud-ready applications. However, there is a little secret: your applications do not have to be fully cloud-native, Twelve-Factor applications to run on Cloud Foundry. Often existing applications will run just fine on Cloud Foundry with a few minor changes — if you know some simple recipes!  

Cloud Foundry provides a highly available, scalable, and secure platform to deploy your application. And with autoscaling, your application can scale-out to accommodate surges in traffic and then scale-in once traffic subsides — automatically!

Here is a guide to Cloud Foundry at a glance:

• Initial release in 2011
• An open cloud-native platform (PaaS)
• Fast and easy to build, test, deploy, and scale apps
• Works with any language or framework
• Available as open source, commercial distributions, or hosted offerings
• Open source with an Apache license, hosted on GitHub
• Developers use the cf command-line utility to interact with a CF deployment
• The cf CLI (Command-Line Interpreter) is pre-built for Windows, Mac, and Linux
• The cf supports any language or framework through buildpacks

As a developer, Cloud Foundry does the following:

• Enables you to focus on building applications
• Moves you out of the VM provisioning game
• Allows you to recreate an application's runtime environment continuously
• Deploys and scales an application in seconds
• Externalizes and injects environment-specific dependencies
• Has an API that enhances release management productivity
• Uses containers to isolate apps and create application virtualization
• Manages your application’s entire life cycle

The Cloud Foundry project code can be found at:

• https://github.com/cloudfoundry/
• https://github.com/cloudfoundry-incubator/

The Cloud Foundry architecture abstracts away many of the complexities of day-to-day application development to provide a rich and robust environment for deployment. Cloud Foundry handles many of the operational and infrastructural demands behind the scenes in a unified and consistent way so that Cloud Foundry operators and engineers can manage and maintain the platform without downtime in most cases, enabling rolling, zero-downtime upgrades, and patches to the platform without developers noticing anything going down. Scaling Cloud Foundry by adding more infrastructure is baked into the platform to enable growth over time as demand increases. 

The Cloud Foundry platform is composed of a set of horizontally-scalable, distributed services. It includes tooling which automates and orchestrates the underlying infrastructure, providing an abstraction layer over IaaS platforms.

Cloud Foundry is very robust. It uses what can nominally be called Weak AI because of its narrow focus on maintaining a self-healing feedback loop under the hood via its release engineering and management tooling, called BOSH. For instance, when a virtual machine in Cloud Foundry is misbehaving, it is taken out of service and replaced quickly. This enables failure detection and recovery at any level: application, container, VM, or the entire Cloud Foundry Foundation when configured for high availability (HA).  

Perhaps the most unusual aspect of Cloud Foundry, from a platform engineer's perspective, is that it is infrastructure agnostic, meaning that an operator can run Cloud Foundry on a variety of IaaSes such as VMware vSphere, Amazon Web Services, Google Cloud Platform, Microsoft Azure, OpenStack, bare-metal servers, and others. This is as revolutionary as the concept of the write once, run anywhere dream of application portability that application developers sought with the slogan created by Sun Microsystems to illustrate the cross-platform benefits of the Java language. Cloud Foundry does this by using an abstraction, called a Cloud Provider Interface (CPI), that translates a common set of infrastructure build commands into an IaaS-specific translation using an open source project called Fog (http://fog.io). Fog enables Cloud Foundry to avoid vendor lock-in, which constrains you to a single IaaS. Interestingly, many IaaS providers are adding support to Fog directly, such as the Google Compute Platform. As they do, Cloud Foundry enjoys this rich inheritance that will enable it to run on an ever-growing list of cloud providers as they become available and supported.

The capabilities and the operational aspects of Cloud Foundry are truly remarkable, if not revolutionary, from a system operator's and platform engineering perspective.

The Cloud Foundry platform provides key elements such as routing, container management, logging, and metrics, as well as application configuration, service catalog, and messaging built-in.

Cloud Foundry is a polyglot platform, in that you are free to use any programming language of your choosing to develop your application for deployment. It has built-in support for Java, .NET Core, Python, Ruby, Go, Node.js, and PHP and it can support more by adding a variety of buildpacks that contain everything needed for application runtimes in additional languages. Most buildpacks are open source and community-driven. They can be found at https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Buildpacks#community-created.

A simplified overview of the Cloud Foundry ecosystem:

Additionally, there are Command Line Interpreter (CLI) and Integrated Development Environment (IDE) integrations for popular development tools such as Eclipse, Visual Studio, IntelliJ IDEA, and VS Code, among others.

What about connecting your application to services such as databases, message brokers, object stores, and so on? Most applications have dependencies on these types of externalities. Cloud Foundry addresses this necessity elegantly, providing several ways to address these capabilities, of course. We will discuss this in detail in future chapters.

A simplified overview of the Cloud Foundry platform architecture:

The preceding figure shows the stack of infrastructure and BOSH that Cloud Foundry platform engineers use to install, manage, and maintain Cloud Foundry. There is the Cloud Foundry Application Runtime ™ (previously known as Elastic Runtime) inside the big box outline that is comprised of the various components. From the developer's perspective, this is Cloud Foundry. But from the holistic, systems view, it is but one part, albeit a very, very important part. The CF Application Runtime is exactly as the name implies:

The elastically scalable application runtime environment that stitches together the compendium of components needed to stretch across the underlying infrastructure resources to create and manage pools of compute, memory, datastore, blobstore, and networks to support the app-centric view of the world we call application virtualization. This includes all the orchestration, networking, containerization, management and control systems you might imagine are needed to pull together such a complex ballet of dynamic technology.

Primarily, these fall into the following categories:

• Routing
• Authentication
• Application life cycle management
• Application execution
• Platform services
• Messaging, metrics, and logging
• All of these are unified behind the Cloud Controller API, which enables RESTful integration with the CF Application Runtime through the Cloud Foundry CLI (a.k.a. the cf CLI) and other commercial user interfaces (UI) such as Pivotal Cloud Foundry's Application Manager web-based UI

We will unbox these in more detail in future chapters. Further information may be found at https://www.cloudfoundry.org/platform/.

Cloud Foundry enables a future-forward, cloud-based re-evaluation of long-held security fundamentals and assumptions because of the way its BOSH component works behind the scenes. This is an exciting time to rethink and reframe security in proactive ways that were not imaginable even a few years ago without the automation and feedback loops BOSH gives us. BOSH is constantly tearing down VMs that are no longer in good state or performing as expected, and recreating them on the fly. BOSH is always eliminating a plague that all infrastructure that is not fully automated will eventually encounter: configuration drift.

BOSH is always running on a feedback loop, validating the state of real-world infrastructure with the expected configuration. If there is drift, BOSH eliminates that bad apple and promptly replaces it with one that meets the exact specification of the configuration. This is a process called repaving. Repaving constantly ensures that we have smoothly paved underlying infrastructure that meets the needs of our Cloud Foundry Foundation and our applications. BOSH does this seamlessly behind the scenes with zero downtime to your application (provided you have at least two application instances running).

Because of this, a new way of thinking about security posture has become commonplace with the advent of the three Rs of security: repair, repave, and rotate.

These principles were first articulated by Justin Smith, a thought leader at Pivotal, in a presentation titled Cloud Native Security: Repair, Repave, Rotate in 2016, which can be found at https://www.infoq.com/presentations/cloud-native-security.

Justin defines cloud-native enterprise security as:

• Repair: Repair vulnerable software as soon as updates are available.
• Repave: Repave servers and applications from a known good state. Do this often.
• Rotate: Rotate user credentials frequently, so they are only useful for short periods of time. Minimizing the attack vector of time.

Cloud Foundry manages some of these for you already. And, it is improving rapidly as the three Rs have become a key element for the Cloud Foundry community to drive the cloud-based security posture story forward.

Just as Cloud Foundry is changing the way of thinking about a proactive, modern, agile, and adaptable security posture that is constantly repairing, repaving, and rotating at the operational levels of the Cloud Foundry components, so too has the thinking about provisioning, scaling, and capacity management changed to reflect the dynamic and adaptable way in which Cloud Foundry enables containers to work.

In the past, at least in most enterprises, if you wanted infrastructure you would likely need to work your way through the circles of provisioning hell. Often the process looks something like this:

1. Request a server or VM to be provisioned or purchased.
2. Wait until that server or VM was provisioned.
3. In the meantime, you need to get to work building the app. So either,
   1. Find a box you can temporarily run under your desk as your app sandbox.
   2. Or, break out the credit card and provision some compute from a public cloud provider as a stopgap.
   3. Or, leverage some version of shadow IT that your organization turns a blind eye toward while the normal IT process runs the official gauntlet
4. Get the server racked in the data center or the VM spun up.
5. Get access and credentials to ssh and log in to the box.
6. Discover issues with the configuration.
7. Request remediation of the issues by the operations team.
8. Once everything is in order, install and configure your application runtime environment and middleware.
9. Finally, after week, months, or years, deploy your application to deliver the business or mission value it promised.
10. Find out that you are under-provisioned to handle demand -- then quickly start the process over again to get more capacity and compute to keep the app online and available as it grows.
11. Learn your lesson and always order way more capacity than you think you'll need, just in case, because it takes too long to bring more online once you're in production.

The last step is very common in large organizations with lots of processes and red tape. And, often as a result of protecting the scarce resources of servers racked in the data center and watts guzzled by those additional servers, organizations wind up vastly over-provisioned, meaning that they have more capacity taking up square footage in the data center than they need. In some organizations where this has been measured, the over-provisioning can be well over 40%. That is to say that over 40% of the racked servers can be un-racked and taken offline with no effect on the ability of the organization to provide a good home from which applications can serve their users.  

This would be an entirely avoidable situation if it were not for the hard climb and time required by developers and operators to get through the process and red tape. The psychology that takes over is one of having long-lived pets. Because of the tremendous effort required to get these servers or VMs, developers in this situation always ask for more than they think will meet their immediate needs. They become attached and even if some of these servers have nothing on them yet, they defend them and protect them from reclamation, and rightfully so.

In large organizations, perhaps the hardest part of application development is getting into production. It is not unexpected in organizations of scale to wait a whole month, driving through road blocks step by step, until the production infrastructure is provisioned and has a dial tone to then finally deploy your application to the world. Cloud Foundry shortcuts that on the infrastructure side, but often there is still some much-needed improvement on the process red tape.

Part of the solution is to get rid of the servers as pets worldview that feeds this behavior. Containers are a good answer to this challenge. This is because they can be treated as disposable things that can be re-spun very quickly to enable our applications to scale-out automatically when demand is high and then scale-in once that demand dissipates, thus, always right-sizing our compute capacity and energy consumption to what we actually need at the time, and, eliminating the fear and headaches that one must always run through the thicket of ticket jungles to get more capacity when we need it.

Containers are ubiquitous in the cloud discussion. A good definition comes from Amazon Web Services (AWS):

Containers are a method of operating system virtualization that allow you to run an application and its dependencies in resource-isolated processes. Containers allow you to easily package an application's code, configurations, and dependencies into easy to use building blocks that deliver environmental consistency, operational efficiency, developer productivity, and version control. Containers can help ensure that applications deploy quickly, reliably, and consistently regardless of deployment environment.

Source: AWS, What are containers? (https://aws.amazon.com/containers/) 

Containers are great, but orchestrating and managing rolling security patches and upgrades without downtime is a very hard problem in most scenarios, leaving our applications open to vulnerabilities and exposing us to risks we may be unwilling to take.

Cloud Foundry makes containers work better by orchestrating them automatically. It does all of the difficult things that containers need to keep them updated, patched, happy, and healthy -- and, all with zero downtime. There are few other container-based PaaSes that can do this well in an enterprise or mission-critical setting at the current time.

Cloud Foundry containers are standards-based. The specification comes from the Open Container Initiative (OCI) (https://www.opencontainers.org). The OCI is a consortium of highly-visible organizations like Docker, Dell Technologies, Microsoft, IBM, Google, Red Hat, etc. that serve as the keeper of the flame for the runC library that Cloud Foundry uses as its primary container runtime library for Linux-based nodes. Commitment to this container interoperability standard by a wide variety of players enables Cloud Foundry to do interesting things to leverage the standard and expand the capability of the platform. For instance, Cloud Foundry can run Docker images from Docker repositories, such as Docker Hub. For more information, see https://github.com/opencontainers/runc.

This enables Cloud Foundry to run everything on Linux and Windows (any .NET core and most .NET classic) applications, to loading and running pre-baked Docker images with specific app runtimes and configurations.

Pivotal Cloud Foundry™ or Pivotal CF™, commonly referred to as PCF, is currently the leading enterprise PaaS powered by Cloud Foundry. Many of the companies that comprise the Fortune 1000 use Pivotal Cloud Foundry internally as a part of their cloud portfolio offering. Using this particular Cloud Foundry distribution, they build their own cloud-native applications and migrate existing applications so that they can leverage many of the benefits of moving to a PaaS. It is because of this deep enterprise penetration and the higher likelihood of encountering Pivotal Cloud Foundry within the confines of business, government, and organizations that we will discuss some of the additional capabilities Pivotal Cloud Foundry provides above the open source Cloud Foundry release.

Pivotal Cloud Foundry delivers an always-available, turnkey experience for scaling and updating PaaS on multi-cloud public, private, or hybrid infrastructures such as VMware vSphere, Amazon Web Services, Google Cloud Platform, Microsoft Azure, and OpenStack.

As a commercial distribution of Cloud Foundry, it provides several significant additional features and a commitment to support the product that organizations are accustomed to from vendors. For instance, Pivotal Cloud Foundry provides extra tools to simplify installation and administration not included in the open source software product.

For instance, should you want to install a Cloud Foundry distribution on your own infrastructure, you would do the following at a high level:

1. Set up all external dependencies, such as an IaaS account, external load balancers, DNS records, and any additional components.
2. Create a manifest to deploy a BOSH Director.
3. Deploy the BOSH Director.
4. Create a manifest to deploy Cloud Foundry.
5. Deploy Cloud Foundry.

This is initially a manual process that requires a good deal of BOSH and platform engineering expertise, although any platform engineer worth their salt would typically begin to automate a good deal of this process. However, it can be very difficult to get the distributed configuration of a large system composed of a variety of multiple VMs, network components, compute, IaaS access, storage, DNS, SSL certificates, and so much more described properly within the manifest file you must define, which BOSH then uses to build the Cloud Foundry foundation. Even getting to the starting line requires creating a manifest to deploy a BOSH Director which can be difficult if you are unfamiliar with the inner workings of BOSH; an interesting topic to be sure, but also deep and complex with a steep learning curve and commitment.

Building upon the foundation provided by the open source Cloud Foundry release (https://github.com/cloudfoundry/cf-release), as one might expect, Pivotal Cloud Foundry adds many features atop of the open source version that have been driven and shaped by the needs of enterprise, government, and organizations to simplify the administration and day operations of Cloud Foundry.

Without belaboring the finer details of the differences between the open source and Pivotal distributions of Cloud Foundry, there are a few differences that are worth highlighting.

As mentioned previously, a good deal of expertise in BOSH is a prerequisite to installing the open source version of Cloud Foundry. Pivotal Cloud Foundry provides a simplified web-based UI for installing and managing the installation of Cloud Foundry and various components, such as the CF Application Runtime, and other services such as RabbitMQ, Redis, MySQL, and so forth as simplified service tiles. Ordinarily, each would require their own BOSH installation and manifest creation to deploy in a coherent way – a rather significant challenge if done manually. This UI is called Ops Manager and enables zero-downtime upgrades for the platform and services, along with simplified maintenance and changes to the deployment configurations underpinning the Pivotal Cloud Foundry Foundation.

A second significant difference between the open source and Pivotal versions of Cloud Foundry is developer-centric. Apps Manager is an administrative UI that enables developers to access many of the capabilities of the Cloud Foundry CLI in a more intuitive way. Apps Manager provides a visual way to configure and manage many of the critical features necessary to handle the daily ins and outs of managing your applications for scale, performance, settings, services, logging, and integrations such as autoscaling that are only available with the Pivotal Cloud Foundry distribution.

The Pivotal Cloud Foundry distribution provides additional support for cloud-native applications via much of the NetFlixOSS functionality under the guise of Spring Cloud and Spring Cloud Services (SCS). This provides common pattern implementations that enhance resilience, ease of configuration, and high availability in the applications you design and deploy to Cloud Foundry, including service coordination and discovery, circuit-breaker patterns to prevent downtime, and other patterns that are particularly useful for microservices.

Another notable feature of the Pivotal distribution is the PCF Metrics dashboard, which presents easy access and visualizations of recent application events, metrics, and logging.

Pivotal Cloud Foundry components and what they do include:

• Ops Manager: A web interface for installing, configuring, upgrading, and scaling Pivotal CF and Pivotal Services
• Apps Manager: A web interface for working with Cloud Foundry and managing orgs, spaces, users, apps, services, routes, and so on
• Pivotal Cloud Foundry Metrics: A dashboard monitoring, event and logging component for applications running in PCF
• Pivotal Services: Managed services including autoscaling, MySQL, RabbitMQ, Redis, Spring Cloud Services, and so on

In addition to the commercial offering of Pivotal Cloud Foundry, the Cloud Foundry Foundation certifies additional platform providers to ensure consistency in the core Cloud Foundry components to ensure portability. The Cloud Foundry Certified PaaS certification requires certified offerings to actually use the software released by the Foundation’s project teams. For more details on Cloud Foundry Certified Platform Providers, please see https://www.cloudfoundry.org/provider-faq/.

A partial list of provider offerings include:

• AppFog from CenturyLink (https://www.ctl.io/appfog/): CenturyLink’s platform based on Cloud Foundry.
• Atos Cloud Foundry (https://atos.net/en/solutions/application-cloudenablement-devops): A commercially licensed and managed Pivotal Cloud Foundry.
• GE Predix (https://www.predix.io/registration/): An industrial internet offering of Cloud Foundry for IoT (Internet of Things devices) and analytics.
• IBM Cloud (https://www.ibm.com/cloud/): IBM’s cloud platform based on Cloud Foundry, which provides access to IBM services, including Watson. Formerly called IBM Bluemix.
• Pivotal Web Services (https://run.pivotal.io/): Pivotal’s public Pivotal Cloud Foundry. A fully managed version of Cloud Foundry that runs on a public cloud.
• SAP HANA Cloud Platform (https://cloudplatform.sap.com/capabilities/runtimes-containers/cloud-foundry.html): SAP's HANA cloud platform based on Cloud Foundry, which provides access to SAP services.
• Swisscom Developer Portal (https://developer.swisscom.com/): Swisscom’s Application Cloud. A fully managed version of Cloud Foundry offered on a public cloud that stores all of your data in Switzerland.

A comprehensive list of Cloud Foundry Certified Platform Providers and their offerings can be found at https://www.cloudfoundry.org/how-can-i-try-out-cloud-foundry-2016/.

We explored how Cloud Foundry simplifies the development and deployment of scalable applications that are highly available. Focusing less on operational and administrative concerns of the platform enables application developers to instead transfer that effort into writing better code and improving the value of the features that make up the application.  

We touched on a cloud-native application design which allows developers to take full advantage of a Platform as a Service (PaaS) like Cloud Foundry. And, found that leveraging Cloud Foundry opens up the possibility of quickly autoscaling applications to meet surges in demand while providing other benefits like zero-downtime deployments that would be difficult to accomplish in a traditional middleware-deployed environment.

Finally, we discussed some high-level differences between our open source Cloud Foundry distribution and a popular commercial distribution called Pivotal Cloud Foundry among other offerings that are available generally.