AWS Proton
aws.amazon.com
aws.amazon.com
Amazon has a real problem if even the HN audience can't easily figure out what a new service is.
I actually didn't get it either, and came to the comments for help.
That seems fairly clear to me. What am I missing?
What "different tools"? What kind of "infrastructure provisioning"? Code deployments from where, and to what? Monitoring of what? Updates to code, to the infrastructure, to tooling, or something else?
Is it an abstraction service that manages CodeDeploy, EKS, and CF underneath? Is it something completely new?
It is very fluffy language that tries to make Proton sound awesome, but explains absolutely nothing about what it actually does without any context.
I feel who have responded to my initial comment want the first sentence to be completely understandable by a layman, but simultaneously technically detailed. Those two goals are frequently mutually exclusive in a short piece of text.
^ understandable (or at least Googleable) by a layman. And it includes at least some technical detail that paint a picture of what the service actually does (if it does this).
To answer your question bluntly: Yes, it is possible to be much more descriptive and still simple with an opener.
As it currently stands, I had to go to the FAQ to see an off-handed note about CloudFormation. No other services, tools, or technologies are specified. I'm just guessing by the buzzwords used to describe the service.
That's OK; I just read this as "not for me". Every time I touch AWS, I get the impression that it's for large-scale deployments of stuff that's way out of my hobbyist league. I'm sure I could get it if I put my mind to it, but I'm just as happy that I don't have to.
What Amazon has done is take these workflows and make them very developer friendly. You can save some time and energy (and money) using EKS over managing your own kubernetes nodes on EC2, for example. Or you can use their native services that provide other niceties. Welcome to the latest form of vendor lock-in!
For a hobbyist, lambda is basically always free - so long as you stay under 1 million requests and 3.2 million compute-seconds per month. Super friendly for just playing around with, imo. I barely pay anything for the hobby projects I run in AWS - literally pennies per month.
Much of AWS' praise comes from the ability to scale projects if there comes a need. If your hobby project running on 5 lambdas gets super popular over the weekend and you suddenly need 10,000 times the power - done. AWS handles this kind of dynamic scaling extremely well, and reliably. So well in fact, that you might handle a 10k X increase in demand without even noticing, because AWS is that flexible, until you get your bill and realize that you exceeded the free tier - be careful with this ;) This is why a lot of big-name software companies use AWS though.
However, over recent years, there's been a lot of in-fighting in the community about which AWS services handle which types of projects better/cheaper/more reliably/etc. You can host a static site in S3 with lambda as an API backend and a DynamoDB for essentially no cost. You can also manually spin up an EC2 instance running Ubuntu, and write/deploy that site to the server by hand. There are also half a dozen other services that will spin up that EC2 instance for you, if you'd like to automate that process for any reason.
The confusing part about Proton is that it seems to be an abstraction service for other AWS services, that glues together functionality to make it easier for some niche purpose. I couldn't glean what that purpose is from the landing page, or what Proton is doing behind the scenes to accomplish it. So it's essentially a big ?? for me.
CloudFormation is...complicated, especially for an inexperienced AWS user. It's a power-user tool that you can use to define your AWS infrastructure with code, rather than manually within each service. It's very cool, and very powerful, but you can also get by completely fine without it in most cases. I would not recommend spending much time learning it without having a better grasp on the individual services you are trying to define first.
It's a monoid in the category of endofunctors.
The best analogy I came up with is "It's like kubernetes and jenkins had a baby."
Probably relevant tho is that I left after a year and am no longer doing DevOps because C/C++ low level mathy or systems oriented coding is fun, and actually makes sense to me. :)
"Just as a blueprint allows an engineer or an architect to sketch a project's design parameters, Azure Blueprints enables cloud architects and central information technology groups to define a repeatable set of Azure resources that implements and adheres to an organization's standards, patterns, and requirements. Azure Blueprints makes it possible for development teams to rapidly build and stand up new environments with trust they're building within organizational compliance with a set of built-in components, such as networking, to speed up development and delivery."
[1]: https://docs.microsoft.com/en-us/azure/governance/blueprints...
I think managing AWS will be a major application of early almost-general AI, because it is beyond human comprehension.
My first question when I see a product like this is, "Do the people developing the service actually use it themselves?"
I guess I won't be trying this until they support CDK.
For a small number of services, I find code template with Pulumi/CDK a much developer experience, rather than dealing CloudFormation templates directly
And by "a bit" I mean I'm still wondering what exactly this service provides.
Is this high-level management and grouping for CloudFormation templates?
And it seems to be based on CloudFormation templates https://github.com/aws-samples/aws-proton-sample-templates/b...
That may be OK if you exclusively run workloads on AWS. If they can get people to switch to it, that would seem to increase the friction of switching to some other provider (i.e. a business win for Amazon).
If you're invested in Terraform already, and have dealt with the headaches of managing that .tfstate file properly, this likely isn't worth looking at... yet. If you're a newbie and haven't really practiced Continuous Delivery before, this is a welcome addition to a gap in Amazon-provided tooling.
But for those of us who've been around the block with AWS... Yeah, we'll keep using Terraform and check back in a couple of years.
Not disagreeing with you, just posting information I've come across, they plan to support 3rd party tools including terraform and jenkins, how is unclear.
No different than sorting through which libraries you need to use and the docs for those libraries... That's... That's the job.
All the major clouds are the same, though. You have to sift through a lot of marketing pages and docs to find what you want. It's still better than the old days of managing it all yourself.
To be clear, I am looking for a way to click through some setup stuff in a user management console then set some configurations and never have to manage anything again other than pushing to git. I don't even want to setup my own Dokku server, I already do that and while it's not hard, I don't like having to update it and maintain it about once a month.
Yes. I do this with a very small config file with BitBucket Pipelines. It's easy to set it up with GitHub Actions or any other CI/CD solution.
The core process is:
1. Build your code
2. Zip the build
3. Upload to S3
4. Tell Elastic Beanstalk to deploy the S3 file
The BitBucket Pipeline I'm using is already configured with the code to do this, so you just specify some build commands and branches.
> To be clear, I am looking for a way to click through some setup stuff in a user management console then set some configurations and never have to manage anything again other than pushing to git.
That's exactly what I want(ed) and was able to achieve with Elastic Beanstalk + BitBucket Pipelines.
Probably useless for smaller organizations, but if you're a central technology team trying to engineer a safe cloud platform for your business units to develop, deploy and operate on, any improvement over what AWS provides to date would be welcome.
- https://docs.aws.amazon.com/proton/
- https://docs.aws.amazon.com/proton/latest/adminguide/index.h... (Platform Team Administration Guide)
- https://docs.aws.amazon.com/proton/latest/userguide/index.ht... (User Guide)
- https://docs.aws.amazon.com/proton/latest/APIReference/index... (API Reference)
Proton is an opinionated, 'self-service' application CI/CD workflow built on top of CloudFormation (for now, however it appears intentionally designed for future expansion).
The service defines separate workflows for two distinct teams in an organization, the 'Platform Team' and 'Developers'.
The Platform Team publishes two types of 'Template Bundles' ('Environment' and 'Service') for self-service usage by Developers:
- 'Template bundles' consist of a stack template (CloudFormation yaml that gets passed through a Jinja template filter), a schema file (defining inputs and outputs), and a manifest (metadata specifying the template language [CFn] and rendering engine [Jinja], intended for future expansion).
- 'Environment' templates define the set of shared resources and policies that Services are deployed into (e.g., VPCs, clusters, and shared load balancers or API Gateways);
- 'Service' templates define the AWS resources specific to the service (e.g., Lambda functions, ECS tasks, associated IAM roles, etc), Service bundles also include a separate 'Pipeline' template which defines a separate set of resources (e.g., CodeBuild Projects + CodePipeline Pipelines) used for building/testing/deploying instances of the service.
Developers then consume these template bundles for self-service deployment of CI/CD pipelines for their applications. First they create an Environment from a published Environment template, then create Services (containing one or more Service Instances) in an Environment from published Service templates. When a Developer creates a Service they connect it to their code repository, so new commits trigger the service pipeline to build+deploy the application code.
Finally, the Platform Team maintains its template bundles over time by publishing new minor/major revisions, and Developers manually opt-in to these version updates for their deployed Environments/Services.
The service also provides some curated template bundles (for Lambda and Fargate-based services), which is helpful because there's a ton of boilerplate in wiring up all of these parts together.
Overall, Proton seems to occupy a similar space as Service Catalog (admin-curated CloudFormation stack templates for self-service deployment by developers), but it provides a more managed, opinionated workflow with a shared Environment stack and separate CI/CD pipeline stack for each Service. Seems like an interesting attempt to standardize a bunch of these elements that go into a common use-case of CloudFormation-managed CI/CD pipelines for self-service application development.