Martin Fowler's Blog, page 16

Other implementations for domain-oriented observability

Pete completes his discussion of domain-oriented observability by
comparing domain probes to using events and aspect-oriented programming

more…

Passing execution context to domain probes

Calls to instrumentation require various bits of execution context.
Pete extends his discussion of domain probes to show how factory functions
help simplify the data plumbing.

more…

Testing Domain Probes

Now he's shown you the basic idea, Pete shows how
using domain probes makes it much easier to test observability behavior.

more…

Domain-Oriented Observability

Any serious software system needs some form of observability, so we can
figure out how it is working and keep track of problems. But adding the
code for this often results in lots of low-level cruft. Pete Hodgson describes a pattern that allows
developers to add observability via a testable domain-oriented API that
removes most of this cruft.

more…

Bliki: LockInCost

In my recent client engagement, I foresaw that serverless architecture was
a perfect fit. The idea of adopting serverless architecture, though, didn’t
fly to our client well due to the fear of vendor lock-in. It was an
interesting time for retailers as staying in AWS might mean that Amazon, as
another retail business, will be given a competitive advantage. Given the idea
of not supporting a competitor, my client was interested to ensure that the
solution chosen by us is fully portable to other cloud vendors.

From a technical perspective, ensuring that we have the ability to move our
system from one platform to another is definitely desirable. With the advent
of containerization, why would one be interested to be locked in a specific
platform? A high lock-in cost is not something that we would like to show back
to the business when we have decided to move another platform. We, therefore,
need to make sure that the migration cost is as low as possible when this
scenario happens. If I’m about to make a simple formula for lock-in cost with
our current understanding, it would look like this:

Lock-in cost = Migration cost (?)

This formula is correct when we are looking at it only from a technical
perspective. A business perspective, however, should not be overlooked.
Remember that the technical solutions we deliver are always designed to solve
business problems. Most of the times the business get a benefit when a
particular technology is adopted. One of the significant benefits is a faster
time to market. Faster time to market can be formulated into opportunity
gain:

Lock-in cost = Migration cost - Opportunity gain

Opportunity gain is very difficult to measure because you are dealing with
an unknown unknown. Migration cost can be analyzed and reasoned. Opportunity
gain, in contrast, is not as easy to analyze. You can theorize and analyze how
to migrate from one platform to another, but how would you calculate the gain
of seizing your competitors’ market opportunity? By looking at your
decision-making process from a holistic view, combining both the technical and
business perspective, the lock-in decision you are taking might result in a
profit.

Let’s have a look into an example of building an event-driven architecture.
You will need to choose a distributed messaging system in the architecture. If
you are already chosen AWS as your platform, you would have the option of
vendor-specific services like Kinesis. These services are fully managed and
you can get it running in no time, hence giving you an opportunity gain. In
comparison with a vendor-agnostic system like Kafka, these vendor-specific
services will incur a higher migration cost. Setting up your own distributed
messaging system, however, will take more time to hardened and for it to be
made production ready, especially when you are not experienced in building
such platform yet. Instead of looking at your decision from just migration
cost, focus on how you can reduce the migration cost by making your system
more adaptable. Especially in this example of using a cloud, this is
a similar reason on why we recommend to hold the practice of

generic cloud usage.

Acknowledgements

Thanks to Chris Ford and Matt Newman for their inputs.

Special thanks to Martin Fowler for his support, suggestions, and time spent with the content and help with publishing.

Share:

if you found this article useful, please share it. I appreciate the feedback and encouragement

Fixing attribute completion in Emacs nxml-mode

I write most pages on this website in an XML format source file, and
use emacs to edit those sources. I’m very happy with how nxml-mode works
with prose-style XML, making it much more usable than other environments
seem to be. But recent changes (with emacs 26.1, IIRC) put a bit of grit
into the environment.

more…

Repair to “Using OAuth for a simple command line script to access Google's data”

In 2015, I wrote a command line script to get some data from YouTube.
Since I had difficulty puzzling out the limited documentation,
particularly on the authentication and authorization aspects, I wrote a
short article to capture what I'd learned. Google updated its libraries in
2016, breaking my scripts. I was busy with other things at the time, so
didn't update them (or the article). Finally I've got around to it now,
and updated both. Going back, I found the article handy to remind myself how to
work with Google's use of OAuth, with refresh and access tokens.

more…

photostream 119

Washington, D.C (2018)

Kindle edition of Refactoring now available from Amazon

Amazon is now selling the Kindle edition of Refactoring. As I write
this, it's touch more expensive than the hardback since they are currently
discounting the hardback but not the electronic version.

more…

Face to Face with the Book

The books arrived at my house a couple of weeks ago, but I missed them
as I was on the road.

more…