Driving down lead time, shortening the feedback loop, moving fast and iterating, and evolving our systems as we learn, is the holy grail of software development. Independently deployable microservices are supposed to help us achieve this. But the question arises: How small should a microservice be? The common answer is to follow the Single Responsibility Principle (SRP), but the SRP is commonly misunderstood.

This is understandable, because the name implies that a module should do one, and only one, thing. But this was never the definition of the SRP, and yet it has been repeated over and over again. This misunderstanding has arguably led to the creation of many microservice death stars. These death stars are resistant to change and ultimately drive up lead time, because of the complex dependencies within these systems.

The original definition of the SRP is that a module should have one, and only one, reason to change. This is better, because the operative word is change, but it is ambiguous, because it doesn’t zero in on what drives change. The short answer is that people (that is, actors) drive change. Uncle Bob (the creator of SRP) acknowledged this problem and refined the definition in his book Clean Architecture, as follows:

a module should be responsible to one, and only one, actor

Armed with the recognition that people are the drivers of change, we can start to architecture our serverless software systems so that they enable change.

In my books I zero in on three kinds of actors: Users, External Systems and Business Owners. These kinds of actors drive change in different ways.

• Users perform many different activities and each can change independently.
• External Systems are owned by separate entities and will change at the whim of their owners.
• Business Owners control the overarching business p