A serverless-first approach to multi-cloud with AWS
Tags: aws, serverless
Published: 2020-12-13 14:20:06

---
title: A serverless-first approach to multi-cloud with AWS
published: true
description: 
tags: aws,serverless
//cover_image: https://direct_url_to_image.jpg
---

## What happened?

How much of an oxymoron this post title could be? Serverless and multi-cloud seem to be an _either-or_ approach for running your apps and services on the cloud. Or at least it was until last week after they introduced the new [AWS ECS Anywhere](https://aws.amazon.com/blogs/containers/introducing-amazon-ecs-anywhere/) service, which allows you to deploy and run container tasks virtually on any environment -remember, not only Docker, but also contai-nerd (pun intended).

According to AWS's press release _"this will include the traditional AWS managed infrastructure, as well as customer-managed infrastructure. All this without compromising on the value of leveraging a fully AWS managed, easy to use, control plane that’s running in the cloud, and always up to date"_

Basically, they broke multi-cloud as we knew it as they keep moving the cloud to the edge. This means that we as customers can provision our compute resources from regions, AZs, edge locations, and now, from our own private infrastructure in our datacenters. Or even beyond that, nothing stops you from running AWS ECS Anywhere on your Blackberry Pi.

However, as AWS states in their note _"Cloud connectivity is required to update or scale the tasks, or to connect to other in-region AWS services at runtime"_. This is an interesting point. It means that we are moving towards a **decentralized provisioning but with centralized control**. 

## What does this mean to cloud-native development?
Interesting times. This move means that we don't need expensive solutions like K8s anymore in order to implement our cloud portability requirements ([we never did](https://blogs.gartner.com/marco-meinardi/2020/09/04/adopting-kubernetes-application-portability-not-good-idea/), but now it has become more obvious).

We can now have a **serverless-first** approach to multi-cloud (including private cloud). It means that our default application and service development strategy can be one that leverages serverless by default without defensively designing and programming our workloads with portability requirements in mind. We can now rely on the cloud provider to provide the _application primitives_ we need for our services anywhere. 

How? Well, I see several options

1. For small workloads, you can build your services using AWS Lambda. But it just happens that AWS also announced that they have [open-sourced all their base images for AWS Lamba runtimes](https://github.com/aws/aws-lambda-base-images/blob/nodejs12.x/Dockerfile.nodejs12.x). It literally means that you can take all your AWS Lambda functions, package them into containers using their base images and run them on AWS ECS Anywhere. You invest on serverless once, and you get free portability to multi-cloud.

2. For bigger workloads, you may be already using Fargate tasks on AWS ECS. Easy, you just need to move those containers to ECS Anywhere, and you are ready to go

Of course, there are other many considerations. It depends on how your architecture is leveraging other managed-services such as DynamoDB, SNS/SQS, EventBridge, API Gateway, or Step Functions. However, what we can see here is a trend. As we stated above, AWS is betting on a **decentralized provision with a centralized control**. And we'll see more in this space in the future, I am sure. 

For now, we can start moving our workloads virtually to any premise while leveraging our initial serverless investment without the need of wrapping them in complex fleet managers or even without re-writing a single piece of code.

AWS has broken multi-cloud.