Tag: Modularization


Announcing the Modularized AWS SDK for Ruby (Version 3)

by Alex Wood | on | in Ruby | Permalink | Comments |  Share

We’re excited to announce today’s stable release of version 3 of the AWS SDK for Ruby. The SDK is now available with over 100 service-specific gems (starting with aws-sdk-*, such as aws-sdk-s3) on RubyGems. You can find a full list of available service gems can be found at our GitHub landing page.

Features

Version 3 of the AWS SDK for Ruby modularizes the monolithic SDK into service-specific gems, for example, aws-sdk-s3 and aws-sdk-dynamodb. Now each service gem uses strict semantic versioning, along with the benefits of continuous delivery of AWS API updates. With modularization, you can pick and choose which service gems your application or library requires, and update service gems independently of each other.

These new service-specific gems use statically generated code, rather than runtime-generated clients and types. This provides human-readable stack traces and code for API clients. Additionally, version 3 eliminates many thread safety issues by removing Ruby autoload statements. When you require a service gem, such as aws-sdk-ec2, all of the code is loaded upfront, avoiding sync issues with autoload.

Furthermore, the SDK provides AWS Signature Version 4 signing functionality as a separate gem aws-sigv4. This gem provides flexible signing usage for both AWS requests and customized scenarios.

Upgrading

We’ve provided a detailed upgrading guide with this release, which covers different upgrade scenarios. In short, the public-facing APIs are compatible, and so changes you need to make are focused on your Gemfile and require statements.

Most users of the SDK have a setup similar to this:

# Gemfile
gem 'aws-sdk', '~> 2'
# Code Files
require 'aws-sdk'

s3 = Aws::S3::Client.new

ddb = Aws::DynamoDB::Client.new

# etc.

If that’s you, the quickest migration path is to simply change your Gemfile like so:

# Gemfile
gem 'aws-sdk', '~> 3'

However, this will pull in many new dependencies, as each service client has its own individual gem. As a direct user, you can also change to using only the service gems actually required by your project, which is the recommended path. This would involve a change to both your Gemfile and to the code files where your require statements live, like so:

# Gemfile
gem 'aws-sdk-s3', '~> 1'
gem 'aws-sdk-dynamodb', '~> 1'
# Code Files
require 'aws-sdk-s3'
require 'aws-sdk-dynamodb'

s3 = Aws::S3::Client.new
ddb = Aws::DynamoDB::Client.new

# etc.

Other upgrade cases are covered in the guide.

Feedback

Please share your questions, comments, issues, etc. with us on GitHub. You can also catch us in our Gitter channel.

Modularization Released to NuGet in Preview

by Norm Johanson | on | in .NET | Permalink | Comments |  Share

Today, we pushed our new modularized version of the AWS SDK for .NET to NuGet in preview. This means there are separate NuGet packages for each AWS service. For example, if your application uses Amazon S3 and Amazon DynamoDB, then instead of including the existing AWSSDK package that includes all the AWS services, you can add the AWSSDK.S3 and AWSSDK.DynamoDB packages. This allows your application to include much smaller assemblies, and you’ll need to update these packages only when the services you use are updated.

Why Preview?

The modularized version of the SDK is production ready, so we encourage developers to start using the modularized version now. We marked the modularized SDK as a preview while we are tweaking our release process and documentation. When adding preview packages, be sure to select Include Prerelease.

Check our previous blog post to learn about the differences. You can also follow our development on the modularization branch in GitHub.

NuGet Packages

Service Name NuGet Package
Auto Scaling AWSSDK.AutoScaling
AWS Support API AWSSDK.AWSSupport
AWS CloudFormation AWSSDK.CloudFormation
Amazon CloudFront AWSSDK.CloudFront
AWS CloudHSM AWSSDK.CloudHSM
Amazon CloudSearch AWSSDK.CloudSearch
Amazon CloudSearch Domain AWSSDK.CloudSearchDomain
AWS CloudTrail AWSSDK.CloudTrail
Amazon CloudWatch AWSSDK.CloudWatch
Amazon CloudWatch Logs AWSSDK.CloudWatchLogs
AWS CodeDeploy AWSSDK.CodeDeploy
Amazon Cognito Identity AWSSDK.CognitoIdentity
Amazon Cognito Sync AWSSDK.CognitoSync
AWS Config AWSSDK.ConfigService
AWS Data Pipeline AWSSDK.DataPipeline
AWS Direct Connect AWSSDK.DirectConnect
Amazon DynamoDB (v2) AWSSDK.DynamoDBv2
Amazon Elastic Compute Cloud (EC2) AWSSDK.EC2
Amazon EC2 Container Service AWSSDK.ECS
Amazon ElastiCache AWSSDK.ElastiCache
AWS Elastic Beanstalk AWSSDK.ElasticBeanstalk
Elastic Load Balancing AWSSDK.ElasticLoadBalancing
Amazon Elastic MapReduce AWSSDK.ElasticMapReduce
Amazon Elastic Transcoder AWSSDK.ElasticTranscoder
Amazon Glacier AWSSDK.Glacier
AWS Identity and Access Management (IAM) AWSSDK.IdentityManagement
AWS Import/Export AWSSDK.ImportExport
AWS Key Management Service AWSSDK.KeyManagementService
Amazon Kinesis AWSSDK.Kinesis
AWS Lambda AWSSDK.Lambda
Amazon Machine Learning AWSSDK.MachineLearning
AWS OpsWorks AWSSDK.OpsWorks
Amazon Relational Database Service (RDS) AWSSDK.RDS
Amazon Redshift AWSSDK.Redshift
Amazon Route 53 AWSSDK.Route53
Amazon Route 53 Domains AWSSDK.Route53Domains
Amazon Simple Storage Service (S3) AWSSDK.S3
AWS Security Token Service (STS) AWSSDK.SecurityToken
Amazon SimpleDB AWSSDK.SimpleDB
Amazon Simple Email Service (SES) AWSSDK.SimpleEmail
Amazon Simple Notification Service (SNS) AWSSDK.SimpleNotificationService
Amazon EC2 Simple Systems Manager (SSM) AWSSDK.SimpleSystemsManagement
Amazon Simple Workflow Service AWSSDK.SimpleWorkflow
Amazon Simple Queue Service (SQS) AWSSDK.SQS
AWS Storage Gateway AWSSDK.StorageGateway
Amazon WorkSpaces AWSSDK.WorkSpaces

 

Update on Modularization of the SDK

by Norm Johanson | on | in .NET | Permalink | Comments |  Share

As mentioned earlier, we are currently working on modularizing the AWS SDK for .NET into individual packages for each service. We have pushed the changes to the modularization branch in GitHub. If you use the solution file AWSSDK.sln, it will produce a core assembly for each supported platform and individual service assemblies for each supported platform. Since this solution builds Windows Store and Windows Phone versions of the SDK for .NET, we recommend that you use Windows 8.1 as your platform. We still have more testing, clean up, and work to do on our build/release process before we release modularization for general availability.

Breaking changes

We have tried to keep the list of breaking changes to a minimum to make it as easy as possible to adopt to the new modularized SDK. Here are the breaking changes in the SDK.

Amazon.AWSClientFactory Removed

This class was removed because in the modularized SDK it didn’t make sense to have a class that had a dependency to every service. Instead, the preferred way to construct a service client is to just use its constructor.

Amazon.Runtime.AssumeRoleAWSCredentials Removed

This class was removed because it was in a core namespace but had a dependency to the AWS Security Token Service. It has been obsolete in the SDK for quite some time and will be removed with the new structure. Use Amazon.SecurityToken.AssumeRoleAWSCredentials instead.

SetACL from S3Link

S3Link is part of the Amazon DynamoDB package and is used for storing objects in Amazon S3 that are references in a DynamoDB item. This is a useful feature, but we didn’t want to cause a compile dependency on the S3 package for DynamoDB. Consequently, we needed to simplify the exposed S3 methods from S3Link, so we replaced SetACL with MakeS3ObjectPublic. For more control over the ACL on the object, you’ll need to use the S3 package directly.

Removal of Obsolete Result Classes

For most all services in the SDK, operations return a response object that contains metadata for the operation such as the request ID and a result object. We found having a separate response and result class was redundant and mostly just caused extra typing for developers. About a year and half ago when version 2 of the SDK was released, we put all the information that was on the result class on to the response class. We also marked the result classes obsolete to discourage their use. In the new modularized SDK currently in development, we removed these obsolete result classes. This helps us reduce the size of the SDK.

AWS Config Section Changes

It is possible to do advanced configuration of the SDK through the app.config or web.config file. This is done through an aws config section like the following that references the SDK assembly name.

<configuration>
  <configSections>
    <section name="aws" type="Amazon.AWSSection, AWSSDK"/>
  </configSections>
  <aws region="us-west-2">
    <logging logTo="Log4Net"/>  
  </aws>
</configuration>

In the modularized SDK, there is no longer an assembly called AWSSDK. Instead, we need to reference the new core assembly like this.

<configuration>
  <configSections>
    <section name="aws" type="Amazon.AWSSection, AWSSDK.Core"/>
  </configSections>
  <aws region="us-west-2">
    <logging logTo="Log4Net"/>  
  </aws>
</configuration>

You can also manipulate the config settings through an Amazon.AWSConfigs object. In the modularized SDK, we moved config settings for DynamoDB from the Amazon.AWSConfigs object to Amazon.AWSConfigsDynamoDB.

What’s next

We are making good progress getting our process and development switched over to the new modularized approach. We still have a bit to go, but in the meantime, we would love to hear any feedback on our upcoming changes. Until we’ve completed our switchover, you can still use the current version of the SDK to make all the changes except for the configuration. This means you can make those updates now to ready your code for the modularized SDK.