Cloud Foundry Day at KubeCon + CloudNativeCon North America

When we think about establishing a Kubernetes capability for our organization, our instinct, or perhaps just habit, might lead us to stand up a single cluster that will then be a shared resource across numerous tenants. Kubernetes offers namespaces that are intended to carve up the capacity across different users or groups of users. And while this may work well in some scenarios, it does impose certain constraints and limitations on its use. For example, it is well understood that the multitenancy in Kubernetes is soft, meaning it does not guard against deliberately malicious attacks from one tenant to another.
 
If instead, we align tenant boundaries to Kubernetes clusters, effectively creating many single tenant clusters we can not only avoid certain limitations but we gain some significant advantages.  Add a control plane for managing these sets of clusters and we have a powerful solution built on decades of maturity in machine virtualization.
 
In this session, we will present both models, multi-tenant clusters and multi-clusters and study the tradeoffs of each.

You will learn,
- How to leverage Kubernetes along with your CF installation, and wondering what.
- Use CF for what its great at and compliment it with power of kubernetes  
- How Predix created a complete PaaS where both stateless and stateful workloads can run in harmony.
- How to add standardization for service catalog, with OSB and marketplace.
- Standardize operation with single tool to provision and run them all BOSH.
- How to maintain tenancy in kubernates + cloud foundry PaaS.

And above all we will share our experiences about what worked for us and what not turned out so well.

The Open Service Broker API gives developers the power to consume services from different cloud providers on different cloud platforms. This talk will show the power of this specification in action. We will show a single application deployed to Cloud Foundry that uses a service from Google Cloud, a service from Microsoft Azure and a service from IBM Cloud. We will then take the same application and deploy it to Kubernetes and use the same set of services.

Platform and Container as a Service layers (PaaS/CaaS) enable developers to deliver the functionality of their code to end users in a fast way and have become the standard for microservice deployment.
One decision the developer has to make here is which abstraction layer to use for deployment - container or application.

Kubernetes and Cloud Foundry are very popular options to deploy and run Spring Boot Microservices successfully by providing the 2 approaches. But what does it really take to get your application and required backend services up and running successfully on
either platform? How many configuration steps are in fact required and where are the hidden pitfalls? How easy do you scale, recover from failure or update the application without downtime? What kind of a difference does the level of abstraction "Bring your
own code vs. Bring your own container" mean in the end?

In my role as Cloud consultant and university lecturer for distributed systems I come across these topics a lot and want to share my experience with this talk. I will analyse the differences between the
two platforms as seen from a developer's perspective from getting started to running successfully. The comparison is based on a Spring Boot sample app. The talk includes a live demo of those steps.

Using the power of BOSH, bosh CF and Kubernetes are transformed into an easy to deploy and manage solution.  Learn how BOSH with CFCR enables:
- easy updates with stemcell OS image security patches
- how to mix on prem and public cloud into your k8s deployment during peak usage time
- built in monitoring to keep your day 2 operations running smoothly with automatic recovery of detected failures
- scaling up or down your deployment with a single command
- linking together CF and Kubernetes using the new links API and dynamic DNS featuresNew features of BOSH can enable some powerful benefits for operators who make use of them. This talk intends to energize operators and enable them to make use of these benefits in their day to day operations to make their deployment of CFCR Kubernetes and Cloud Foundry respond to demand, while remaining stable and secure.

Concourse is an open-source CI/CD system that helps automate your build, test and delivery processes.  It is the most popular CI/CD tool for Cloud Foundry but it can also be easily used for Knative. This talk will demonstrate how to use Concourse to automate your end to end software release process for applications running on Knative. The improved development experience will be built up in Concourse using a sample serverless application and leveraging Knative’s Build resource and Buildpacks. The demonstration will walk through each of the steps needed to do automated testing, and subsequent automated deployment, all triggered from a single git push. 

The National Institute of Standards and Technology (NIST) released a lengthy paper on September 2017 that detailed a set of recommendations for container security. This talk will shed some light on the core insights that the report stressed, such as using container specific tooling to monitor for vulnerabilities as well as opinions about how to implement them, from a Cloud Foundry centric perspective.

Is container scheduling commoditised yet?? :-)

The Eirini project (now an “official” incubator project in the CF Runtime PMC) is bringing pluggable container scheduling to the Cloud Foundry Application Runtime. In other words: the `cf push` developer experience we all love, with your choice of container orchestrator - including Kubernetes - under the covers.

This session will introduce the Eirini project, talk through the reasons behind it, and tell you what it means for your developers (not much) and your operators (for many of them, quite a lot!).

We’re also going to demo getting up and running with Eirini on Kubernetes using a single Helm chart. This way you - and your Kubernetes-loving friends and colleagues! - can try out the `cf push` developer experience, going from code to first-class Deployments, Pods and Services in your existing Kubernetes cluster, all in a single command!

Today, Cloud Foundry users use OSBAPI volume service brokers to provision and attach storage to apps running in the Diego runtime.  Using service brokers gives application developers a clear and user friendly way to discover and use volume services, just as they would use any other service in the service catalog.

The Eirini project gives Cloud Foundry a way to schedule and run apps using K8S instead of Diego, while maintaining the same developer friendly workflow.  But so far, while it is possible to create and bind regular services to your applications with Eirini, it has not been possible to use volume services.

In this talk, we will explore how the Volume Services workflow can be enabled when CF is using K8S to schedule its containers.  We will look at how the CF cloud controller, the OSBAPI service broker, Kubernetes, and the Container Storage Interface (CSI) volume plugin can be wired together to allow an application developer to easily find and use volume services in a service catalog.

"Here's my code, run it in the cloud for me, I do not care how" - the famous Cloud Foundry Haiku - can now be adopted to native Kubernetes thanks to project Eirini.
Unlike other Cloud Foundry (CF) and Kubernetes (K8s) integration projects, Eirini - a CF incubation project - really tackles integration deep in the guts of the system - at the scheduler level, where "container compilers" like CF and "container orchestrators" like K8s meet. K8s is a world-class container scheduler, but kubectl isn't really the first choice for a developer. K8s is moving in that direction now with project Knative, but even compared to that CF still provides a higher developer abstraction, letting developers focus on stateless apps and rapid development. In this talk, we'll present project Eirini which under the covers converts CF apps into first-class K8s deployments and keeps them in sync: The best of both worlds. We'll also talk about what this means now that project Knative is out. 

As container technology is becoming the standard choice for cloud platforms, it is essential to compare various container technologies. The popular choices of Kubernetes and Cloud Foundry are major topics in the Cloud industry: What is their role, how they differ, and how they compliment each other in a modern Cloud application deployment?

The IBM Offering Managers for IBM Kubernetes and IBM Cloud Foundry will discuss these questions and draw conclusions about how these important technologies compliment each other and their futures together.

Creating a commercial Cloud Foundry distribution for a containerized environment brings up a number of challenges. Drawing on real-world experience providing a commercial Cloud Foundry distribution in which the entire stack runs on top of Kubernetes, this session summarizes the history of this style of Cloud Foundry deployment. Sandy and Troy examine some of the advantages of this approach as well as the challenges and solutions, including deploying Cloud Foundry, upgrading and scaling it, providing Cloud Foundry-as-a-Service, and staying in sync with upstream changes. They also describe development currently underway that brings containerized Cloud Foundry more closely in line with recent developments in BOSH.