Matt Stine

Containers: What Every Developer Needs to Know about Docker & More!

Containers have been a feature of the Linux kernel since 2007, and were in use behind the curtain at Google well before then. But developers, for the most part, did not know about or use them. Enter Docker in 2013, and all of a sudden if you're not using containers, you're no longer playing with the cool kids. Is it all hype? Or will you be deploying your applications in containers before you know it? This workshop will arm you with what you need to know and give you hands-on practical experience with container technology.

Docker I

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

Docker II

Building and running container images isn’t enough. There are very real problems that we still have to solve:

• how do we schedule and run these containers on infrastructure?
• how do we create networks that can link these containers across multiple hosts?
• how do we handle data that needs to persist across container restarts?
• how do we handle concerns like service discovery and load balancing?

These concerns are the focus of much of the development work being done in the Docker ecosystem today.

Building 12 Factor JVM Applications

Modern applications are changing as we embrace the engineering practices associated with Continuous Delivery and DevOps, migrate our applications to modern cloud platforms, elastically scale applications with the dynamics of customer demand, and embrace microservices architectures. The Twelve-Factor App is a collection of application development patterns developed by Heroku engineers that aim to support these types of architectural and cultural change.

Advanced Data Architecture Patterns

As we move toward microservices, we learn to properly decompose not only our behavior model, but also our data model into bounded contexts. This data decomposition is not without consequences. By placing strict boundaries around ownership of domain concepts, we make it more difficult to refer to concepts that naturally want to cross these boundaries. How do we “denormalize” these entities effectively? How do we keep these representations in sync? What do transactions look like? How do we ask BIG questions that span multiple contexts? These are the questions that we’ll dive into in this session.

Microservices Testing Strategies

Microservice architectures place great emphasis on autonomous product teams that develop and deploy equally autonomous services using decentralized release management, testing, and deployment strategies. I don’t have to wait on you to deploy my service, and you don’t have to wait on me. And yet the complexity associated with managing these large, distributed systems seems like it would demand even greater discipline and centralized coordination of testing activities. Fortunately, while greater discipline is in fact required, we don’t require the centralized coordination that would seem to destroy many of the benefits of embracing microservices. In this session will examine principles and practices that will help us develop an effective testing strategy for microservices.

Monitoring and Metrics and Logging: Oh My!

Visibility is one of the primary characteristics of applications that aren’t just coded well, but run well in production. We need visibility to understand:

• how our system performs
• how our system misbehaves
• how our system fails
• how our users interact with our system
• what’s providing value to users and what’s not
• and more!

In this talk we’ll look at the three disciplines of monitoring, metrics, and logging, and see how properly used, they can dramatically increase our system’s inherent visibility.

Go Programming for Java Developers

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.

Building Distributed Systems with Netflix OSS and Spring Cloud

With the advent of microservice and cloud-native application architectures, building distributed systems is becoming increasingly common for the enterprise Java developer. Fortunately many of the innovators in the space, including Twitter, LinkedIn, and Netflix, have embraced the JVM as they’ve built increasingly complex systems, with Netflix open-sourcing much of its toolkit for constructing these systems at NetflixOSS.

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems. Many of these patterns are provided via wrapping the battle-tested components found at NetflixOSS.

Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer's own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.

Concourse: CI that scales with your project

Concourse (http://concourse.ci/) is a CI system composed of simple tools and ideas. Concourse can express entire pipelines, integrating with arbitrary resources, or it can be used to execute one-off tasks, either locally or in another CI system. Concourse attempts to reduce the risk of adoption by encouraging practices that keep your project loosely coupled to the details of your continuous integration infrastructure.