I didn't realize AWS didn't have this already! I've been working exclusively in GCP for the past few years, and I assumed the two platforms were at parity. Is AWS starting to lag behind in new features?
My impression is that the stuff that GCP does have tends to be more capable and production ready (although I'm curious if others would disagree with that).
The only one I can think of that might be in this category is SimpleDB. AWS recommends you use DynamoDB instead of SimpleDB for new applications.
However, I wouldn't call SimpleDB abandoned. SimpleDB continues to work as it has for may years.
One thing that AWS is amazingly good at is not breaking existing customers and their applications. Did you build an application 10 years ago based on SimpleDB? All the APIs you used 10 years ago are still there and available to your application today. Its really quite amazing how dedicated AWS is to not breaking existing customers.
Otherwise yeah, there might be too many ways to do the same thing, but AWS generally has a stellar track record of supporting everything else they have made.
I'm searching just now over *.amazon.com and nothing comes up. The product pages also bear zero indication of that.
Amazon are like the anti-Google: rather than killing products, they're happy to have them limp along forever.
https://aws.amazon.com/blogs/compute/implementing-dynamic-et...
Fair enough that services often continue to work the way they always have, but I'm thinking more of the case where you're actively developing something, and the AWS service has major bugs or is missing significant features that all the alternatives have which makes your job harder building on top of it.
Elasticsearch was a famous example, it went years without any updates during which time upstream Elasticsearch itself improved dramatically. Then they picked it back up again once the elastic.io hosted product got good enough that it was a much better alternative.
Another example is ECS, which was out in the wild for a couple of years with a very limited feature set while GKE was completely eating its lunch and upstream Kubernetes got a lot of major improvements. Then AWS released EKS which sort of seemed to replace ECS for a while, but they have gone back and forth now for a bit with ECS having some features that EKS didn't have (e.g. fargate for a long time) and vice versa.
There are all sorts of other support bugs I've stumbled across in their forums, too many to recall. Often years old threads that have never really been addressed.
Edit: another one that comes to mind is cloudwatch/the entire monitoring & logging stack. It's very basic, not really a viable alternative at all to something like splunk. As such an important thing, I always kind of expected it to get better but it just didn't, you had to export your own logs/events to a separate ES cluster, or to Redshift via S3, or something else, etc. Whereas GCP Stackdriver is a much better solution out of the box.
Last version was 10 years ago and this service is one of the core AWS services, so it's definitively not abandoned.
Unless I'm confusing your comment.
Its not obvious to me why supporting a newer wire format would be a high priority for AWS. I think I would rather they work on things like native JSON/semi-structured data support[1] than a new wire format.
[0]: https://aws.amazon.com/redshift/whats-new/ [1]: https://aws.amazon.com/about-aws/whats-new/2020/12/amazon-re...
[1] https://docs.aws.amazon.com/cloudsearch/latest/developerguid...
I used CloudFormation for a few years and ran up against a lot of its limitations. Maximum file size. Maximum resource count. Automatic rollbacks of THE WHOLE STACK on any subsystem failure like unavailable instance. It has no templating built in, so doing ten things with minor differences means copying and pasting 10x or deploying your own templating solution to generate CF. And I did this back in the ROLLBACK_FAILED days, where if you did something that it couldn't automatically undo you were stuck - no way to roll forward or backward, just abandon innplace. The button for "Continue rollback" or whatever that came out 5-10 years ago was huge.
Contrast that with Terraform: all of your points addressed, plus all of mine are non-problems. It lets you do some awesome things that are no doubt inspired by CF, but it takes them to an entirely new level.
There are a few downsides too, but nothing compared to CF. You can build too-complex things much more easily in TF, so you have to be careful not to go overboard. It also bugs me that I can't spec a high-level thing like "compute with 4 cores and 32GB RAM, repeat 10x and put behind a load balancer with DNS name foo" and use it anywhere, I have to say google_compute or azure_load_balancer or aws_dns. That was the biggest disappointment coming out of CF and hearing how awesome this thing was, and then realizing it still left me vendor locked.
I totally can see where this is coming from :) CFN is best used as separate templates/stacks for parts of the solution, not the whole solution rolled in a single template. Reusable is the key word here, and Parameters. Let me try a city example. Have separate templates for a school, fire departnemt and house block. Build all Detroit schools using the same school.yml template, just supply different parameters for each. Don't copy-paste code from school.yml into detroit.yml. Actually, there should be no detroit.yml, leave city level to CI/CD job.
> I have to say google_compute or azure_load_balancer or aws_dns
Multicloud? It rarely makes sense. All you get is triple the infra code, triple monitoring tools, triple devops competence requirements. Properly designed solution with HA and AZ/regional redundancy is sufficient on a single cloud platform.
It tends to be badly implemented, but it makes a ton of sense as a strategy.
It would be limited to least-common denominator just because of the vagueness of objects that it would support, but the example I suggested would be incredibly useful.
Thats exactly why it is not useful. You design your solution using all features of the LB, solution using only basic ones will be meh.
Maybe CF has gotten better, but I'm not sure since I totally jumped ship for GCP.
Talk about damning with faint praise.
> It rolls back,
Sometimes.
> no leftovers on delete,
Well, on successful delete, maybe. DELETE_FAILED with partial stack deletion is a thing (and a thing CF could fairly trivially avoid in some common cases by simply querying resources for deletion protection.)
> full control of resource properties
Except the AWS resources it doesn't support, and properties of supported resources it doesn't support, because CF always lags the underlying services and their APIs.
That is until I realized that nothing worked. You had to use a version that was 5 versions behind the current version which is the opposite of what the documentation said which explicitly said not to use that version. Even then not everything worked out of the box.
https://docs.aws.amazon.com/streams/latest/dev/shared-throug...
I would classify this as a critical issue, and this is part of the reason why we stopped using Kinesis entirely.
https://chrome.google.com/webstore/detail/console-recorder-f...
From my understanding each service team within AWS is run pretty much as it's own little startup which sometimes make features across services, i.e. tagging, be inconsistent. It also leads to why the UI seems to be so fractured.
If AWS lacks anything, it is a "why the hell this API call failing exactly" feature. It is horrendous to debug a resource that is using other resources and you do not have any means to get what _exactly_ is missing. Usually you get an error like "s3 throw a 403, bye" message. The closest to a solution is CloudtTrail with giant amount of JSON entries to go through or try to load it to Athena or other database, and because you do not know what exactly you are looking for it is very hard. I usually just ask the support to debug it for me because they have internal tooling that can do that. Most of our support tickets fall into this category.
However, those instances get used in more of a "pet" than "cattle" context.
The difference being that you have to launch & maintain the server yourself (and pay for its runtime).
This probably abstract away the .aws profile? I can't see much reason to use it since I use aws cli just fine in the however many terminal tabs I have.
- You have to install CLI components piecemeal on GCP, and sometimes need to opt into beta features. With the Cloud Shell, it's all preinstalled for you.
- You have to "log into" the CLI if you're running it locally, which can be a minor annoyance. (I know the AWS CLI doesn't have this issue, as it doesn't use OAuth for authentication with the console.)
- All of the data transfers in Cloud Shell are happening between machines in Google's data center, so you get gigabit speed file transfers in the Cloud Shell. For example, this is super useful when you need to download a large bucket to a working directory to make edits to multiple files, or if you need to run scripts that pull and push to/from Cloud Storage.
I think a Cloud Shell for AWS is a net positive! It can make some workloads easier and reduce the amount of configuration you need to do.
https://aws.amazon.com/about-aws/whats-new/2020/12/amazon-s3... + https://github.com/gaul/are-we-consistent-yet/blob/master/RE...