Cloud Foundry / Containers 101

While some other platforms you may have heard of have containers front-and-center as the main user experience, Cloud Foundry uses containers under the covers to provide a rich user experience ("push my code, I don't care how"!). The container engine powering Cloud Foundry is called Garden and pre-dates most of the big name container technologies now in the market. In this talk, you'll find out what makes Garden different from other container technologies (including detailed comparisons of other container engines), and in what ways it's just the same.

Julz Friedman
IBM

George Lestaris
Software Engineer, Pivotal
George Lestaris is a software engineer working at Pivotal in the Garden team, the container runtime of Cloud Foundry. Before Pivotal, he spent time with web programming, high throughput computing and cloud computing research. He has given talks before in CHEP 2013 regarding virtual clusters and their use in high-energy physics and, most recently, in PyCon UK 2015 on interactive cloud experimentation.

Modern applications consist of small, highly interconnected, independently scalable units of deployment that are often referred to as “microservices.” When you deploy these services on Cloud Foundry today, they are forced to communicate via routes that are advertised to the external routing tier. Not only does this force all services to be exposed to external clients, it adds significant latency to the interactions between services.

What if instead of exposing routes to all of your services, you could define the network topology that’s right for your application? How about defining an isolation policy to prevent unauthorized access? What about enabling secure access to existing networks?

The Cloud Foundry Container Networking project hopes to make these things a reality. Come learn about where we are today, where we’re going, and how you can help us get there.

Gabriel Rosenhouse
Software Engineer, Pivotal
Gabe is a software engineer at the Pivotal office in Santa Monica, California. He is currently working on the Cloud Foundry Container Networking team.

Matthew Sykes
STSM, IBM
Matthew is an senior technical staff member in IBM's open cloud technology group. He has been involved with Cloud Foundry since 2013 as part of the elastic runtime and Diego teams. He is currently working on the Cloud Foundry container networking project to enable flexible, efficient, and secure communications between containers and legacy networks. Prior to his work on Cloud Foundry, he worked on IBM application servers and middleware.

Have you heard about Diego for a while now, but wonder what it means to you as an application developer or operator? Have you experienced the magic of pushing an application to Cloud Foundry and want to know what makes it all possible behind the scenes?

Over the past year, the Diego container runtime has made tremendous strides, reaching feature parity with the existing DEA runtime, making its deployments easily upgradable, and scaling to manage larger and larger container workloads. In this talk, the project lead for the Diego team will review the components of the Diego system, how they interact with each other, and how they integrate with existing Cloud Foundry deployments to allow a straightforward transition to the new runtime. We will also discuss how the Diego runtime enables many powerful new platform features, such as CF Tasks, TCP routing, and SSH access to containers, and preview other upcoming features that CF teams are actively working on and exploring today.

After watching this talk you’ll be ready to upgrade to Diego with confidence and take advantage of the many improvements it brings to Cloud Foundry.

Eric Malm
Pivotal Software
Eric works at Pivotal Software as the Product Manager for the CF Runtime Diego team, and prior to that was a software engineer on the Diego team and on the CF Runtime team. He also holds a Ph.D. in Mathematics from Stanford University.

Persistent Storage is coming to Diego! IBM, Pivotal, and EMC have partnered to extend the Cloud Foundry runtime to include persistence storage. We discuss the approach we are taking, how distributed filesystems and block storage services fit well with our service broker abstraction. and how we plan to offer these services in the marketplace. An overview of the types of storage, their differences, and the effect they have on scheduling and the application lifecycle will be discussed. Example use cases for each type of storage will be covered. We will also discuss the pros and cons of running databases and other services directly on Cloud Foundry.

Nagapramod Mandagere
Research Group Leader, IBM
Nagapramod Mandagere received his PhD from University of Minnesota in Enterprise data management. He has been a researcher at IBM Almaden Research center since 2008 working on various systems technologies. He has coauthored several conference papers and has several patents in domain of systems management

Paul Warren
Software Engineer, EMC

Ted Young
Pivotal
Ted has built distributed computer systems in a variety of environments: computer animation pipelines for VFX, live event coordination, and elastic compute platforms. In 2015 he received a Pivotal Research Grant to explore approaches to running persistent workloads in a multi-tenant environment. He is a core contributor to Diego, and heads up the Diego Persistence Team (Persi).

As a distributed container management system, it is important that Diego not only runs containers, but it does so in a quick and timely manner. In small deployments with manageable work loads, it is easy for us to guarantee that Diego adheres to these performance requirements. However, as both the scale of the deployment and the amount of containers increases, it has become increasingly challenging for us to validate that Diego maintains its performance characteristics.

This talk will dive into the steps that we took to design, perform, evaluate, and improve performance testing that has given us confidence in Diego as a backend to Cloud Foundry. Topics will include: how the Diego team designed performance experiments and testing suites given product requirements, how we evaluate a performant Diego environment, results that led to various performance changes in the system, and lastly how the Diego team is continuing to build out infrastructure to validate Diego’s performance at a larger scale on a more regular basis.

James Myers
Software Engineer, Pivotal
James Myers is a software engineer for Pivotal Software and a core contributor to the Cloud Foundry project. James is currently a member of the Diego team and has worked on Cloud Foundry for two years. He has presented previously at the 2015 North American CF Summit on the CF API.

Luan dos Santos
Software Engineer, Pivotal
Luan Santos is a Pivotal developer and core contributor to the Cloud Foundry platform. He is a member of the Diego team, located in San Francisco, CA. He also spoke at the CF Summit 2015 in Santa Clara, CA about the Cloud Foundry API.