Matt Stine

Docker for Developers

“Docker is an open-source engine that automates the deployment of any application as a lightweight, portable, self-sufficient container that will run virtually anywhere.” Docker creates containers that provide running process with:

• an equal slice of CPU
• a maximum memory quota
• its own process ID (PID) namespace
• its own network interface
• its own private root filesystem

It does this by leveraging low-level Linux kernel primitives like cgroups and namepaces. The end result is a portable application container that can run anywhere Docker can run, including on VMs, bare-metal servers, OpenStack clusters, public instances, or combinations of the above.

Deploying Distributed Systems with BOSH

BOSH was originally developed to be the toolchain that installs and manages the Cloud Foundry runtime, which is a large distributed system consisting of multiple components running on multiple virtual machines. In order to deploy and manage such a system, you need elements of:

• configuration management tools, such as Puppet and Chef
• orchestration tools, such as Mcollective and RunDeck
• knowledge of multiple IaaS layers (compute, storage, networking) to support portability
• health management
• monitoring and reporting
• etc.

Functional SOLID

Robert Martin assembled the SOLID family of principles to provide a useful guide to help us create object-oriented software designs that were resilient in the face of change. In recent years, the need to write highly-concurrent software in order to leverage increasingly ubiquitous multicore architectures, as well as general interest in more effectively controlling complexity in large software designs, has driven a renewed interest in the functional programming paradigm. Given the apparent similarity in their goals, “What is the intersection of SOLID with functional programming?” is a natural question to ask.

Cloud Foundry Deep Dive, Part 1: The Developer Experience

In recent years, the cloud has gone from Larry Ellison's “Maybe I'm an idiot, but I have no idea what anyone is talking about,” to Microsoft's “TO THE CLOUD!” to a central part of many companies IT strategy. At the same time, the way that we consume the cloud has continued to evolve. Many of today's cloud efforts revolve around utilization of various “infrastructure as code” products (e.g. Puppet and Chef) and homegrown automation to create deployment pipelines. When we start at this level, we often end up reinventing many of the same wheels as we climb the abstraction ladder.

Platform as a Service (PaaS) offerings are positioned to allow developers (and operators) to start climbing the abstraction ladder from a higher rung, shifting the model from machine-centric deployment to application-centric deployment. This session will focus on life as an application developer using Cloud Foundry as a PaaS, with demos using Pivotal's Hosted CF at http://run.pivotal.io.

Cloud Foundry Deep Dive, Part 2: Architecture and Operations

This session will focus on how you can build your very own Cloud Foundry private PaaS running in your own data center or on AWS or even on OpenStack on your own Mac mini. You will learn how the Cloud Foundry BOSH tool constructs a full Cloud Foundry instance from a bare bones virtual machine and continues to coordinate and manage the entire PaaS cloud once it is operational.

Cloud Foundry Deep Dive, Part 3: Enabling Continuous Delivery

One of the great features of a PaaS platform like Cloud Foundry is the simplicity that it brings to the deployment. This simplicity aids us in creating powerful continuous delivery pipelines, which allow us to prove our ability to deliver working software at any time. In this session will examine specifically how to leverage Cloud Foundry as part of such a pipeline, looking at tools and techniques such as:

Cloud Foundry Deep Dive, Part 4: Custom Buildpacks and Data Services

One of the most powerful features of Cloud Foundry is its extensibility. Cloud Foundry has two primary extension points:

1) Buildpacks - by following the buildpack model first popularized by Heroku, the Cloud Foundry platform was designed to be application runtime agnostic, and the platform provides the same services to an application regardless of it being implemented using Java and Spring, Ruby and Rails, JavaScript and Node.js, or any other language/framework combination. Cloud Foundry users can easily implement their own buildpacks by following a specification that exposes three basic scripting endpoints.

2) Services - the Cloud Foundry platform exposes to developers a consistent user experience for external service interaction through the idea of “creating” and “binding” services. This is easiest to see through the idea of first “creating” a database and user role within an existing PostgreSQL or MySQL cluster and then “binding” the proper credentials to my application's environment so that I can connect to and consume that database instance. This is made possible by the Cloud Foundry service broker API, a set of REST endpoints that are consumed by the Cloud Foundry Cloud Controller to orchestrate the necessary steps for a given service.

Programming with Immutability

For much of the last two years I've delivered a two-part series at NFJS shows entitled “Effective Java Reloaded.” For all pracical purposes, it is an ala carte style rehash of the book Effective Java, written by Josh Bloch. One of my favorite parts of the discussion is of Item #15, which tells us to “Minimize Mutability.” If we turn this inside out, we're actually saying that we want to MAXIMIZE IMMUTABILITY. When we do this, we reap many benefits, such as code that is easier to reason about and that is inherently thread-safe. This can carry us a long way in the direction of program correctness and decreased complexity. However, when we start to program with immutability, several major questions arise.

A Java Dev Learns to Go

The Cloud Foundry engineering teams have steadily increased their use of the Go programming language (http://golang.org) for building (or rebuilding) components, starting with the Router, and progressing through Loggregator, the “cf” CLI, and more recently the Health Manager 9000.

As a Java-developer-turned-DevOps-junkie focused on helping our customers and community succeed with Cloud Foundry, it's become clear to me that I need to add Go to my knowledge portfolio.

Failure is the Only Option

Even taking into account everything that we've learned about operating at “web scale” in the last several years, most applications are designed and implemented to be, as Michael Nygard highlights in his book Release It!, “feature complete” not “production-ready.” Unfortunately, the architectural patterns associated with operating at scale – notably the move toward “micro-services” – introduce an order of magnitude more ways in which our applications can fail. If we do not plan well for failure, we will experience the ultimate failure. But if we do plan well for failure, we have a fighting chance at success.