AWS AppRunner Is Not There Yet, and Might Never Be | ✉️ #14

Illustration for 'MKDEV Dispatch #14' featuring a smiling person holding a small dog, with a paper airplane and text 'AWS AppRunner is not there yet, and might never be'. Illustration for 'MKDEV Dispatch #14' featuring a smiling person holding a small dog, with a paper airplane and text 'AWS AppRunner is not there yet, and might never be'.

Hey! 👋

This week, I finally got my hands on AWS AppRunner. The service itself was released more than a year ago, but it usually takes some months, sometimes years, for AWS to make a service truly usable for production workloads. Is AppRunner production ready now? I am not sure.

To give a re-cap, AppRunner is yet another attempt from AWS to give us the simplicity level of Heroku. Let’s take a simple case of a web application that needs to talk to the database:

  1. With ECS, you need a Service, TaskDefinition, ALB and all the glue in between, together with VPC and IAM configuration;

  2. With Lambda, you need a Function, an API Gateway or ALB or, recent addition, just an URL;

  3. With EKS... well, you need to know how to use Kubernetes and expose services via ALB Ingress Controller;

Besides that, none-container options exist, as well as options with containers, but without AWS-specific services - but let’s focus on how AWS sees containerized application deployment. AppRunner’s promise is nice: you only need a container image, pass some environment variables, optionally set custom domain and that’s it. It also integrates with GitHub, so that you can get automatic deployments easily. More or less just like Heroku.

As of today, this simplicity is not really there, as AWS has to implement such services within existing architecture of AWS itself. As a result, to connect AppRunner-hosted application to RDS, you need to figure VPC Connector configuration. To provide secrets (feature only added in January 2023), you need to use either SSM or SecretsManager - and make sure you configure IAM Policies correctly.

AWS Console for AppRunner is horrible - it does not help you to create a valid configuration, and if you make a mistake, you need to delete the whole application and start over. Using Terraform or similar tools is a natural choice, but at the same time it defeats the purpose of a service aimed at making infrastructure as simple as possible.

The alternative is an amazing AWS Copilot, finally a very friendly CLI to deploy applications to AWS, specifically to ECS or AppRunner, with a great set of abstractions and simple configuration. As of 2023, it’s impossible for AWS to hide the complexity except via building client-side abstractions on top of their architecture - for good reasons, too. The problem for AppRunner in this case, is that Copilot works as great and simplifies as much for ECS - with a wider range of features and possibilities available on ECS side.

The attention AppRunner gets so far is confusingly little. SSM and SecretsManager support landed only couple of months ago, while selection of CPU/RAM is bare bones, with a maximum of 2 CPU and 4GB of RAM (per task/container/whatever AppRunner uses under the hood). At the same time, AppRunner is crazy expensive. Yes, ECS Fargate with ALB will probably cost more, but you can use Fargate Spot and drive costs down quite a lot. With AppRunner? No such option.

At the end of the day, AppRunner, technically, simplifies things - it’s finally a way to run containers without provisioning ALB, and without diving into the serverless model of Lambda. It’s a service obviously built as a competitor to GCP CloudRun. But while GCP CloudRun is a solid, production ready way to run both event driven and regular workloads, AppRunner has a lot of catching up to do - and so far I don’t see AWS investing a lot of effort into this.

I am working on a new video just about the AppRunner, don’t forget to subscribe to our channel to see this tool in action - the plan is to deploy mkdev’s preprod environment with it.


What We've Shared

  • Service Weaver, monolithic or microservice? We're going to learn how Service Weaver works, a new functionality from Google, a framework to write micro services in a monolithic code:

  • Argo CD Self-Heal, Sync Windows and Diffing: In the last lesson of our Argo CD Lightning Course we are going to learn how to deploy new changes, as well as reconcile the infrastructure with the state in git - and limit this automation to a sync window.

  • Majestic Pipeline: A CI/CD Love Story: Come, sit around the fire, as Pablo Inigo Sanchez, god of thunder, father of dragons, tells you the greatest story ever told, the story of Pipelines and a quick history of CI/CD, from the shell scripts at the dawn of time to the age of the containers.

  • How to debug Cloud Run with Visual Studio Code? Visual Studio Code will help you to debug in the cloud, and Pablo is here with a quick example of how to use it in Google Cloud.

  • 'DevOps Accents', episode 6: In this episode of DevOps Accents, Leo, Pablo and Kirill talk about reasons why Uber moved to Cloud and the problems with international privacy legislation.

***​

What We've Discovered

  • EKS and Cost Optimization: An overview of things to consider on node and pod level when it comes to optimising cost of an EKS cluster.

  • Priority Classes in Kubernetes: To make sure most critical pods always get scheduled, Priority Classes are great. Nice examples on how to use them to make sure prod pods always run, even if means evicting dev pods.

  • Top 15 plugins for kubectl: Some are niche, but all are great!

  • Service Mesh 2022 Recap: It's a bit biased towards Linkerd, but point #2 is very good and important. The movement from per-pod sidecars to ambient mesh with per host proxies and eBPF seems to be like a crazy overcomplication of an already complex technology.

  • Tips for optimizing AWS VPC: A comprehensive list of things that you should consider when planning your VPC setup. A lot of this comes down to "it depends", but at least it points to the places you need to pay attention to.


A job offering

EU company seeking System Integration and Workflow Specialist. Details, job description, required expertise and skills, and contacts are on our job listing page here.


The 15th mkdev dispatch will arrive on Friday, March 31st. See you next time!