Microservices

Failure Isolation

Part 5 of my “Responsible Microservices” series is live! Should that be a Microservice? Part 5: Failure Isolation In the first part of this series, we laid out a set of principles to help you understand when microservices can be a useful architectural choice. We promised follow-up pieces describing each of the factors in more detail. In the fifth post of the series, we explore failure isolation. Digital products don’t live alone.

JAX London 18

JDD

Responsible Microservices

Full Abstract Responsible Microservices These days, you can’t swing a dry erase marker without hitting someone talking about microservices. Developers are studying Eric Evan’s prescient book Domain Driven Design. Teams are refactoring monolithic apps, looking for bounded contexts and defining a ubiquitous language. And while there have been countless articles, videos, and talks to help you convert to microservices, few have spent any appreciable time asking if a given application should be a microservice.

Evolving to Cloud Native

Full Abstract Evolving to Cloud Native Every organization has at least a phalanx or two in the “Cloud” and it is, understandably changing the way we architect our systems. But your application portfolio is full of “heritage” systems that hail from the time before everything was as a service. Not all of those applications will make it to the valley beyond, how do you grapple with your legacy portfolio? This talk will explore the strategies, tools and techniques you can apply as you evolve towards a cloud native future.

Independent Scalability

Part 4 of my “Responsible Microservices” series went live yesterday! Should that be a Microservice? Part 4: Independent Scalability In the first part of this series, we laid out a set of principles to help you understand when microservices can be a useful architectural choice. We promised follow-up pieces describing each of the factors in more detail. In the fourth post of the series, we explore independent scalability. Let’s take a quick spin in our hot tub time machine and head back to an era before cloud, microservices and serverless computing.

Independent Life Cycles

Part 3 of my “Responsible Microservices” series went live earlier this month! Should that be a Microservice? Part 3: Independent Life Cycles In the first part of this series, we laid out a set of principles to help you understand when microservices can be a useful architectural choice. We promised follow-up pieces describing each of the factors in more detail. In the third post of the series, we explore independent life cycles.

Multiple Rates of Change

Part 2 of my “Responsible Microservices” series went live last week! Should that be a Microservice? Part 2: Multiple Rates of Change In the first part of this series, we laid out a set of principles to help you understand when microservices can be a useful architectural choice. We promised follow-up pieces describing each of the factors in more detail. Here’s the first of such posts; let’s explore multiple rates of change.

Please Microservice Responsibly

I wrote a post summarizing some advice that Matt Stine and I used with a client… Should that be a Microservice? Keep These Six Factors in Mind You’re writing more code than ever before. The trick is knowing what should be a microservice, and what shouldn’t. These days, you can’t swing a dry erase marker without hitting someone talking about microservices. Developers are studying Eric Evan’s prescient book Domain Driven Design.

An Architect's Guide to Site Reliability Engineering

Full Abstract Development teams often focus on getting code to production losing site of what comes after the design and build phase. But we must consider the full life cycle of our systems from inception to deployment through to sunset, a discipline many companies refer to as site reliability engineering. While your organization may or may not have an SRE team, you have someone playing that role and we can all benefit from looking at the principles and practices that we can bring to bear on our projects.