Deployability is a top priority for your cloud services

When building software, deployability and testability are the two most important attributes of an architecture that predict high performing teams (based on research in the Accelerate book).

Yet so often in architecture design conversations, I see these attributes being downplayed in importance or reduced to an afterthought to be worked out after a decision has already been taken. This decision was usually in favour of the “best tool for the job”, where “best” was subjectively defined on some narrow functional attributes without any consideration for ongoing operational complexity.

The problem with “best tool for the job” thinking is that it takes a myopic view of the words “best” and “job.” Your job is keeping the company in business, god damn it. And the “best” tool is the one that occupies the “least worst” position for as many of your problems as possible. (source: Choose boring technology)

Specifically on the deployability aspect, this can become an issue when you are considering venturing outside your main cloud provider for a particular service. If you’ve selected a functionally best-of-breed third party service which has a terrible deployment story, you will almost certainly be shipping slower and your quality will likely suffer as well.

So how do you assess a new third-party service’s deployability? Here are some questions to ask yourself:

• How can we automate provisioning of environment-specific instances of this cloud service? Does it fit into our existing Infrastructure-as-Code deployment tools (e.g. CloudFormation or a layer on top of that) or do we need to build our own scripts to call their APIs to provision and deploy configuration changes to it? Or worse, do we have to manually use their web admin console to make such changes?
• In addition to fixed environments (test, staging, prod), can every developer provision their own “instance” of this service within their own personal cloud environment so that they can continue to work fully in isolation from other team members without needing to share a resource?
• Does the pricing for the service fit the granular pay-per-use metered serverless model? If not, how will this affect any plans for adhoc environment provisioning?
• Does this service need seed data? If so, how do we automate creation of it?
• Are there privacy and compliance issues of storing data in this service (if it’s outside of your main cloud provider)? If so, what checks do you need to put in place to ensure certain types of data don’t get sent to it?
• How do we manage security credentials for connecting to this service?