About six months ago, I saw a great talk by Nora Jones’ called “Rethinking chaos engineering” — I was inspired, not so much by the chaos engineering, but by something else.
You see, I’d seen these pattern in a bunch of different organisations;
Pattern 1:
Service A (that your audience interacts with) relies on Service B and C. Service B & C fails, but Service A gets a bad rap with their users. The teams responsible for Services B & C don’t know about the impact they are having on Service A.
Pattern 2:
New product owner comes into a team. The don’t understand the technology estate. They are left with questions like “Is Service A more important that Service B?” “How critical is Service C to my overall priorities?”.
So I spent a few nights pulling together a Proof-of-Concept called Spectacle.
My solution was to create a dashboard that would capture, displaying and communicate service’s SLIs, SLOs, SLAs, their dependancies and align the service closer to business priorities.
I saw the purpose of the concept as a way of facilitating a conversation between teams about the importance of a service within a microservice estate.
I got some lovely feedback from a few folks, made a few tweaks and moved on.
Four months later
I had started playing around my next PoC — content workflow/state management — when it stuck me something major was missing from Spectacle; Architectural decisions.
Helping to build a complete picture of each microservice within your estate is one thing. Building an understanding and consensus amongst teams on the direction, challenges and impacts those microservices are facing is the next logical step.
I’ve seen too many architects in organisations make decisions upon high and not communicate them at all (or particularly well). Then disaster hits, because the impact of the decision reaches the service teams and doesn’t fit.
So taking some cues from Riot Games on how they do Tech Design and Michael Nygard’s documenting architecture decisions I decided to add it into Spectacle. But it would need a major change.
Spectacle was ‘single user’ — it saved your data locally in your browser, using local storage. You couldn’t export or easily share your data, this required a major shift.
A macro/micro/nano-SaaS?
User authentication, multi-tenancy, databases, APIs. It was all starting to look like a fully fledged software-as-a-service. So I thought, why not launch it as one?
I decided to use an old domain that I had never used and see what happens. Two months later, The Slate went live.
I do believe in the power of insights and open communication. The more you and your teams know, the better decisions you make. I don’t expect the Slate to become the “next big thing”. But if it helps one or two teams have a better understanding of their organisational context, then I’ve done something useful.
What’s next?
Going back to the feedback from the Spectacle PoC, there were two major comments.
- I can’t share it with anyone (Resolved!).
- I’d like to see summaries from monitoring and alerting systems alongside a particular service.
So, depending on how well the launch goes I’m going to start looking at 3rd party integration and see where that leads me.
Top comments (0)