Based on the comments on this thread:
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.
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?
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. :)
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.