Building a "Curated Infrastructure" With AWS Proton
Building a "Curated Infrastructure" With AWS Proton
Simplifying infrastructure by centralising it
Just over a year ago, AWS launched AWS Proton, a service that promises to automate the deployment of serverless and container-based applications.
I think that, in principle, the idea behind Proton is a very powerful and much-needed one.
Since a lot of people have either not heard of or not had a chance to play with Proton, I figured it would be useful to introduce it here.
What It Is
AWS Proton is a fully managed service that allows organisations to centralise the creation, distribution, and update of the infrastructure needed to run services.
It is trying to address the following needs:
Reducing divergence between different services
Increasing adoption of best practices
Automating and simplifying security reviews and updates
How Does It Work
There are 3 elements to an AWS Proton setup, the last of which is optional:
Environments
Services
Components
Each one of these elements is defined via Infrastructure-as-Code Templates (Cloudformation or Terraform, but with some additional elements).
With Environments, the basic foundations can be established and shared across resources. For example, I may want to have a dev environment where certain endpoints are not exposed to the public but only accessible from within the company intranet. Similarly, the production environment may have a certain domain attached to it.
Services are where most of the substance resides. Here we can get more specific, as we define the entire infrastructure that is going to characterise our applications. For example, if I have a microservice architecture where each service uses Lambda, DynamoDB, and API Gateway, I can build a Service Template for that. Developers can then access the Proton console, and spin up a new instance of this service whenever they need to create a new microservice.
Lastly, Components are additional blocks of infrastructure that developers themselves can add to an existing Service. These are, again, defined as simple IaC Templates. Administrators can establish guardrails around what types of Components can be created or, more broadly, what permissions should they have.
When Should I Use It?
Arguably, AWS Proton does not have the best User Experience. It’s a “serious” tool, and the implicit expectation is that no one is going to start using it without reading the docs first. That may explain why despite the excitement at the time of its announcement over a year ago, AWS Proton doesn't exactly seem to have captured many hearts.
Also disappointingly, AWS didn’t think to add first-class support for the CDK. It should still be possible to use the CDK to generate the Cloudformation template, but it means adding an extra step to the process and setting up some extra tooling to automate it all.
Nevertheless, AWS Proton is a very powerful service. It addresses a need for standardisation, enhanced security, and best practice enforcement that most teams usually have to either live without or come up with in-house tools for. Taking the time to read the docs is a worthwhile investment; there are videos and tutorials out there that can help us out.
In my view, teams should consider adopting AWS Proton to enhance the quality of their software as well as to simplify and speed up development. The lack of native CDK support, as mentioned, is a problem. That may be a valid reason to wait out until (hopefully) support for it is introduced.