Venturing outside the AWS walled garden

The beauty of serviceful architectures is that you don’t need to limit yourself to one cloud provider for all your services. You can choose and compose as you please from any internet-facing service.

And yet, it often seems the path of least resistance to simply select the relevant service offered by your cloud provider. Indeed, this is the route taken by many folks starting off.

But the time will come when you’re seriously considering using a third party for part of your system, whether it’s a greenfield application or replacing a component within an existing workload.

What factors do you need to consider when making this decision?

I would break this down into the following three high-level questions:

1. What are we giving up by going outside of AWS?
2. What qualities does a third party service need to have for it to be a good fit for us?
3. For each third party service under consideration, what are the integration points between it and the relevant AWS service(s), and what’s involved in connecting them together?

In this post, I’ll cover question 1 and address the others in upcoming articles.

A trusted, known quantity

First and foremost, AWS aren’t going to go bust and leave you in the lurch. They generally have a strong reputation of listening to their customers and not killing off services.

Security and IAM

The services in your system need to communicate with each other securely. The called service needs to trust that the calling service is who they say they are and based on this, grant it a specific set of permissions to use it.

AWS Identity and Access Management (IAM) is how almost all services within the AWS suite achieve this inter-resource and inter-service authentication and authorisation. But IAM is proprietary to AWS and if you decide to go with a third party service, you need to find an alternative mechanism to secure your communications.

“AWS IAM… absolutely is the worst form of cloud lock-in that currently exists, at least relative to the zero people who seem to be talking about it.” (Forrest Brazeal)

Data privacy and compliance

By keeping all your data within a single cloud provider’s infrastructure, you’re reducing your risk of data privacy breaches. Also, AWS have huge numbers of resources dedicated to compliance that you can make use of. If you have your own regulatory requirements such as GDPR or HIPAA to meet and need to send any kind of personal or sensitive data, you now need to do your own due diligence on a third party provider.

Single admin interface

The AWS Console, for all its UX faults, allows you to administer all services across your entire application/workload from within a single web app. This familiarity can make onboarding new engineers easier.

Built-in integration to Lambda and other AWS services

Many AWS services automatically integrate with each other, saving you the expense of writing and managing your own integration. And if 2 services don’t have a direct integration out-of-the-box available, many have built-in integrations to Lambda so that you can build your own custom integrations with small amounts of glue code.

Infrastructure-as-Code

The vast majority of AWS services that you might use in a serverless application have CloudFormation support. This makes it easy to describe your resource configuration and automate deployments using a common language. You generally don’t need to write your own custom deployment scripts to provision an AWS resource or update a configuration setting.

Monitoring

Many AWS services have built-in integration with CloudWatch. This allows for logging and metrics to be aggregated within a single interface or dashboard.

One credit card, one bill

If all your services are within AWS, you can pay for all your services from the same credit card (set up once) and view your cloud operational costs in one place. This reduces the friction for getting started with new services, in particular within corporate environments where getting access to a company credit card can be extremely difficult.

A high standard for third party services to meet

The above benefits can make staying within the comfort of the cosy AWS garden very tempting. Third party services certainly have a high barrier to scale to be considered.

Next time round, I’ll look at what qualities a third party service needs to hurdle this wall and be worthy of your consideration.

— Paul