[kempbellt]

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.

[oh_sigh]

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.

[kempbellt]

"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.

[jfengel]

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.

[flatline]

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!

[kempbellt]

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.