One of the reader reactions to the above blog a few weeks ago was on what Proton templates look like, what they do and how they are different from Infrastructure as Code (Cloudformation or Ansible or Terraform) templates. AWS hosts thousands of enterprise customers on their container platforms EKS and ECS. Proton provides platform teams with the tools to manage and enforce consistency across environments while helping developers as well.
https://www.vamsitalkstech.com/aws/how-to-create-a-fully-automated-cloud-platform-using-aws-proton/
Let me explain.
Container engineering teams in large organizations are typically organized into dev and platform teams. The dev teams focus on writing, updating and maintaining application services while the platform team uses tooling to create the platform on top of an IaaS or Bare metal or cloud. The tooling used by these teams includes observability, CI/CD pipelines and security software.
Templates are the way of bringing these teams together as can be seen in this illustration.
The process of defining a service template starts with adding in the definition of the above cloud resources – CI/CD pipelines, observability tools. Infrastructure teams can look over and manage these in the AWS Management console. In the first GA version, AWS Proton will integrate with commonly used CI/CD pipelines and observability tools such as CodePipeline and CloudWatch while expanding over to other popular tools such as Jenkins, Prometheus etc during 2021. We also provide curated templates that f common deployment patterns such as Fargate based webservices or serverless functions for Lambda.
This is what the list of templates looks like.
Now what makes up a template?
Anatomy of an AWS PROTON TEMPLATE
The Proton template is made of the pieces that will support your infra and code deployment end to end. It has 4 key components.
- IAC template parameterized – this means you will take the infrastructure as code that supports your application and select the parameters that developers will need to provide at the time of deployment. E.g. DNS Route for a microservice
- CI/CD template – define a pipeline using the template and parameterize it
- AWS Proton Schema is how you will tell developers what information is needed at the time of creation. Its written using OpenAPI and contains a list of all these parameters along with their potential input values
- Finally, a Manifest which tells us what all files to look for so that nothing is missing from the core template
You create a generic CFN template – StoreFront and StoreFront Staging – with parameters for the DNS Route object. Proton will inject the DNSRoute into those parameters. We then create a schema after that tells Proton that for every Service instance we are going to need a subdomain which is going to be entered as a string. We will see how this reflected in the developer experience. Whatever info they give us, Proton will inject these into the CFN template and it runs them for the developer.
Once created, the template is compressed and dropped into an S3 bucket. You will then see a Proton console as shown to register the template. You provide some additional details – service name, template description – metadata that allows developers to choose the right one they need.
Proton then shows them in the Service templates UI. Name, Descriptions and versions
AWS PROTON SAMPLE TEMPLATES
We want to support the customers with some sample templates to help them learn and practice. We provide a GitHub repo with sample templates. They’re well architected and can be used as a starting point for your own implementations. To use this repository, browse to the folder that corresponds to the template that you want to use. You will find there all the information you need to create environment and service templates and to deploy the corresponding environments and services. You will also find a link to a repository with basic code that runs on each one of them, in case you want to fork it to use it as the basis for your deployment.
Keeping Infrastructure updated through template versions
It is critical for customers to keep updating their environment via versions. If a template changes or is updated, there is a new version of the template that’s available.
We divide template versions into two categories – Minor and Major.
A Minor change is when you update your infrastructure. Maybe you are adding a new IAM role or changing a role in one of them. In Proton you can
Major versions are when schemas change (e.g. In your Fargate service you need developers to be providing the amount of memory they need your FG instance to be using). Proton requires new inputs from the developer due to template schema changes. AWS Proton makes a best-effort attempt to determine whether the new version’s schema is backward compatible with the previous minor versions of the template. However, it doesn’t check if the template bundle CloudFormation template is backward compatible with the previous minor versions. For example, AWS Proton doesn’t check if the new CloudFormation template will cause breaking changes for the applications that are running on the infrastructure provisioned by a previous minor version of the template.
When a new version’s schema is backward compatible, you’re responsible for determining how changes to the template bundle CloudFormation templates impact applications and resources that are running on previous versions of the environment template. Based on the determination, you, as an administrator, decide if the new version is designated as a major or minor version.
When you publish a new version of an environment template, it becomes the Recommended version if it’s the highest major and minor version. New environments are created using the new recommended version, and AWS Proton prompts administrators to use the new version and to update existing environments that are using an outdated version.
The console enables you to view all your templates and the versions etc. It also lets you view the existing instances using it.
Hope this blog post helps clarify this aspect of the platform. Comments and feedback are welcome!!