My passion is taking a metaphysical approach to software engineering: what is the nature of the collaborative game that we continuously play, and are there better, more contextually-aware ways to play that game?
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.
Cloud-native architectures combine the unique aspects of cloud platforms with the principles of DevOps and Continuous Delivery to enable the rapid development, deployment, and management of applications. As the speed of innovation becomes one of the key drivers of business success, these architectures ensure teams are able to meet the need of the business, to move quickly, while at the same time ensuring important non-functional characteristics like availability and scalability.
Many of the innovators in this space, including Amazon, Twitter, LinkedIn, and Netflix, leverage small, autonomous teams which focus on business capabilities and build twelve-factor style, microservice applications. Microservices integration is achieved via lightweight, decentralized, and choreographed point-to-point interactions rather than the heavyweight, centralized, and orchestrated ESB-style integration found in traditional SOA.
With the advent of cloud-native architectures, building distributed systems will become increasingly common for the enterprise Java developer. Fortunately many of these same innovators 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.
Cloud Foundry and Spring provide open source framework tooling and platform services for developers to quickly build some of the common patterns in found in distributed, cloud-native systems. Many of these patterns are provided by the Spring Cloud project, which wraps many of the battle-tested components found at NetflixOSS with the Spring programming model, and provides easy deployment of NetflixOSS services to Cloud Foundry.
In this class the learner will have the opportunity to practice working with cloud-native architectures using Spring and Cloud Foundry.
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.
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.
Topics to include:
What is fragile? Fragile things are easily broken, damaged, or destroyed. When faced with stressors, they crumble. Then what is the opposite of that? Many of us would answer something like “robust” or “resilient.” Things that maintain their integrity when faced with stressors. But it’s possible that we’re wrong.
In his book Antifragile, Nassim Nicholas Taleb challenges this idea by inventing the word that forms the book’s title. Antifragile is the true opposite of fragile. Whereas fragile things are easily broken, damaged, or destroyed when faced with stressors, antifragile things improve, become stronger, or become more powerful when faced with stressors.
Can we build software systems like this? Dick Gabriel explores the idea of ultra-large scale systems that self-regulate (and in fact thrive) in the face of unexpected changes and stressors in his essay “Design Beyond Human Abilities,” and Russ Miles explicitly calls out the idea of Antifragile Software in his book by the same name. During this session we’ll explore these ideas and what they mean to us as developers and architects.
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.
While microservices may be smaller than some of their architectural cousins, that doesn’t mean that testing the internal components of a microservice takes a back seat.
In this presentation we’ll walk through the test-driven workflows that you can use to build a well-factored microservice.
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.
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.
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.
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.