Autonomous Services

Autonomous Services

In my previous post, I explored how words and language used by users of our system in our domain space can have different meaning based on their context. This establishes which services own which behavior and data. In this post, I’m going to explore why services are autonomous and how we can communicate between them

This blog post is in a series. To catch up check out these other posts:


Autonomy is the capacity to make an informed, uncoerced decision. Autonomous services are independent or self-governing. 

What does autonomy mean for services? A Service is the authority of a set of business capabilities. It doesn’t rely on other services.

We are constantly in a push/pull battle between coupling and cohesion. High coupling ultimately leads to the big ball of mud.

What’s unfortunate is the move to (micro)services with non-autonomous services that rely on RPC (usually via HTTP) hasn’t reduced coupling at all. It’s actually made the problem worse by introducing an unreliable network turning the big ball of mud into a distributed big ball of mud.

Prefer Messaging over RPC

We want services to be autonomous and not rely on other services over RPC to reduce coupling. One way to do this is to communicate state changes between our services with events.

When Service A has a state change, we publish that event to our message broker. Any other service can subscriber to that event and perform whatever action it needs to internally. The producer of the event (Service A) doesn’t care about who may consume that event.

Services that don’t Serve

This may seem completely counter-intuitive since the definition of a service is an act of assistance. However, an autonomous service does not want to assist other services synchronously via behaviors, rather exposing to other services things that have happened to it via asynchronous messaging.

An example of this in our distribution domain is in the form of Sales services and the quantity on hand of a product.

Does Sales need the quantity on hand of a product?

Sort of. You could assume without knowing this domain that you do not want to oversell. However, in my experience in distribution, overselling isn’t really a sales problem as it is a purchasing problem.

Sales want to know the quantity on hand of a product, as well as what has purchasing ordered from the vendor but has not yet been received. This is called Available to Promise (ATP) and is used by sales to determine if they can fulfill an order for a customer.

Another interesting point is related to Quantity on Hand. The quantity on hand that is owned by the warehouse service is still not really the point of truth for the real quantity on hand. Whatever the quantity on hand is for a product in a database isn’t the truth. The real truth is what’s physically in the warehouse. Products get damaged or stolen and aren’t immediately reflected in the system. This is why physical stock counts exist which end up as inventory adjustments in our warehouse service.

If we’re using RPC, for the Sales Service to calculate ATP it would need to make synchronous RPC to:

  • Purchasing Service to get what purchase orders have not yet been received.
  • Warehouse Service to get the quantity on hand.
  • Invoicing Service to determine what other orders have been placed but not yet shipped.

However, if we want our Sales Service to be autonomous it needs to manage ATP itself. It can do so by subscribing to the events of the other services.

Sales can manage it’s own ATP for a product subscribing to the various events. When a purchase order is placed it will increase the ATP. When inventory is adjusted it will increase or decrease the ATP. And finally when an order is invoiced it will decrease it’s ATP.

Blog Series

More on all of these topics will be covered in greater length in other posts. If you have any questions or comments, please reach out to me in the comments section or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #45: AWS Secrets Manager, Microservices, ASP.NET Core Architect, WCF vs gRPC

Here are the things that caught my eye this week in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

AWS Secrets Manager client-side caching in .NET

AWS Secrets Manager now has a client-side caching library for.NET that makes it easier to access secrets from .NET applications. This is in addition to client-side caching libraries for Java, JDBCPython, and Go. These libraries help you improve availability, reduce latency, and reduce the cost of retrieving your secrets. Secrets Manager cache library does this by serving secrets out of a local cache and eliminating frequent Secrets Manager API calls.


Microservices and more in .NET Core 3.0

Enabling developers to build resilient microservices is an important goal for .NET Core 3.0 In this episode, Shayne Boyer is joined by Glenn Condron and Ryan Nowak from the ASP.NET team who discuss some of the exciting work that’s happening in the microservice space for .NET Core 3.0.


Becoming the ASP.NET Architect with David Fowler

In this episode, David Fowler, the Partner Architect for the ASP.NET team walks you through landing his first job, moving from a dev to an architect role and what he had to learn and let go of at every step along the path. (David intros himself as a Principal Architect but his promotion was announced right after we filmed.)


WCF vs gRPC – Round 2

After my previous post comparing WCF to gRPC, a couple of people on Twitter and in the comments asked which WCF binding I had used for the performance comparison. The answer to that was “whatever the default binding is”, which is basic HTTP binding. As Clemens Vaster pointed out, that is not an “apples-to-apples” comparison, and a fairer WCF vs gRPC test would use NetTCP binding. So I re-ran my performance tests using NetTCP binding in a simple console host for the WCF service.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Context is King: Finding Service Boundaries through Language

I’ve found that one of the most important ways to find service boundaries is through the dialog you have with various end users in different parts of the system we are working on. Really focusing in on the words they use can be instrumental in finding service boundaries.

This blog post is in a series. To catch up check out these other posts:

Taken out of Context

If a statement or remark is quoted out of context, the circumstances in which it was said are not correctly reported, so that it seems to mean something different from the meaning that was intended.

If was talking with my son, and you overheard the statement:

The crane was huge.

Which crane would you have thought of?

There really is no way for you to know which type of crane I’m referring to without more context.

A Product isn’t a Product

As a more practical example, let’s use a distribution company.

The high level is the company purchases products from vendors, receives them into their warehouse, and then sales those products to customers.

When you talk about a product, it can mean different things to different people depending on their context.

If you talk about a product to a salesperson, when they use the word price they are referring to is the sale price. Sales are customer-centric.

When you then discuss a product to a person in purchasing, they will refer to the products price as the vendor price since purchasing is vendor-centric.

Talking about that exact same product to someone in accounting, they will refer to the price as the sales price, and cost as the vendor price.


By understanding the context of the end users of the system you can determine when a word may mean different things to different people. If it does, then you may have found a boundary.

Blog Series

More on all of these topics will be covered in greater length in other posts. If you have any questions or comments, please reach out to me in the comments section or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.