[HN Gopher] AWS Cloud Control API, a Uniform API to Access AWS a...
___________________________________________________________________
AWS Cloud Control API, a Uniform API to Access AWS and Third-Party
Services
Author : lukehoban
Score : 89 points
Date : 2021-09-30 19:19 UTC (3 hours ago)
(HTM) web link (aws.amazon.com)
(TXT) w3m dump (aws.amazon.com)
| spullara wrote:
| It is super interesting to me that they now have essentially a
| declarative API in CloudFormation and now this corresponding
| imperative version with the same format. I'm not quite sure why
| you would need the imperative version. Anyone have any ideas?
| Couldn't Pulumi have just compiled their code into CloudFormation
| and deployed it?
| rhooke wrote:
| Imperative version can fill more dynamic use cases, like
| spinning up entire servers in response to something (eg user
| wants to create a game server at the click of a button).
|
| Not something you can easily do with the declarative version.
| spullara wrote:
| That new game server could just be another cloudformation
| stack but I get your point.
| dragonwriter wrote:
| > Not something you can easily do with the declarative
| version.
|
| Its something that you can do easily with the imperative API
| _for_ CloudFormation plus the declarative description of the
| stacks _in_ CloudFormation.
| lukehoban wrote:
| CloudFormation is really three separate things rolled up into
| one: (1) a resource model for AWS, (2) a deployment
| orchestration engine and (3) a syntax for specifying desired
| state as CloudFormation templates.
|
| Tools that compile to CloudFormation templates offer a way to
| access (2) directly - to use alternative front-end syntaxes but
| to still deploy via the CloudFormation orchestration engine.
|
| Tools like Pulumi (and Terraform) have their own deployment
| orchestration engines, which we believe offer many benefits -
| performance, secrets, components, transformations,
| aliases/refactoring, multi-cloud provisioning, and a lot more.
|
| Cloud Control API lets us (and others like us) access (1)
| directly, without having to use (2) or (3), and thus being able
| to still offer the full set of benefits of provisioning via
| Pulumi, along with the full set of benefits of a well-defined
| AWS resource model.
| k__ wrote:
| Pretty awesome. Now IaC tools like Pulumi will be always up-to-
| date.
| lukehoban wrote:
| Indeed! And we just released a new AWS Native provider which
| builds on top of this new AWS Cloud Control API:
| https://www.pulumi.com/blog/announcing-aws-native/.
|
| I'm really excited about what Cloud Control API enables more
| broadly as well. I see this as a new high bar for cloud
| provider resource provisioning APIs, and it's an approach I
| hope to see more of across the industry going forward.
|
| Previously, to provision and manage a resource, you would need
| to find the REST APIs for that specific resource, and define
| your own model for what set of REST API calls constitute a
| logical Create, Read, Update or Delete operation. This work was
| done and re-done in dozens or hundreds of cloud provisioning
| tools.
|
| But AWS themselves had already built a model for doing this,
| and service teams at AWS were already defining their own well-
| defined resource model - the CloudFormation resource model for
| their services/features - it was just locked up behind
| CloudFormation templates as the only way to author and deploy
| resources using this resource model.
|
| With Cloud Control API, all of the value of that resource
| model, and the work by teams at AWS to cleanly define that
| resource model, is now unlocked to be used by any sort of
| provisioning tool or service - not just CloudFormation
| templates.
|
| At Pulumi, that has enabled us to build our new AWS Native
| provider on top of Cloud Control API, but it opens up tons of
| additional scenarios as well. Kudos to the AWS team for their
| work on this!
| k__ wrote:
| Is a native provider planned for Cloudflare?
| mwcampbell wrote:
| Now if we could just use cfn-signal (or something like it)
| when setting up an EC2 auto-scaling group without having to
| create a Cloudformation stack behind the scenes as the Pulumi
| awsx package does.
| nprateem wrote:
| I wonder how long before this becomes a standard like swagger.
| People will create a spec for a well-known endpoint and probably
| call it CURDL that allows APIs to be self documenting and
| automatically compatible with a general universal API client. No
| one will have to maintain their own clients any more and everyone
| will wonder why it took so long to think of this...
| robxu9 wrote:
| There's Smithy, which tries to help design API operations
| around a resource in a CRUDL-like fashion - I think that's what
| you're getting at? https://awslabs.github.io/smithy/
| cperciva wrote:
| There's an xkcd for that: https://xkcd.com/927/
| mooreds wrote:
| Not sure why you are getting downvoted, this was the first
| thing that sprang to mind for me.
|
| "Oh, yes, another option." On top of terraform, pulumi,
| CloudFormation, the AWS SDKs, the CLI, and the CDK.
|
| I mean, I appreciate them trying to push things forward and
| realize all options aren't all equivalent, but where's the
| deprecation to make things simpler?
| ablekh wrote:
| I'm really excited that Pulumi supports this from day one:
| https://www.pulumi.com/blog/announcing-aws-native.
| OJFord wrote:
| Why: aws cloudcontrol delete-resource \
| --type-name AWS::Lambda::Function \ --identifier
| ukjfq7sqG15LvfC30hwbRAMfR-96K3UNUCxNd9
|
| and not: aws cloudcontrol delete-resource \
| AWS::Lambda::Function \
| ukjfq7sqG15LvfC30hwbRAMfR-96K3UNUCxNd9
|
| (and why 'cloudcontrol' for that matter, not top-level CRUD)
|
| Awscli loves its arguments. Several people are going to point me
| at autocompletions, tell me zsh has this really great feature
| where .. all fine. But why have this 'problem' to solve in the
| first place? I don't get it.
|
| For non-interactive use, sure, I don't care how verbose it is,
| it's even a sort of self-documenting feature. Is that it? They
| just really want all interaction via the web console?
| 015a wrote:
| All AWS CLI commands follow the format 'aws [service] [action]
| [flags...]'. To my knowledge, there are exactly zero instances
| where positional arguments are used outside of naming the
| service and action; its always flags.
|
| Whether this is best or not is a different discussion; I'm
| simply pointing out the irony of suggesting the CLI API for a
| service designed to make their APIs more consistent, should be
| inconsistent with the other CLI APIs customers are used to.
| OJFord wrote:
| Yes I know, I was sort of using it (new CLI designed to be a
| better interface) to say why is it so.
|
| Apparently I hold a minority opinion that's so offensively
| contrary it deserves downvotes though!
|
| I maybe didn't make it clear enough, but I think it's
| somewhere between 'don't care either way' and 'great' for
| non-interactive/scripted use. I just don't like the UX at all
| for using it interactively, I find it extremely slow and
| cumbersome.
|
| This looks to be a big improvement, but - to me - just leaves
| such easy obvious trivial stuff on the table.
| la6471 wrote:
| That is a solved issue . It is the standard way of command line
| syntax and provides a common way of parsing command line for
| many OS. You can certainly do things "another" way but all it
| will do is break decades worth of work for standardization and
| good old fashioned common sense. Make things modular so you can
| expand in different ways.
| OJFord wrote:
| Well that's not really true, or at least incomplete. GNU &
| BSD have different styles; I believe both do
| positional/unnamed arguments.
|
| It's true that awscli goes for all --named=args currently,
| but that's not decades of it not happening in general, and I
| just commented on wishing it weren't the case here.
|
| I think this is a great simplification/abstraction, and I
| don't see why it couldn't go further and just be `aws <crud>
| <type> <resource>`. But that's apparently highly disagreeable
| even as a mere thought or suggestion, so I'll shutup.
| justicezyx wrote:
| Other than the flag name, what's other significance of this
| difference? The flag seems trivial to me. Warp it in a shell
| script seems sufficient.
| OJFord wrote:
| What do you mean other than? I removed it, that _is_ the
| (entire) difference.
|
| > Warp it in a shell script
|
| As I said, for non-interactive use of course I don't care.
| But trying to actually do/check/test anything with awscli
| interactively/'manually' is pretty painful IMO.
| cheeze wrote:
| I disagree here. The first example is much more self-
| describing and follows the same paradigm that the rest of
| the AWS CLI already follows. I'd prefer erbosity here
| rather than the AWS CLI trying to figure out what I'm
| doing.
| jen20 wrote:
| I'm of the same opinion - I'd rather not have to consider
| the argument order, and instead just be able to append
| flags to an interactive command in any order I see fit as
| I'm refining queries.
| Deathmax wrote:
| And you no longer have to worry about the meanings of
| positional arguments changing between versions and
| potentially running the wrong command.
| orf wrote:
| The AWS CLI is old and for the most part auto-generated from
| the API definitions. I actually prefer the first example to the
| second one, but in general I'm happy that it's consistent. Even
| if it's sometimes consistently annoying (help, not --help).
| riffic wrote:
| jeez write your own wrapper script then. I don't understand
| what this needs to be bikeshedded for.
| shaicoleman wrote:
| They only released support for it for the legacy AWS CLI v1, but
| not for AWS CLI v2.
| nprateem wrote:
| I don't know why hashicorp and pulumi are all smug about this. In
| one go it's destroyed half their moats.
| OJFord wrote:
| I don't know anything about Pulumi, but for Terraform I'd say
| err no?
|
| Terraform is declarative; this is imperative.
|
| Terraform doesn't try to make a common CRUD interface to
| everything on AWS; that is the sole distinction between this
| and the pre-existing CLI.
| mwcampbell wrote:
| Not really a moat, at least for HashiCorp. Consider that Pulumi
| was able to get off the ground by using Terraform providers,
| including HashiCorp's AWS provider, behind the scenes.
| neximo64 wrote:
| People use Hashicorp and Pulumi not to use AWS by api but to
| provide options to move to other providers easily.
| VWWHFSfQ wrote:
| I don't think the (theoretical) ability to move to another
| infrastructure provider is the main motivation to use those
| tools. It might be a supporting motivation. But definitely
| not the real reason why they're using it. Hardly anybody
| actually changes their infrastructure provider anyway
| mdeeks wrote:
| Terraform has multi-cloud support but it is not cloud
| agnostic. You have to rewrite your terraform for the things
| that you want to move to another provider.
|
| Moving to other providers is unfortunately rarely easy except
| for all but the most basic infrastructure.
| rad_gruchalski wrote:
| If it only was so easy to move! Sure, one tool, one
| configuration format but it's not so easy to simply change
| some configs and move.
|
| Even going for the provider lowest common denominator implies
| maintaining different configurations.
| streetcat1 wrote:
| I think that the main usage pattern for a tool like terraform
| is be able to version control your config, and , on the way,
| apply the git flow/git ops to infra changes (infra as code).
| dfinninger wrote:
| In most places I've been, Terraform was used more for
| documentation than mobility. Sure, you don't need to unlearn
| Cloudformation if you switch to GCP, but you have a ton of
| AWS-specific stuff in your TF config that's going to need to
| be ported to the appropriate counterparts in your next cloud.
| But having a documented change history in Git for (almost)
| everything was much more useful than theoretical mobility.
| Dunedan wrote:
| Luc van Donkersgoed wrote a blog post about inconsistent AWS APIs
| just a week ago [1]. Funny coincidence.
|
| [1]: https://www.lastweekinaws.com/blog/how-aws-dumps-the-
| mental-...
| arpinum wrote:
| Since this is from CloudFormation team, what can we expect about
| the performance vs calling the APIs directly? CloudFormation is
| not known for its speed.
| jfcllotr wrote:
| ^ This. Surprised no one has enquired about the overhead of
| this abstraction layer.
| m0zg wrote:
| Just buy Pulumi already and have them do it the way it's supposed
| to be. It's ridiculous that AWS documentation usually contains
| dozens of error prone manual steps.
___________________________________________________________________
(page generated 2021-09-30 23:00 UTC)