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?

Join daily email list

I publish short emails like this on building software with serverless on a daily-ish basis. They’re casual, easy to digest, and sometimes thought-provoking. If daily is too much, you can also join my less frequent newsletter to get updates on new longer-form articles.

    View Emails Archive

    ☎️ Serverless Clarity Call

    Need quick guidance on a specific issue on your AWS serverless project? Or just wondering where to start with serverless?

    Book a call and ask me anything.

    Learn more >>

    🛫 Serverless Launchpad

    Ready to start building your new AWS serverless project but need help with getting everything setup?

    The Serverless Launchpad is a done-for-you DevOps service installed in under a week. You get a leading-practice multi-account AWS environment, a scaffolded codebase and architecture including the common AWS serverless services, isolated cloud environments for individual developers, automated delivery pipelines right through to production and much more. Everything is IaC, extensively documented and handed over to your developers.

    Learn more >>