By day I lead a team tasked with taking a first-principles-centric approach to intentionally enabling programming language usage at the largest bank in the United States.
By night I write and teach my way through a masterclass in software engineering and architecture targeting early-career software engineers working in large-scale enterprise technology organizations.
To win the game. More seriously: to get 1% better every day at providing business value through software.
I'm a 22-year veteran of the enterprise software industry. I've played almost every role I can imagine:
I've worked at Fortune 500 companies, a tenacious teal cloud startup, and a not-for-profit children's hospital. I've written a book, and I've hosted a podcast. I've learned a lot along the way, including many things I wish I'd known when I first got started. And so now I want to pass those learnings on to you, especially if you've only just begun your career.
Many of us would love to embrace microservices in our day-to-day work. But most of us don’t have the opportunity to start over with a pure greenfield effort. We have to understand how to refactor our existing monolithic applications toward microservices. Practical steps include building new features as microservices, leveraging anti-corruption layers, strangling the monolith.
In this presentation we’ll go light on the theory and walk through the actual process of turning a strawman monolith into a family of well-factored microservices.
While rummaging through some books the other day, I came across my copy of The Pragmatic Programmer. Flipping to the copyright page, I realized that it had been 16 years since its publication. Many of our careers have been deeply affected by reading and considering the many nuggets of wisdom contained in this book, and it is near the top of multiple recommended reading lists.
In this presentation, we’ll revisit this book, and we’ll also consider what we’ve learned since its publication - what would we change? And what remains timeless?
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.
Concourse optimizes around the following principles:
During this session we'll learn the simple key concepts from which Concourse pipelines are constructed. We'll understand how to deploy a local Concourse cluster using Vagrant as well as a scalable Concourse cluster to your cloud of choice using Cloud Foundry BOSH. Finally, we'll look at basic and advanced examples of pipelines for Java projects.
Over the past year I’ve had the pleasure of wearing the hat of “product manager” for the Spring Cloud Services team at Pivotal, operating using a distributed variant of the Pivotal Labs process. Along the way I’ve learned many valuable lessons that I hope you’ll be able to apply to your product development efforts.
In this presentation we’ll examine the relationship of product management to engineering and to your customer, and how you can be an effective broker between the two groups.
Much is said about the decentralized governance of and local autonomy given to “two pizza teams” build microservices. But how do you organize teams to effectively collaborate to build the eventual composite system?
In this presentation we’ll examine how to apply the Tracer Bullet Development methodology described in Ship It! to effectively construct distributed systems composed of microservices.
Embracing microservices also means embracing distributed systems. Distributed systems carry with them multiple challenges. One set of challenges includes problem of visibility into the behavior of the composite system, understanding that behavior, and being able to isolate the cause(s) of problematic behavior. These challenges can be addressed by applying the techniques known collectively as Distributed Tracing.
In this presentation, we’ll examine the theory of distributed tracing put forth in Google’s Dapper paper, and we’ll look at how this theory is put into practice in the design of Zipkin, an OSS distributed tracing platform.
As we build distributed systems composed of microservices, we introduce new potential performance problems and failure points. As the number of nodes in our system increases, these problems rapidly amplify. In order to keep our composite systems responsive, we can apply the techniques of reactive programming. In order to keep our composite systems healthy, we can apply fault tolerance patterns like circuit breakers and bulkheads.
In this presentation we’ll examine how to leverage two popular libraries from Netflix, Hystrix and RxJava, to create reactive and fault tolerant systems.
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:
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.
Topics will include: