Speaking

microxchg.io 2015, Berlin, Germany.

The micro-service architecture has changed the game for software
development. It provides the first scalable, effective component model
for software systems. By embracing the organic, dynamic and chaotic
nature of micro-services, you can built fault-tolerant, scalable and
reactive systems.

But there is a dark side. Things can get out of control very quickly.
As the number of micro-services, and messages and interactions between
them grow, how do you keep control? How do you retain understanding of
the system? How can you offer any commitments about its behavior to
your CEO?

The answer is to embrace the complexity of the system, and recognize
that it has emergent properties. Rather than auditing and tracking
technical behaviour, measure the behaviour you care about, the
business outcomes. This allows you to understand the effects of new
deployments and failures at the right level.

Curator, Dublin Micro-services Meetup 2015, Dublin, Ireland.

Measuring Micro-services Video

Mucon 2014, London, UK.

Micro-service War Stories

Presentation Video

A reprise of the NodeConfEU 2014 talk.

NodeConfEU 2014, Waterford, Ireland.

Micro-service War Stories

Presentation Video

After nearly 3 years of building micro-services systems, you learn a few things. This is an empirical report on the good, the bad, and the ugly.

PayPal NodeDay 2014, San Francisco.

You only need 100 lines of JavaScript

Presentation Video

This talk is an appeal to server-side JavaScript developers to make
use of this time of change – Node.js is going to become the primary
server-side platform for most developers. We can move forward from
the old way of building web apps as large inter-locking co-dependent
code bases.

The Node.js module system has shown us the way. It’s the first
step. Now, we need to use the beauty of Node modules to help us build
robust, scalable apps.

This approach is called the Micro-Services Architecture. It’s more
than just having some services with HTTP end-points. It’s about taking
this to the extreme. Everything is a service, and no service is larger
than 100 lines of code.

We’ve been using this approach for most of our projects for the last 18
months and it works really well. We get to drop loads of
project management ceremony. There will be some customer war stories.

Node Summit 2013, San Francisco.

Monolithic Node.js

Enterprise software teams are starting to understand and embrace the
power of Node.js. They face a serious challenge: integrating Node.js
into the legacy systems they maintain, and migrating these system over
time into Node.js architectures. This talk is a pathfinder for those
facing this task. As a community we must proactively engage with the
Java and .Net communities, and create a deeper understanding of the
“Node.js Way”.

Web Summit 2013, Dublin, Ireland.

Falling in Love with Technical Debt

The only way developers can finish projects on-time and under-budget is by taking on Technical Debt. Taking shortcuts, using quick fixes, and writing unmaintainable code builds up a technical debt that get the project delivered today. Tomorrow, there will be a reckoning, as development costs spiral and progress grinds to a halt. This talk helps you embrace the debt, love the cowboys, and gives you a way to make repayments.

Distill 2013, San Francisco, EngineYard’s developer conference.

“How to Write Big Apps” (updated)

The Seneca pattern is a way to break your application into pieces so that you can put it back together again in many different ways. You don’t have to worry about architecture, database choice, network design, scaling or even which objects to define – you can defer them all! Instead you focus on the “stuff that needs to happen” right from that start. A concrete, production implementation exists in Node.js, and you can also write components in other languages.