How to found latest supported version for an AWS service? Not latest.
For example for Amazon SQS?
The current API version for SQS is 2012-11-05, as noted at the top of each page of the SQS API Reference.
Most services list their current API Version this way -- at the top of each page in the API Reference for that service.
The AWS service APIs are usually very stable, so AWS doesn't always bump the version when enhancements come out. That means the date 2012-11-05 for SQS doesn't imply that the API is completely unchanged for 5+ years. Instead, it means that no breaking changes have occurred to the API, and libraries written against any iteration of the 2012-11-05 SQS API will continue to work for all the features that particular library implements, going forward.
There is essentially never a need to specify an older version, nor a need to change the version you reference in any particular project of yours to a newer API version, unless you are trying to use a new feature that is only a available via the newer API release... which generally means your supporting libraries/SDK would need upgrades as well... so once you configure this, there's not often a need to change it.
There is a full list of versions for 3.X services here: https://docs.aws.amazon.com/aws-sdk-php/v3/api/index.html
A managed service, such as Amazon SQS, has one version. There are no lists of supported versions to have to maintain/understand.
Are you talking about different versions of, for example, a java library for SQS?
Related
We're new to Amazon Seller Partner-API. Need to invoke certain Amazon SP-APIs for an integration workflow. For some internal reasons, using Amazon SDKs is a secondary option. With our conventional approach, we're able to interact with most APIs, in this case the AWS Request signing & Signature generation is where we're stuck.
As per Amazon using SDK handles it all internally. Is it possible to use a command line utility like - AWS CLI to interact with SP-APIs? Not sure if this is feasible. Found this - amazon-sp-api but not sure if it is stable / reliable.
I believe there should be ways to interact with SP-API from command line. If not, atleast there should be a tool that is able to produce AWS Request signature (given the request info, key etc...).
Kindly share your experience and expertise. We're new to AWS, so if I'm confusing AWS with SP-API (esp for Request signing - I believe both use the same mechanism) pls point it out.
The link you shared to amz.tools does not look like a command line interface. It is just an SDK generated in NodeJS. There is not way to connect to the API via command line. You can use Postman if you want to avoid SDKs.
And yes, AWS is not the same thing as SP API.
You can search github for SDKs generated on other languages; some seem to have a lot of use.
We generated our own SDK in C# because others didn't fit out criteria.
Ours is a Spring-Boot based application. For integration with AWS SNS and SQS, we have couple of options:
Use Spring-Cloud-AWS
Use AWS-SDK-Java 2
I wanted to know if there is any advantage in using one or the other.
When I ask AWS guys, they tell me that AWS SDK gets updated regularly and integration with SNS and SQS is not difficult. Hence, there is no need to integrate with Spring-Cloud-AWS.
I tried searching on gitter channel for Spring-Cloud and could not find any relevant information. Documentation does state that I can update the AWS-SDK version. Documentation does not state any compelling reason for not using AWS-SDK directly.
If anyone has some insights, please share.
From the AWS Spring Team:
"From now on, our efforts focus on 3.0 - based on AWS SDK 2.0."
So, if you need AWS SDK 2.0, you probably want to go directly with the SDK.
https://spring.io/blog/2021/03/17/spring-cloud-aws-2-3-is-now-available
For more on what's new on AWS Java SDK 2.0:
https://aws.amazon.com/blogs/developer/aws-sdk-for-java-2-0-developer-preview/
The main advantage over the AWS Java SDK is the Spring style convenience and head start we get by using the Spring project. As per the project documentation (https://cloud.spring.io/spring-cloud-aws/reference/html/##using-amazon-web-services)
Using the SDK, application developers still have to integrate the SDK
into their application with a considerable amount of infrastructure
related code. Spring Cloud AWS provides application developers already
integrated Spring-based modules to consume services and avoid
infrastructure related code as much as possible.
Simple explanation of my current infrastructure: I am using AWS Lambdas (running python code there), which are deployed via the Gitlab CI using serverless framework.
Explanation of situation: I currently have an AWS Lambda which uses a specific library version (for now say version 1.x.x). At some point in time, this Lambda will start using a new version of the this library (say 2.x.x), but I want both of these lambdas to be still deployed and available to handle requests.
If at some other point in time the version 3.x.x of the library comes, I want to keep the lambda using version 3.x.x and 2.x.x running (basically the current version and current version - 1 lambdas). Lets call them Lambda_NEW and Lambda_OLD.
AWS lambdas have the concepts of versions and aliases which could be used, but unfortunately they are not supported by serverless directly.
Note: serverless supports multiple versions (which cannot be named) and there is a plugin called serverless-aws-aliases which can set aliases for you, but that one refer to the actual AWS Lambda versions (see https://github.com/serverless-heaven/serverless-aws-alias/issues/148).
Do you have any idea on how to tackle it?
My only valid thought so far is to keep two branches (NEW and OLD) which will use two different versions of the library, and each branch will have its different deploy CI. This is very counter intuitive though, since I don't know how to maintain develop and master branches. Also, when to deploy to which stage etc.
Also I somehow want both Lambda_NEW and Lambda_OLD to be deployed on the same time (e.g. when switching to library 5.x.x, I want version 5.x.x to be in the NEW and version 4.x.x in the old)
I'm not sure from your post, but I gather that you want a way to handle canary deployments, so that you could easily roll back changes? If that's not the case, could you edit your question and provide a bit more clarity?
If that's the case, I'd recommend following this guide and using the canary-deployments plugin, which will automatically create aliases for new versions, and allows you to define how traffic is shifted between deployed versions.
I have a question about the lambda functions versioning capabilities.
I know how the standard way of versioning works out of the box in AWS but I thought there is a way for the publisher to specify the version number which would tag a specific snapshot of the function. More exactly what I was thinking of was including in the uploaded zip file a config.json where the version would be specified. And this would be used afterwards by AWS for tagging.
The reason I am asking is because I would like, for example, to keep in sync the version of the lambda function with the CI job build number that built (zipped) the lambda.
Any ideas?
Many thanks
A good option would be store your CI job build number as an environment variable on the Lambda function.
Its not exactly a recommended way to version AWS Lambda functions, but definitely helps in sticking to typical 1.x.x. versioning strategies and keeping them consistent across the pipeline.
Flipping the topic the other way around. Can we go with AWS Lambda versions 1.2.3., and then find a way to have our CI builds also use a single digit version no? Im not yet comfortable with this approach, and like the flexibility of 1.x.x as a versioning scheme to indicate major.minor.patch.
Standard Lambda versioning.
This is the most detailed blog I came across on this topic.
https://www.concurrencylabs.com/blog/configure-your-lambda-function-like-a-champ-sail-smoothly/
When you are deploying the Lambda function through CLI command or API, its not possible to give a custom version number. Its currently an automatically generated value by aws.
This makes it not possible to map the version number in a configuration file to the Lambda version supporting your use case.
I'm quite interested in beginning some development using Amazon SQS, perhaps SimpleDB too, my question is this, are there any open source solutions that mimic the functionality, just for the purposes of development. I've already encountered the Eucalyptus project (http://open.eucalyptus.com) for creating an EC-esque cloud.
I've not had any success with google, I suspect it's because the cost of entry is so inexpensive, but still, does anyone know of anything like this?
For SQS I wrote ElasticMQ, which you can run either embedded (it's written in Scala, so runs on the JVM) or stand-alone. It has both persistent and in-memory modes, the first being good for dev, second for testing.
If you need a test double for more than just SQS, you can try LocalStack.
To simulate SQS, it internally uses ElasticMQ mentioned by adamw.
You can start LocalStack via Docker, for example, and it will start the following services:
API Gateway at http://localhost:4567
Kinesis at http://localhost:4568
DynamoDB at http://localhost:4569
DynamoDB Streams at http://localhost:4570
Elasticsearch at http://localhost:4571
S3 at http://localhost:4572
Firehose at http://localhost:4573
Lambda at http://localhost:4574
SNS at http://localhost:4575
SQS at http://localhost:4576
Redshift at http://localhost:4577
ES (Elasticsearch Service) at http://localhost:4578
SES at http://localhost:4579
Route53 at http://localhost:4580
CloudFormation at http://localhost:4581
CloudWatch at http://localhost:4582
SSM at http://localhost:4583
Some of the Amazon SDKs have "mock" mode, which is:
The mock service is an alternate way
to use the sample code. The service
doesn't call AWS, but instead returns
a set response that you can modify to
suit your needs (the XML response
files are in the Mock directory). The
mock service makes it easy for you to
test how your application handles
different responses.
For SQS, it appears the Perl and PHP SDKs have mock mode. I know that the .NET SDK for Amazon RDS also has the mock mode.
The Java SDK doesn't contain mock implementations:
The client mock implementations have been removed. Instead, developers
are encouraged to use more flexible and full featured mock libraries,
such as EasyMock, jMock
If the SDK you will be using doesn't have the mock mode available, you could probably create your own similar type of thing which returns the preconfigured responses instead of actually hitting up the service.
See here for more info
GoAws - https://github.com/p4tin/goaws - was just released as beta. (disclaimer - I am the developer).
Regarding the Java SDK, it does no longer contain mock implementations:
The client mock implementations have been removed. Instead, developers
are encouraged to use more flexible and full featured mock libraries,
such as EasyMock, jMock
If you are in .NET or Mono you can try Stratosphere. It has local implementations that mimic SimpleDB, SQS and S3. For SimpleDB mock implementation it uses SQLite, for SQS and S3 it stores messages/objects in file system.
if you need to simulate SNS as well as SQS you can check out: Yopa