AWS Proton(aws.amazon.com)
aws.amazon.com
AWS Proton
https://aws.amazon.com/proton/
71 comments
Literally the first sentence on the site is "AWS Proton is the first fully managed application deployment service for container and serverless applications. Platform engineering teams can use Proton to connect and coordinate all the different tools needed for infrastructure provisioning, code deployments, monitoring, and updates."
That seems fairly clear to me. What am I missing?
That seems fairly clear to me. What am I missing?
Literally nothing in that sentence explains what Proton really does, how people will use it, or what problem it solves.
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.
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.
Can the first sentence of anything ever answer those kinds of questions? The first sentence gives a fairly clear high level overview of what it does. You can continue reading to find out more specifics.
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.
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.
"AWS Proton: A one-stop-shop for managing your CodeDeploy, EKS, and CloudFormation and Lambda assets - providing a single place to monitor the state of your infrastructure and role out updates to your code"
^ 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.
^ 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.
As a professional developer with a very passing familiarity with AWS, that version is still unclear to me. Lambda is the only one I'm familiar with. I can guess something about CodeDeploy. CloudFormation has always been unclear to me, and a quick Google suggests that it overlaps with Kubernetes.
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.
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.
The technologies are not just for large deployments IMO, it's the next logical step of leveraging OSS software: composition at the service layer instead of binary interfaces. You can pull down an ElasticSearch image, for instance, to provide search for your application, and write against their REST API. It then gets rolled into an orchestration with your app. You can debug locally against the rest of the orchestration, then package the whole thing using a script and/or some config files and deploy it to a stand-alone server, the cloud, whatever. Set it up once and deploy anywhere without (too much) extra hassle.
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!
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!
Piggybacking on @flatline's comment: AWS is great for hobby projects as well. The beautiful thing is that AWS has free tiers for a lot of their services, so you can play around without committing much (if any) money. Check out https://aws.amazon.com/free/
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.
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 fully managed (meaning Amazon maintains it?) application deployment service (so, like CodeDeploy?) for container and serverless (again, CodeDeploy?). It allows you to connect and coordinate (?) all the different tools. I use AWS, CodeBuild, CodeDeploy, CloudFormation, Terraform, CloudWatch, etc. I don't understand from these two sentences where this falls into this, or if it's somehow meant to sit on top of it, etc. Like the GP, I came to this thread to see an explanation of what this actually means.
>Platform engineering teams can use Proton to connect and coordinate all the different tools needed for infrastructure provisioning, code deployments, monitoring, and updates.
It's a monoid in the category of endofunctors.
It's a monoid in the category of endofunctors.
Perhaps it's just confusing to people like me, who don't work on "platform engineering teams". The sentence is just too packed with terms I have no analogy for.
The best analogy I came up with is "It's like kubernetes and jenkins had a baby."
The best analogy I came up with is "It's like kubernetes and jenkins had a baby."
Nah, I worked on a "platform engineering team"/DevOps for a year and I have no idea what this service does or what it's for. I have a vague inkling, like I could make a guess, but even thinking about that makes my head hurt.
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. :)
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. :)
I don't really see the problem with that - you probably aren't the target audience. Good tools will frequently be specialized. You could probably understand the initial blurb for React or some library in whatever your speciality is that may just be confusing to a "platform engineer".
Hm, so, guessing from the description, it's like a new Slack, right? like a chat but for devops people somehow?
Reading this I think Proton == Waypoint for AWS services only. Still a lot of work to manage infra and cobble everything together and geared more towards platform teams at larger companies vs. everyday developers and startups.
This sounds similar to Azure Blueprints[1]:
"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...
"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...
this is the correct answer
Yet another meta Amazon Web Service with vaguely overlapping features.
I think managing AWS will be a major application of early almost-general AI, because it is beyond human comprehension.
I think managing AWS will be a major application of early almost-general AI, because it is beyond human comprehension.
It seems like we're seeing the outcome of an internal political battle for relevancy.
My first question when I see a product like this is, "Do the people developing the service actually use it themselves?"
My first question when I see a product like this is, "Do the people developing the service actually use it themselves?"
Maybe this is ok, because AWS is so large, competition of technologies is good and probably necessary for long term survival.
On the other hand, not very good if you're using Amazon and one of the technologies you've picked doesn't make the "survival of the fittest".
Maybe less likely than out in startup land where piecing many tools together? And at least everything works well together.
Taking a look at the template repo, it seems to be just CloudFormation at the moment: https://github.com/aws-samples/aws-proton-sample-templates/t...
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
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
What's CDK?
It's an AWS tool for writing infrastructure as code in a few different languages that compiles to a CloudFormation template.
https://docs.aws.amazon.com/cdk/latest/guide/home.html
https://docs.aws.amazon.com/cdk/latest/guide/home.html
AWS Cloud Development Kit
https://aws.amazon.com/cdk
https://aws.amazon.com/cdk
If anyone at AWS is listening, please fix your new pricing tool. I have been using AWS for damn near a decade and miss the old pricing calc terribly. This new tool doesn’t return search results for fargate or proton pricing. I always fumble around and eventually end up on a random blog just to calculate stuff.
That's one thing I liked about Google Cloud when playing with it. Their notebook environment tells me exactly how much my notebook will cost per month based on the VM settings. AWS (SageMaker Studio) doesn't even tell me what is running in an easy to access way much less future costs.
The FAQ has a bit more information: https://aws.amazon.com/proton/faqs/
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 by "a bit" I mean I'm still wondering what exactly this service provides.
Is this high-level management and grouping for CloudFormation templates?
This maybe explains a bit better https://docs.aws.amazon.com/proton/latest/userguide/Welcome....
And it seems to be based on CloudFormation templates https://github.com/aws-samples/aws-proton-sample-templates/b...
And it seems to be based on CloudFormation templates https://github.com/aws-samples/aws-proton-sample-templates/b...
It seems to be? Which is a deal breaker for me as I manage everything with terraform
Right, this seems to be a replacement for Terraform, with the caveat that it only works for AWS.
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.
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.
https://github.com/aws/aws-proton-public-roadmap/issues/1
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.
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.
I have no clue what this is, like everyone else, but if AWS released a Heroku-like deployment tool that scaled massively and only cost the underlying resources and a small fee, I'd use it immediately for almost all my Dokku projects. I'm waiting for a Heroku-like service from the major providers that abstracts away the deployment work, but isn't going to bust my wallet (Heroku is way too expensive for personal projects).
AWS has this. It's called Elastic Beanstalk. There's no "small fee" on top. It just costs the underlying resources.
Just the fee of your time sorting through which services you need and then the docs for those services - assuming of course you chose the correct service(s)
I mean, yeah. AWS has a big offering of services.
No different than sorting through which libraries you need to use and the docs for those libraries... That's... That's the job.
No different than sorting through which libraries you need to use and the docs for those libraries... That's... That's the job.
It's pretty annoying to do it yourself, but AWS also offers a lot of free time with their sales/accounts teams. You can just say, "Hey, I want a service that does _____" and be pointed at exactly what you need.
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.
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.
Can I push to a git repo and have it automatically deploy the code there, like in Dokku, without any work at all?
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.
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.
> Can I push to a git repo and have it automatically deploy the code there, like in Dokku, without any work at all?
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.
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.
Awesome! Thanks for that info! I think I'll try it out tonight, I still haven't used my free AWS products, so maybe I'll try a few others, too.
To be honest, Caprover does this easier than Dokku.
Uffizzi is cutting legs out of Heroku on price. It’s new - some of docs are lacking but great UX and has a cheaper pricing scheme.
Is Heroku that expensive? Uffizzi looks to be $20/m for the smallest tier. Which is significant for small apps imo - am i misunderstanding something? I thought Heroku and DigitalOcean Apps had ~$5/m options with no DB, and something like $10/m for App+DB.
SalesForce also has been slowly killing Heroku for years (including layoffs recently).
Second this
Render.com
i thought aws ligthsail or whatever did that
digital ocean apps may fit the bill?
This sounds like it's possibly a more comprehensive front-end to Service Catalog, maybe a bit more abstracted from the provisioning b/c it says 'infrastructure as code tools like CloudFormation' where Service Catalog is strictly pinned to CloudFormation. It also seems to include some facility for building the account itself (e.g. logging, vpc endpoints, etc) that today is just generally done with homespun IaC tooling and automation.
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.
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.
Is this using CloudFormation (shit) or can it be used with Terraform (not shit)?
CF, obviously - it's AWS! It probably will support CDK in the future (underneath is CF template), but I don't see terraform being supported unless AWS acquires the company
I would imagine that if there's enough demand there won't be very much lead time before it is added to Terraform.
Terraform competitor or complement? I have to admit, the overhead for setting up our AWS is quite a struggle for me, but I also tire of the continuing layers of AWS that could sometimes create a complete waterfall of problems (ahem, Kinesis outage). (EDIT: To clarify, the decision to use AWS for some things or all things.)
https://www.terraform.io/
https://www.terraform.io/
Here are documentation links with more detailed info (hard to find since they were not linked anywhere in the product page or announcement, seems like a rushed release):
- 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)
- 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)
How different is this from ElasticBeanstalk. Both wrap other AWS resources in a template. They both have notions of an application and set of environments. If ElasticBeanstalk did not succeed why will this succeed? Is it because it leverages Docker container/Lambda layers underneath instead of a custom build and packaging pipeline
Seems like an interesting product that I’m sure a lot of people have a need for. At first I thought it was going to be a Google Cloud Run / Azure Container Instances clone, but seems to be more fully featured like Netlify. Seems ripe for vendor lock in, though.
Looks like this is the GCR/ACI compete: https://news.ycombinator.com/item?id=25267182
AWS needs to start naming things in a more self-explanatory manner. So many services.
Maybe I'm not a 'Platform Engineer' but how is this different than Kubernetes?
Here's my attempt to summarize what this service actually does, after reading the documentation in more detail:
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.
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.
Would this work as a substitute for fargate + codedeploy + codepipeline?
Isn't this just CloudFormation?
This is the 5th amazon.com link trending on HN. Seems like AWS is releasing bunch of new features today.
It’s the annual conference, called reinvent.
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.