Matt Stine

A Java Dev Learns to Go

8:30 PM MDT

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.

Go is a very interesting language, open-sourced by Google in late-2009, that takes a “less is more” (http://commandcenter.blogspot.de/2012/06/less-is-exponentially-more.html) approach to language design, but that also bakes in a powerful concurrency model.

This talk will introduce Go, delve into its distinctives, and contrast its approach with that of Java (where appropriate). We'll also write a fair amount of Go code along the way. This talk will be of particular interest to Java developers looking to add Go to their toolkits, but will also be of interest to anyone looking to learn a little bit more about Go.

Functional SOLID

9:00 AM MDT

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.

In this talk, we'll explore this intersection. We'll begin with a tour of the evolutionary patterns associated with enterprise software and programming paradigms, as well as take a look at the ongoing quest for best practices, the goal being to elucidate the motivation for examining this intersection of SOLID and functional programming. We'll then walk through each of the SOLID principles, examining them in their original object-oriented context, and looking at example problems and solutions using the Java language. Then for each principle, we'll examine its possible intersection with the functional programming paradigm, and explore the same problems and solutions using the Clojure language. We'll close by examining the transcendent qualities of the SOLID principles and how they can make any design simpler, regardless of the programming paradigm employed.

Programming with Immutability

11:00 AM MDT

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.

First, the necessity of using a separate object for each distinct value, never reusing, or “mutating” an object, can quickly cause performance concerns. These concerns are amplified when we're talking about large collections such as lists and maps. These problems are largely solved by what we call “persistent data structures.” Persistent data structures are collections from which we create new values, not by copying the entire data structure and apply changes, but by creating a new structure which contains our changes but points at the previous structure for those elements which have not changed. This allows us to work with data structures in a very performant way with respect to time and resource consumption. We'll examine persistent data structures, their associated algorithms, and implementations on the JVM such as those found in the TotallyLazy library.

Second, because all of an immutable object's state must be provided at the time of construction, the construction of large objects can become very tedious and error prone. We'll examine how the Builder pattern can be applied to ease the construction of large objects, and we'll examine Builder implementations in Java and Groovy.

Third, we run into problems when we start to use frameworks that expect us to program in a mutable style. A prime example is Hibernate, which expects our persistent classes to follow the well-worn JavaBean convention, including a no argument constructor and getters and setters for each property. Such a class can never be mutable! So how do we program with frameworks such as Hibernate and yet still minimize mutability? The key is found in not letting frameworks dictate the way that you design your code. Just because the framework require something, don't let it force you to make the wrong decision. Use the framework as a tool to write your code, don't let your code be a tool of the framework. We'll examine strategies for doing exactly that.

You should come away from this talk better equipped to program in a way that minimizes mutability and maximizes immutability.

Docker for Developers

3:15 PM MDT

“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.

Containers are an excellent way to package your application such that it can run consistently everywhere you want to run it, a fantastic step toward Continuous Delivery. In this session we'll look at how to use Docker to package, deploy, and run Java applications and other services. We'll also compare Docker to another container solution, Warden, which is a key component of the Cloud Foundry PaaS.

Deploying Distributed Systems with BOSH

5:00 PM MDT

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.

Fortunately, BOSH was written in such a way that it can be used to deploy not just Cloud Foundry, but any distributed system. Teams in multiple organizations are using it today to deploy:

• large-scale Jenkins deployments
• Hadoop clusters
• Cassandra and other NoSQL store clusters
• RabbitMQ and other message broker clusters

In this session we'll learn how to develop a BOSH release using the bosh-lite tool. We'll then learn how to create a deployment manifest, which maps our release to a specific infrastructure environment. Finally, we'll deploy our release to Amazon Web Services.

Failure is the Only Option

7:30 PM MDT

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.

This talk will take a tour through the James Chiles' book Inviting Disaster: Lessons From the Edge of Technology, and examine what we can learn from engineering fields in the physical world, applying those learnings to the way in which we develop fault tolerant applications.

Cloud Foundry Deep Dive, Part 1: The Developer Experience

9:00 AM MDT

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.

We'll cover the following topics:

• Hello World: Pushing Java, Ruby, and Node.js apps
• Service Binding: Talking to DB's and other services
• Buildpacks: Flexible application runtime stacks
• “Places to Put Your Stuff”: organizations and spaces
• Promotion Pipelines: Dev to Test to Prod
• Scaling: From 1 instance to 100 instances in 30 seconds or less!
• Health Manager: No more 2 AM support calls…
• Blue-Green Deployments: Zero downtime for your users
• Deploying Cloud Foundry in YOUR data center
• It's Open Source and YOU can contribute!

Cloud Foundry Deep Dive, Part 2: Architecture and Operations

10:45 AM MDT

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.

If you want the convenience of developing against your own private custom PaaS within your company, then this session will give you all the steps you need to get started.

Cloud Foundry Deep Dive, Part 3: Enabling Continuous Delivery

1:30 PM MDT

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:

• Integration with Maven and Gradle
• Integration with Jenkins
• Deep-dive into Cloud Foundry application manifests
• Zero downtime deployments
• Integrating micro services architectures and environment-specific configurations using user-provided services
• Orchestrating the Cloud Controller using the REST API and Java Client Library
• Building a “check-in to continuous deployment” pipeline

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

3:15 PM MDT

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.

In this session we'll learn how to:

• use Heroku buildpacks on Cloud Foundry
• use Cloud Foundry buildpacks on Heroku
• customize existing buildpacks
• author new custom buildpacks
• create service brokers
• deploy service brokers
• test service brokers