byterock

Well I think it is time I get back to blogging as the one month hiatus I originally planned has now stretched out to I think 10 or 11 months with only two little posts on the SPW back in August..

One of the positive notes from that rather depressing (at least from a Perl perspective) meet-up was the feed back I received on my one year's worth of blogging.

A few points that where raised are;

• I should try and do more community oriented posts rather than post from my own little development bubble.


• Go more for quality vs quantity.


• Try something new not something that has already been blogged to death.

So I am going to try and take these suggestion to heart starting with trying to give back the the community and as hacktoberfest is now running I think I will go for a t-shirt as well.

As the title of today’s Post says I will be looking at Paws (Perl AWS) not how it works per-say but how I can help out with it.

Now a few words about Paws.

It is the perl version for the AWS-SDK. The brain child of Jose Luis Martinez Torres, for more detailed notes on what, why where and when check out his slides from the 2015 YAPC::EU. I am just going to give you the 25 cent tour.

Paws takes a 'data-driven' approach to development, meaning it generates its classes from a data structure. The structure, botocore, is in JSON format and it is used as the foundation for the CLI (command line interface) for AWS as well as a number of similar SDKs. Paws uses good old Template Toolkit to generate its class from the botocore data files.

Why did the devs of Paws take this approach? Well one word on that 'BIG'. While not as mind-bogglingly big as space it is a very much longer than a trip down the road than to the local chemist. (sorry Douglas). Here are some stats

• 50+ services


• 1600+ actions


• 3700+ input/output classes,


• perhaps 120K+ attributes and


• still growing

So that mystery is solved.

That covers the how it is produced but what about the why create it in the first place? For JLMARTIN they had a business case for it and in a single line it creates a consistent single interface to AWS rather then a miss-mash of modules and interfaces.

I can testify to at least one problem that comes from the myriad of AWS modules that are out there. In one project I am working on we had 6 different AWS modules 2 of them doing the same job.

To give an exact example of how an inconstant interface caught me we swapped over from using Amazon::SQS::Producer and Amazon::SNS modules to using just Amazon::SNS to send out SMSs. We made the code changes and then moved it to production where it worked fine, at least for a little while.

Once established in prod and the customer started to use and depend on the SMSs. The message volume increased and soon messages started to be dropped and even blocked by some service providers.

Well the phone started ringing with the customer worried that then new system they now depend on was no longer working correctly.

After great gnashing of teeth and pulling of hair and a few frantic calls to AWS support I found out our SMSs where being routed though 'eu-west' and we where either being blocked because the origin phone was from the EU or due to latency issues some SMS where dropped or deviled very late.

Checking under the hood of Amazon::SNS I found;

sub dispatch {

    my ($self, $args) = @_;

 

    $self->error(undef);

 

    $self->service('http://sns.eu-west-1.amazonaws.com')

        unless defined $self->service;

It was mentioned way at the bottom of the POD but it was easily overlooked by me. The fix was simple enough, just set my default service to 'us-east-1', but the trouble it caused both in time and customer aggravation almost made us select another much more expensive SMS service.

I can go on with a few other issues I have stumbled upon but the point was clear to me. I need a one interface to all of AWS and I guess Paws is it.

So how to get started?

Will it is easy enough just follow the 'getting' started blurb on the git hub page and you should be off to the races.

The only little local config change I did, that saves me a good deal of time, was to remove Paws.pm and the Paws dir from my local perl and set up a symlink for each that links back to my local version.

Another little trick was to be very focused on which classes I was compiling and only compile the one I was working on, but more on that latter.

So far I have fixed one issue with Paws and will soon be working on another and I must say it is a good place to play in. Their preferred method of getting a patch in place is to do a pull request from master and tag and then check you changes in once they are done.

Anyway should have lots of fun with this one over the next little while and maybe even get a T-Shirt.