Net API Notes for 2019/11/14 - Issue 114

In the northern Virginia area (NoVA), outside of Washington, DC, the weather has finally turned colder. That's the perfect excuse to stay indoors, cozy up on the couch, and read the latest Net API Notes!



Dasith Wijesiriwardena, an Australian based full-stack developer, recently posted his APIDays talk, "A Game of Snakes and Ladders Called Microservices". He summarizes many of the issues related to microservice development.

In particular, I found Dasith's guidance on when event systems make sense (and when they don't) compelling:

"Event Sourcing works well for transactional systems when applied within a bounded context. As soon as you do it as a top level pattern for all your microservices, you end up using your event schema effectively as a public data contract. This makes change harder and have the same effect as microservices sharing a table in a database."

Speaking of microservices, I need to cover a recent post on Techerati. It is no secret that I love a well-written postmortem. In "The Hidden Costs of Microservices", authors Wayne Geils and Mike Hostetler describe their experience with service architectures at

"-we determined at one point that we needed to change something in our website's footer, and because we had 17 microservices working together to run the front end of the site, all of them had to be updated to make the change. In the end, it took us a bit of time to make the update."

All of them had to be updated to make the change. Every situation is different, and I have no more context than what the article provided. However, simultaneous updates across multiple services, as described, is not the hallmark of highly cohesive, loosely coupled service boundaries.

Further down, the authors make the statement that "someone must be in charge of coordinating integration testing and inter-team communication".

If there is one thing that working with Irakli Nadareishvili, co-author of the Microservice Architecture book, has taught me is that proper microservices reduce coordination overhead, not increase it.

When folks talk about the benefits of microservices, they often cite the seven principles as outlined in Sam Newman's foundational work, Building Microservices. Those seven properties are:

  1. Independent Deployment
  2. Failure Isolation
  3. Highly Observable
  4. Modeled Around a Business Domain
  5. Implementation Detail Hidden
  6. Decentralized
  7. Made Possible by a Culture of Automation

While each of these is nice on their own, I can also argue that each is an aspect of reduced coordination overhead. I won't go through each - that is an exercise for the reader. However, if I can independently deploy new code to support my service than I'm saving time having to coordinate with others. If my pipeline is highly optimized, I do not have to coordinate manual processes to make a change. If I stop failures from cascading to upstream or downstream integration partners, I'm avoiding having to call everybody from the intern to the C-suite into a war room to triage an outage.

I respect these folks for sharing their experiences. Further, I only have this one piece to go by. However, it sounds that the pain felt was more due to a distributed ball of mud, and not actual microservice architecture.


Many people use OpenAPI for many things. However, one challenge with using the specification has been how to account for runtime configuration properly. In his talk, "Become a Pro at API Management: A Declarative Approach", SmartBear's Emmanuel Paraskakis delves into why storing that information in an API description is a viable idea, what kinds of details would be listed, and how various response policies would be shaped.

It is all a prelude to the "OpenAPI Proposal for Overlays #1843". I know wallowing in the depths of specification minutia is not everybody's idea of a good time. However, if this is your thing, I'm sure your thoughts would be welcome in shaping the next version.



Check out for in-person meetups near you. Special thanks to Adam, who let me know about the upcoming Austin Homegrown API meetup coming up on the 21st. If you know of a meetup, hackathon, or conference that should be added, be like Adam and reach out. I'm always glad to throw something on the ole interwebs.

And thank you to my Patreons. Covering the caffeine is an underappreciated token of support. Not all heroes wear capes.

Till next time,

Matthew @libel_vox and

Subscribe to Net API Notes

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.