Much of my current job is maintaining and enhancing control planes for Heroku’s managed data services. This post explores three patterns used to reduce operational burden and increase system safety and resiliency: state machines (and associated state-transition tables), transducers and re-entrant and idempotent operations.
Ever heard someone say “It’s only software/money/<trivial thing>, not life or death”, in the context of incidents at your company? Although mostly true, I want to talk about a time in my career when sometimes, just sometimes, it was the latter, and how it shaped my approach to operating and owning services.
When building and operating a user-facing system, especially one that is open to the public, it is important to consider the riskiness of a user, which can also be characterised as trustworthiness. These will typically be negatively correlated, with low trust indicating high risk and vice versa, but this is not always the case.
Sprezzatura is “a certain nonchalance, so as to conceal all art and make whatever one does or says appear to be without effort and almost without any thought about it”, coined by Castiglione in 1528’s The Book of the Courtier.
This is a short post on what I see are table stakes for any new user-facing service, security-wise. Mostly focused on user-focused, rather than intra-service, considerations.
Following up from last time, let’s explore the internal and insider fronts when moving beyond security towards safety for our users.
We need to move beyond mere security and towards safety for our customers and our users. This is how we can do that.
Let’s kick off 2016 with a whistle-stop tour of one of my favourite OO approaches, Service Objects, in the context of Rails.