Announcing Capability Services Web Console

You can now interact with Capability Services using the web console.

Capability Services is currently in Early Access. When creating an account you will be asked to join the waitlist. If you choose to join the waitlist, you will receive an email once your account becomes available.

You can also contact tristan.slominski@capability.io directly.

Map/Serverless/DevOps DaysATL 2019 Things Learned

There are lots of things I learned at Map/Serverless/DevOpsDaysATL 2019 that I will probably not mention here, but I do want to share a random set of highlights that I’ll probably want to reference myself in the future.

What Wardley Maps really look like

It turns out, that most practicing mappers, including Simon Wardley himself, use maps in a way where the generated artifact looks like this:

This wasn’t at all obvious to me when reading the mapping book and learning about mapping in general. The pretty versions of maps in the book, in presentations, etc.. are that way mostly* to teach others about mapping. After all, the picture above would be a difficult pedagogical tool.

* some maps are worth presenting or keeping around and iteratively come back to them; also, digital maps allow for long-distance collaboration; however, most maps probably look like the picture.

Vertical axis of a Wardley Map is… kinda there

There is a lot that goes into explaining the horizontal evolution axis of a Wardley Map. Multiple adoption cycles, diffusion of innovation, all sorts of things come into play. It takes a lot of research to determine the stage of evolution, and we usually bypass it via crowdsourcing of people’s opinions. I even created https://mappingevolution.com to help me figure out where things ought to go. The value chain vertical axis, on the other hand, is there as “scaffolding”. People kept asking Simon what is the vertical axis so it is what it is. Movement on the vertical axis, while meaningful, seems to me to be much less meaningful that movement on the horizontal axis. However, Jabe Bloom framed the vertical axis in an interesting way using Regimes, Strategies, and Niches.

I haven’t fully grokked this framing yet, so I’m uncertain if it is useful. However, I am intrigued.

Burja Mapping

Tasshin Fogleman introduced Samo Burja’s Empire Theory and created a sort of mapping for power structures in human organizations.

I have more reading to do, but Burja’s ideas on top of some sort of Tasshin’s mapping are intriguing.

Spatial visualization of framing

As always, Jabe explains some philosophy in a very accessible way. In this case, I really enjoyed his visualization of framing. It is also the first time in my mind it clicked that framing can be interpreted as figuratively putting a picture frame on some part of reality and considering what is in the frame. I always understood framing abstractly, but not this spatially.

Output and Outcomes

Also from Jabe’s presentation, this was an important highlight, that both outputs and outcomes should be on the map.

Cost of Change

Also also from Jabe’s presentation, he highlighted three types of change to keep track of on a Wardley Map. In particular, not only the change of a component on a map, or the change due to movement of component on a map, but the change due to changing relationship between components, the changes in lines on a map and what components the lines link.

Contracts/Pacts

I got to sit out of frame and hear Claire Moss talk about contracts and pacts. I’ve heard of these before, but she highlighted multiple nuances that I wasn’t aware of. Definitely provided additional context for my thoughts on the boundary between Complicated and Complex. You can find the discussion on Twitter.

And lots of other things…

Aside from some of the highlights above, I was fortunate to meet a bunch of people who I only ever saw on video and have conversations with them. That was definitely the highlight of the conf.

Now, I have some reading and thinking to do…

Announcing Media Service Early Access

With the increasing number of online privacy laws such as the EU General Data Protection Regulation (GDPR) and the upcoming California Consumer Privacy Act of 2018 (CCPA) there is increased liability associated with storing Personally Identifiable Information (PII).

Introducing Media Service Early Access

Media Service enables you to send transactional emails to customers without having to store their email addresses, reducing the liability involved with storing Personally Identifiable Information (PII).

Now, with the Media Service, you no longer need to store sensitive email addresses yourself. The Media Service will store the email address on your behalf and instead will grant you a capability to send email to the address without exposing the address to you. You can store and manage these capabilities within your systems without fear of leaking sensitive data.

Using Media Service

With the Media Service, you exchange your customer’s email address for the capability to send email to the customer. This frees you from having to store sensitive PII while still being able to communicate with your customers via email.

You can use Media Service with the Capability CLI, the Capability SDK, or the HTTP API.

To learn more, see the Media Service documentation.

Pricing and Availability

During Early Access, Media Service is free to use. Once Early Access ends, you will pay only for what you use.

To sign up, contact tristan.slominski@capability.io.

Announcing Certificate Manager Service Early Access

With the arrival of HTTPS Everywhere, all browsers now mark non-HTTPS traffic as insecure. However, management of Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates that enable HTTPS can be quite complicated.

Introducing Certificate Manager Service Early Access

Certificate Manager Service simplifies public Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificate management while letting you deploy those certificates wherever you like.

Certificate Manager Service lets you request a publicly trusted certificate and have that certificate delivered to your storage solution so that your systems can distribute and use it as required. Your certificate is not locked into use with only Capability Services.
Read more…

Announcing Membrane Service Early Access

Online delegation of authority looks nothing like how we delegate authority in our every day lives. The prevalence of Access Control List (ACL) authorization pattern (list of permissions attached to a resource) has constrained many systems to centralized access control. While, for some highly sensitive use cases, centralization is desired, for others, the use of ACLs leads to overconstrained solutions.

Introducing Membrane Service Early Access

Membrane Service solves the problem of being able to delegate authority in a decentralized manner. It does this by using capabilities and offering capability-based authorization at any scale in accordance with any policy via membranes.
Read more…


The Last Thought Will Last Forever

PBS Space Time — How Will The Universe End?

As I was watching one of the PBS Space Time videos about the end of the Universe I pondered what it would be like to be present that far in the future at those timescales. Imagine that somehow we transfer our consciousness into a different, more durable, substrate which can endure much longer than our biological bodies and that can be altered to adapt to changing cosmological circumstances.

The substrate, on which our consciousness would run, would continue to exist in the Universe. As the Universe continues to expand and runs out of energy, whatever process keeps us going will need to scavenge energy from further and further away. Signals between the future analog of our neurons would need to travel farther and farther in order to reach the next “neuron” to trigger a follow-on signal. These patterns of firings are what thoughts are. As the expansion continues… a mind with this setup would perceive the Universe around it “speed up”… while an external observer would see this mind “slow down” in its ability to react. As it takes longer and longer for this mind to have a “thought,” the end would never come, Zeno’s Paradox-style. The last thought would last forever O_O.

The Hidden Cost of Collaboration -Resource Contention

This post explores why the speed of software development can slow to a crawl inside large organizations. In particular, we will consider software services and their customers from the perspective of resource contention. It turns out that this framing highlights a major contributing factor that slows software development. We will conclude with what can be done about it.


Consider the problem of resource contention. Software services require resources to operate, and those resources are finite. When users use a software service, resource contention problem occurs as soon as there is more than one user. The key question to consider is, who is responsible for managing the resource contention problem? We have two possibilities. The service itself can manage the problem in a centralized way or the users can manage the problem in a decentralized way. This is the key insight to extract from this framing.

The service itself can manage the problem in a centralized way or the users can manage the problem in a decentralized way.

The resource contention problem can be managed by the service or by the users. In the case of the service, the management can be centralized within the service. In the case of the users, the management must be distributed.

There is a cost associated with managing the resource contention problem.

When the service bears the cost, it bears the entire cost of managing the problem. A typical solution to the resource contention problem is for the service to become multi-tenant. To every user, it seems as they are the sole tenant of the service and need not worry about managing resource contention.

When the users collectively bear the cost, the cost for any single user is mostly small, most of the time. A typical solution takes the form of an ad hoc, distributed, and probably incorrect, consensus protocol. This protocol is typically referred to as  “careful” or “being a good citizen.” Every user knows that there are other users who at any point can do something that severely degrades their own use of the service, or worse, they’re unaware of it. Typically, users coordinate with each other in order to manage the shared service and not exhaust its resources.

Consider what happens when a user uses multiple services for which they have to manage resource contention with other users. Every new service requires adoption of a new, ad hoc, distributed, and incorrect, consensus protocol. While the cost of coordination may be low initially, the cost, per user, grows super-linearly with the number of services used, since all of the users of each new service, some of them unknown, must be coordinated with.

Alternatively, when each service manages the resource contention problem by offering multi-tenancy, every new service requires no coordination from the user. The cost, per user, increases linearly with the number of services used and is limited to learning how to use the service.

When each service manages the resource contention problem by offering multi-tenancy, every new service requires no coordination from the user.


Another relevant concept in the dynamic between services and users is the notion of internal and external users.

Users external to the business, tend to have other options, and therefore are less likely to put up with additional cost of coordination required for using the service. On the other hand, internal users typically have no such luxury, are cost insensitive, and must use the service designated for them. This tends to lead to a pathology where the service seems justified in not paying the additional cost of providing multi-tenancy, as the internal users have to use the service no matter the cost of coordination. But, what is often missed, is the super-linear cost the internal users must bear for their distributed management of resource contention. Fortunately, there are things we can do to avoid this situation.

Service seems justified in not paying the cost of providing multi-tenancy, as the internal users have to use the service no matter the cost of coordination.

We can demand that all services manage the resource contention problem by being multi-tenant. Alternatively, we can ensure that internal customers have a choice of using or creating another service that is multi-tenant, which may eventually lead to multi-tenant services as the cost of their adoption is lower.

Lastly, I want to highlight a pathological move not to make.

Forcing the use of a single service is the right move if and only if that service is multi-tenant.

There is great efficiency to be gained by removing duplication of effort. Forcing the use of a single service is the right move if and only if that service is multi-tenant. Otherwise, the organization is placed in a configuration where internal users must bear the cost of managing resource contention and cannot improve their situation by using a multi-tenant alternative.