What you need to know about the new AWS Proton service

AWS Proton was announced at re:Invent 2020 and is a brand new service from AWS. It is designed for centralized engineering or platform teams to be able to define deployment templates for containerized or serverless applications. These templates can then be deployed by application teams with a minimal set of parameters.

AWS did an unboxing video for our Containers from the Couch series with a Proton engineer and product manager. If you'd like to see it in action you can check it out here:

Proton can be used to create an internal self-service platform built on AWS, completely customized for your needs. Proton allows platform engineers to create templates for services and environments so you can deploy and test your application. Each service template can be deployed to multiple environments to make easy and safe-to-deploy applications.

Service templates can include the application and any additional infrastructure needed by the application including CI/CD pipelines. This means Proton can fully automate the end-to-end application deployments with the required infrastructure such as databases and load balancers.

It's best to adopt Proton for your services when your organization is large enough to have a team that can create and maintain templates or when you have many applications that can be templatized. If you have tens or hundreds of similar applications that often duplicate effort to create infrastructure or deployment pipelines, then Proton could save your organization a lot of time and help with keeping consistent and up-to-date standards.

Because Proton can be managed by a centralized team and used by multiple development teams, the central team is able to create stacks and also update them on behalf of the application teams. This means application teams can focus on developing their apps and the centralized team can make sure their infrastructure is up to date and following the organization's best practices.

Proton templates include versions, so it's easy for the centralized team to see exactly what version template is being used by which applications and in which environments. Platform teams can update stacks on behalf of the application teams to make sure everything is compliant.

Application developers will be able to use the preconfigured service templates and environments to fill out the necessary information, connect their code repo from GitHub or Bitbucket, and deploy with minimal effort.

Some of you may be familiar with AWS Service Catalog. Service Catalog allows central IT teams to define approved AWS services that you can deploy and use with your application. This is different than Proton because Proton can define a full template of services to deploy a complete application stack into an environment.

In fact, you can use Service Catalog-provisioned products inside your Proton stacks! If you have a database team that creates Amazon Relational Database Service (RDS) products in Service Catalog, then the platform team can use those RDS instances to provide to application developers as one component of their deployment.

Here's the major difference between Proton and Service Catalog: when an RDS product needs updates, the platform team can automatically apply them for the application team. In Service Catalog, the database team wouldn't have direct access to the deployed products. For Service Catalog product updates, the DB team would need to coordinate with the application team to make sure updates are deployed.

Being able to fully define a stack increases developer productivity because the platform team can define exactly how the services should be deployed. The application developer doesn't need to select a VPC or availability zone if those options are defined in the service template.

Some people may wonder what the difference between Proton and AWS CloudFormation is. While both can be used for templated infrastructure as code Proton has a few key differences that users should be aware of.

The first difference: Proton provides a self-service web interface where users can easily discover and deploy the latest templates directly from within the AWS console.

Second is Proton's ownership model we discussed earlier. Users who deploy services and environments don't need IAM permission because ownership of the stacks remains with Proton. This simplifies what permissions are given to users and how updates to stacks can be handled.

The third difference is that Proton can be used as a generic templating engine. Support is planned to add other infrastructure as code template options besides just CloudFormation, such as HashiCorp Terraform and AWS CDK.

When a developer uses a service template, they can automatically get a CI/CD pipeline for their application. This functionality works similarly to AWS CodeStar. CodeStar lets you pick an application type and get an opinionated build pipeline without configuring everything from scratch.

Proton can also give you an opinionated CI/CD pipeline based on the service template the platform team created. One of the benefits with Proton is the environment templates let teams re-use pipelines to deploy the same application into a development, staging, or production environment.

Proton is free and you will only pay for the AWS resources provisioned from deployed templates. If you would like to get involved with future features and integrations, the roadmap is public on GitHub.
You can get started with Proton using one of the sample templates on GitHub here. If you already have an AWS account, you can start building with AWS Proton in the console today!