Cloud Foundry Summit Europe 2018

Join UAA Anchor Jennifer Hamon to learn how you can get up-and-running with the new go-based CLI for UAA. Platform operators and application developers of all levels will leave this talk knowing how manage UAA resources including Users, Groups, Memberships, Identity Zones, and Identity Providers. We will also learn to create and test OAuth2 client configurations and discuss common troubleshooting scenarios. Long-suffering users of the old Ruby-based uaac will be excited to see how we've incorporated user feedback and design thinking into this new cross-platform tool.

Most big companies have invested enormous amounts of time and money in enterprise-scale services during the last decades. Databases, connectivity systems and storage solutions have reached a stability and maturity that is at the heart of mission-critical IT.
 
CloudFoundry has brought agility and to the Application tier. 
However, interacting with the 'legacy' services that are required for mission-critical applications is often a hard, manual interaction.
To lay bare the potential of these valuable services, companies must bring them to 21st century and make them consumable and manageable in a self-service manner.
 
The OSBAPI is an ideal technical approach to bridge this gap.
Born within CloudFoundry, it is now being adopted as an open standard by different platforms.
 
Swisscom decided to not only use OSBAPI for its CloudFoundry offering but to build a marketplace that is used for all kind of consumers, from IaaS to on-premise workload. The marketplace offers access to various types of services such as databases, storage, and connectivity.
 
Boban and Matthias tell you about the challenges, obstacles and joys of bridging the old and the new world - which are very often not only technical, but also cultural.

Enterprise customers have a high demand on customizability and extensibility to fit the software they are using to their needs. In the past they had access to central parts of the software and could integrate changes on code level. This is not possible in cloud applications. Sayan Hazra will show in his talk, how Kyma is providing an extension model for cloud applications, leveraging Serverless and containerized technologies.

 

What are the practices and hallmarks of organizations that are running Cloud Foundry at scale? How did they get started? How did they attract hundreds of developers and equip them to deploy thousands of applications?
 
 2017 was a year when more enterprises hit critical mass with their Cloud Foundry deployments. The best part? They shared details of how they did it. Team structures, enablement tactics, target applications… there is a growing body of examples to learn from. But you have to absorb it all! Is there a Readers’ Digest version? Yes. Yes there is.
 
 Wherever you are on your digital transformation journey, learn from your predecessors. In this talk, Dormain Drewitz distills the learnings from several companies using Cloud Foundry. She shares the patterns around strategies, processes, and tactics.

As the projects are growing your team might have to grow too. And now you have to integrate new developers.

 Or you are new to a cloud-native team and feel lost with all the new technologies.
 The speakers want to discuss in the community how to organize project onboardings in Cloud Foundry-based development projects.

 From “how to set up the development environment” to getting someone new hyped for Cloud Foundry, they want to share their experiences, do’s and dont’s and invite others to share their own.

Kubernetes offers an extensive set of features that can provide for different purposes, ranging from test deployments on localhost to deployments with heavy ML computations on GPUs. It can get overwhelming to figure out the specific features, or combinations of features, which may be needed for making a secure and resilient service. CFCR is an open source wrapper around Kubernetes that provides an opinionated K8S deployment, leveraging BOSH functionalities like scaling and self-healing. It offers a subset of Kubernetes features enriched by some functionalities of BOSH, and facilitates an easy learning curve. In this talk, we intend to explore what can make a K8s cluster ‘production ready’ for different business and how CFCR helps reduce the complexity of spinning a K8s cluster and surface only the most commonly used features.

Since BPM debuted last year, nearly all of the release in cf-deployment are converting to use BPM, and v1.0 is available. This talk will discuss BPM’s evolution over the past year, why you should convert your release to use BPM, and some cases where BPM might not (yet) make sense. James and Aram will discuss some of the challenges and tradeoffs of adapting BPM for the releases which have been able to adopt it. They will also discuss where we might go in the future so that we more BOSH releases can adopt BPM.
 
 This talk will also look at what future benefits BPM enables for the release-author community. Examples we hope to cover:
 - BPM’s declarative config which enables static analysis of job-process requirements, and could be transliterated into other container scheduling platform formats (ex: K8s pod spec).
 - Bring consistency to the Operator job-process debugging experience.

When looking at business-critical workloads, where downtime represents either massive business impact or a potentially mission-ending event, then high-availability of data services becomes a key business differentiator. High availability is not only about the ability to recover gracefully from an incident, but also the ability to maintain lower local latencies to application users and achieving strong eventual consistency for your geo-distributed data-service. A highly-available, well-integrated and secure data service that can cover a variety of use cases for different applications, is a key benefit to platform and or business owners.
 
 The Redis Enterprise Bosh release for Cloud Foundry platform gives developers a turn-key solution to set up a globally distributed Redis clusters that will handle replication and consistency automatically, using advanced Conflict-Free Resolution Data Type technology (CRDBs).
 
 In this talk, we will cover:
 - Use cases that require an Active-Active database
 - Set-up of geo-distributed Redis clusters across Cloud Foundry foundations
 - Benefits to global application development and operation teams

Until now, authors of BOSH releases have had to package any dependencies their software needed in their release. While this offers great flexibility, it means that for more complex deployments, there is unnecessary duplication of third-party dependencies. This also makes it difficult to patch external dependencies as they are kept in so many places.
 
 One-off tasks are typically packaged as BOSH errand jobs. Until now, running BOSH errands would require spinning up a VM at the IaaS level. That’s costly and can take up to several minutes, depending on the IaaS.
 
 BOSH recently introduced two very powerful features: package vendoring and errand colocation. Attendees will learn how to use them to simplify release package management, make deployments smaller in footprint, speed up operating and upgrading BOSH deployments.

Garden (the Cloud Foundry App Runtime's container engine, optimised for PaaS workloads) saw awesome features bloom over the last year. Garden is the first production runtime to support rootless mode; a wonderful security benefit. Leveraging containerd, Garden now uses more industry standards than ever, allowing for a much more familiar operator experience. The new "Garden Peas" feature enables sidecar containers for Cloud Foundry. This makes the platform more secure and opens the door for cool things like cf ssh, intelligent routing and many more.
 
 As well as introducing the new features, the talk will explain how operators can interact with the runtime container bundles generated by Garden to debug, extend and operate the platform.

Autoscaler (https://github.com/cloudfoundry-incubator/app-autoscaler) helps Cloud Foundry application developers to scale up or down applications horizontally by specifying policy on the consumption pattern of standard container metrics i.e. memory, throughput and response time. The scale up or down of an application is triggered when the crucial application resources are exhausted or under-utilised. For applications running on production, it is not enough to scale them based on only these few standard metrics. For example, an application consuming messages from a message queue (RabbitMQ) needs to scale up when the application is not able to consume enough messages from the queue at a fast-enough rate. Therefore, rather than standard metrics, in this case, queue length should be the decisive metrics for scaling.
 
 The goal of this proposal is to propose the capability to application developers to scale their applications based on custom metrics. This session will demonstrate how an application can emit custom metrics that can be read and understood by autoscaler and used to trigger (auto) scaling when needed.

Creating a BOSH Cloud Provider Interface (CPI) for Kubernetes (Kube) presents a unique challenge since Kubernetes does not try to hide underlying node updates, unlike a typical IaaS like GCP where VMs are transparently migrated between hosts. While it’s relatively easy to map BOSH concepts to Kube and get a CPI that deploys BOSH releases, BOSH has to behave similarly to the Kube Deployment controller and manage Pd Disruption Budgets (PDBs) in order to automatically maintain expected workload uptime.
 
 In this CPI we have solved these issues by taking advantage of existing Kubernetes primitives and connecting them to existing BOSH workflows. Additionally, as we tested the CPI we have also identified places where we can improve aspects of BOSH – e.g., speed and parallelism of resurrection – which as a whole will improve the BOSH toolset on any platform.
 
 In this talk we will present our incubating project and do live demos using it to deploy / update / and use the latest CloudFoundry Application Runtime as well as other releases on Kube clusters. Secondly, we will discuss preliminary results using the CPI on public Kube offerings such as IBM Cloud, GCP, Azure. Finally, we will briefly discuss our development roadmap.