AWS Proton and Tale of So Many Options
By: Brian Olson
Tags: Aws Proton, AWS, DevOps, Serverless, Cicd

If you weren’t aware AWS re:Invent is just now wrapping up and there have been a lot of announcements. One that stuck out to me was AWS Proton.

Before I say anything about that service specifically let me jump back to the first time I was evaluating creating a service environment in AWS. We had a greenfield project and we could pick essentially any deployment mechanism we wanted. This was ~5 years ago, so containers weren’t mainstream enough for us to feel comfortable jumping into that pool, but we were still weighing several

ElasticBeanstalk EC2 Instances managed by Systems Manager AWS Opsworks Stacks(before there were other opsworks options) Auto scaled instances deployed to with codedeploy

And on top of all of that we were working through CloudFormation trying to grapple with what it meant to manage all of these environments with Cloudformation templates. I finally asked an AWS solutions architect, “It seems like there is a ton of overlap between all of these services.”

And he said, “……..yes there is.” The punch line is that AWS creates services with overlap to give you subtle variations on solutions. If you have an environment that closely matches an ElasticBeanstalk template you can use it and get moving quickly. If you love Chef but don’t want to pay for chef server you can use Opsworks Stacks. If you need the fine grain control of creating your own environment you can do it in EC2.

My struggle was in weighing these very similar options and making a choice on a solution. I’ve been going through that same struggle with AWS Proton. There are a lot of different serverless and CI/CD management options available inside of AWS and it can be dazzling to try to understand how they all fit together

AWS Proton AWS Cloudformation AWS CDK AWS CDK Patterns (e.g. the ECS patterns) AWS ECS Copilot AWS ECS CLI AWS SAM

I use a few criteria when evaluating which tool to use for a new environment. The first is how common is your use case and how strict are your security requirements.

Opinionated but transparent: SAM, ECS CLI, ECS Copilot, AWS Proton Flexible: Cloudformation, CDK Frameworks with lots of examples: CDK Patterns, SAM, ECS CLI, Cloudformation Framework you’ve spent time in: If your use case is special get comfortable with one of the flexible frameworks, but typically pick the one you’ve done the most with

And you can wind up orchestrating all of these with combinations of codepipeline and codebuild.

You can design and build the smoothest CICD pipeline, but it will provide zero value if the team has workflow that doesn’t work with it (did I tell you about the time no one was merging to master?), so the second criteria are how engaged the development team is in maintaining the IaC and how interested they are in learning about infrastructure.

With all of that lets briefly break down the services I listed above

AWS Proton

Proton looks flexible because it’s jinja on top of cloudformation you can do anything you can with cloudformation. I don’t think it would lend itself towards developer insight or experimentation. I would use this when

You have a lot of microservices that use consistent AWS services You have a separate infrastructure team You need strong guardrails in place to ensure cost/security/reliability You have a developer team that is comfortable being a little distant from the details of their app deployment

From the looks of it you will probably wind up with some clicking in the console to create and publish Proton template updates.

My main impression from Proton is that AWS is acknowledging that

Not all teams are going to CICD every aspect of their app deployment (Proton seems more friendly with the console than with a CICD pipeline for the templates) Not all development teams will manage their own infrastructure Some infra teams need to be able to set out guardrails for how apps are deployed in their environment

Cloudformation

Cloudformation has incredible service coverage and documentation. The downside is that the templates can be verbose and you may not like the defaults it picks. Use cloudformation when

You have slowly changing infrastructure You have strict security requirements You use a wide variety of AWS services You don’t want to learn one of the programming languages CDK is available in

CDK and CDK Patterns

CDK essentially puts a programming language on top of cloudformation. It’s a great gateway for getting developers to start interacting with infrastructure through code (between you and me you need the same amount of infrastructure knowledge to use either). The downside is that it will insert a lot of defaults and depending on your security requirements those may not work for you. Use CDK when

You have an infra team that’s willing to learn one of the programming languages CDK is available in You have rapidly changing infrastructure and want to see those changes in code You have strict security requirements and need to be able to see the defaults (they’re there if you dig)

Use CDK patterns when

They fit the stack you’re trying to build You won’t have to modify them to get your environment the way you way You have a development team that’s engaged in managing their infrastructure

AWS ECS Copilot and ECS CLI

I haven’t used copilot much, so I have fewer opinions here. From what I can tell you should use them when you’re in a containerized world.

You aren’t too concerned about creating lots of repeatable stacks with parameters (like you would with Cloudformation) You fit solidly into the ECS world without the need to orchestrate other services in the same tool

All of the other tools fit pretty smoothly into Codepipeline (Cloudformation can be versioned next to your app, CDK can run in a codebuild job triggered by codepipeline, etc). But ECS Copilot will be a little more work to get a fully managed stack.

AWS SAM

AWS SAM is really useful — it’s AWS’s response to the Serverless Framework and does pretty similar things. SAM is helpful when you fit into the serverless world (i.e. your application is all Lambda functions), but you still need to create similar environments with parameters on top of them. Use SAM when

You are app is 100% serverless and mostly uses constructs supported by SAM You want to embed your app environment with your app code You may need to break out to cloudformation at times You are going to use the SAM Local tools for testing

There you have my breakdown of a few different app deployment services. There’s plenty of overlap here, and each of these services can get you to successfully deploying an app to production. My last few tips on choosing one are