AWS Proton is a service that lets you coordinate the work of infrastructure and platform teams for them to define prescriptive AWS environments that developers can use to deploy their applications.
Using Proton, infrastructure and platform teams can define environment and service templates describing the combination of resources that developers can then use to deploy their applications. An environment template represents the shared resources that Proton services will use. Think of resources such as VPC or load balancers, for instance. A service template defines the entire set of resources composing the infrastructure and platform that developers will be pushing their application to. This can also be applicable to resources such as, for instance, a backend service or an SNS topic to publish alarm notifications.
Proton environment and service templates can be authored either in AWS CloudFormation YAML or Terraform HCL format. The AWS Proton team maintains a library with some curated sample Proton templates, for both CloudFormation and Terraform. These sample templates address common cloud application design patterns, such as event-driven architectures (using Lambda), or internet-facing or backend container services (using Fargate or EC2-based ECS). Additionally, if none of the provided sample templates matches your use case, you will have to roll your own templates, but they can at least serve as an example for some extra guidance.
Proton is an opinionated service in how it delivers support for application lifecycle management. When your infrastructure is managed by Proton, the service automatically provisions a CI/CD pipeline that manages the lifecycle of your application, from storing the code in a Git repository, through building and packaging your application, to the actual deployment of your application on top of the AWS resources defined in your Proton environment and service templates.
Moreover, Proton also created the notion of components as a mechanism for developers to customize service templates. Components provide developers with some flexibility to extend the infrastructure templates. A development team may define their own application-specific components, such as DynamoDB tables, for instance. So, which resources should be part of the infrastructure layer (environment and service) and which should fit in the application layer (component)? Suppose everything in an application design that constitutes a moving target and will likely change frequently is a good fit for components.
Infrastructure and platform teams, owing to Proton, can enforce their standards and guidelines into codified and maintained templates that directly address the specific needs of one or more development teams. Proton also lets them manage their template’s lifecycle, so that the infrastructure resources they provide can adapt to technology evolution or changes made to their own standards.
For developers, Proton ensures that they directly focus on writing application code without having to worry about the underlying infrastructure or the CI/CD pipeline to support the development lifecycle. Even if Proton is prescriptive in many ways, developers still have some degree of freedom and flexibility to design and create their applications and focus exclusively on the business logic and not the underlying plumbing.
So far, you have reviewed the plethora of options available to you for deploying resources on AWS, including some of the best practices to follow. The next aspect to cover, one of the key best practices in general for any AWS resource or event, is monitoring.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
