Amazon Web Services (or AWS) is nowadays one of the most common choices of the infrastructure and hardware providers to use and deploy to. Many Spring applications have tackled challenges of integrating the application infrastructure and the underlying layer. These in-house solutions differ in complexity and the degree of sophistication when it comes to the design and the actual functionality. One of the key attributes of success of such a solution besides the proficiency of the team is the overall knowledge and experience with AWS Java SDK. Based on the way Spring Framework has been designed and maintained, it was only a matter of time before Spring introduced a module dedicated to bridging the gap between AWS and the way we configure our Spring applications. I want to discuss some aspects of adoption of this relatively new module in this post and also point out what to look forward to and what to watch out for.

What is Spring Cloud AWS?

Let’s start from the top. Spring Cloud AWS, as apparent from the title, is a part of the Spring Cloud umbrella project. This project focuses on making life easier for Spring application developers deploying to or focusing on cloud. Spring Cloud AWS is relatively young project which started in February 2011 and achieved its first stable release in early March 2015. As of writing of this post version 1.0.3 is available and contains several useful features that are worth checking out. So which AWS products are supported and in what way?

• Amazon ElastiCache
  • Spring Cache API implementation
• Amazon Simple Notification Service
  • Metadata-driven mapping of endpoints via http
• Amazon Simple Queue Service
  • Spring Messaging API implementation
• Amazon Relational Database Service
  • Automatic creation of JDBC DataSources
• Amazon Simple Storage Service
  • Resources accessible using ResourceLoader
• AWS CloudFormation
  • Stack resources accessible by their logical name

Reasons to use Spring Cloud AWS

Obviously, this module is not trying to solve problems that have been solved by AWS SDK. What it tries to do is it tries to set a standard way of configuring Spring applications and offers implementations of standard Spring APIs to be used with and leverage the power of AWS services. From my point of view there are several reasons to consider the use of this module:

• Simplified application configuration
  • By providing simple guidelines and one XML namespace (or package for annotation-driven configuration) it is easy to group your configuration in one place following single philosophy. With reasonable defaults and behavior that is in line with what one would expect from Spring framework, developers have everything they need to create simple and consistent configuration without pollution of business classes which is often the case when AWS SDK is used without any agreement on how to use it.
• Simplified access to S3 resources
  • This must be my most favorite feature so far. Thanks to the integration of S3 with ResourceLoader, one can simply inject this component and ask it to retrieve an instance of Resource representing any given file from S3. From there on it is just business as usual given their role has access to this resource. Developers can easily check whether resource with given URI exists (for example s3://my-bucket/pics/picture.jpg), is accessible, download or manipulate it. One can even externalize log4j configuration and/or application properties to S3 (and out of the war/jar file).
• Support for authentication chain
  • Since the way the user is authenticated varies depending on the environment where the application is deployed, it is really useful to have a way to configure the authentication chain in a way you like it to behave. This is as simple as nesting a few XML elements or dropping a few annotations on the top of your configuration bean.
• Instance and environment metadata
  • Another nice feature for developers is the ability to inject instance and environment variables directly to your Spring components. This is done by using the standard injection mechanisms and property placeholder expressions. This way the AWS-related properties are treated same way as any other bits of configuration are keeping the whole thing nice and consistent.
• Great potential for future versions
  • Since I have not used any of the features like caching, SNS, RDBMS or queues I cannot comment on those. However, it is apparent just by looking at what is available that there is still plenty of space left for improvements, addition of support for other AWS services and simplifications in integration of these components with our applications. This leaves me optimistic about the upcoming versions and eager to find out what services will be included.

These things might sound great but keep in mind that the module is fairly young and if you or your team don’t feel comfortable migrating the code to make use of this module quite yet, it might be better to just wait and see where this project goes in next few months. One of the annoyances I have noticed almost immediately is the lack of proxy configuration options. So if you are sitting behind a corporate proxy server you might need to implement a slight workaround to pass the configuration to all the right places.

Conclusion

These were just a few of the features you can benefit from should you decide to include Spring Cloud AWS module in your application. I have to say I am really excited about the future of this module and feel it brought a lot of benefits even with some drawbacks like the proxy configuration to the product I work on as well as my team. One can expect things to get better and better as the time goes on. This post is the first in micro-series of posts showing the benefits of using Spring Cloud AWS I found integrating it into the product I am currently developing. In the next post called Spring Cloud AWS with proxy settings, I will focus on the overcoming of the aforementioned proxy configuration issue. Stay tuned 🙂