Not even standing room only at the London AWS Summit

As the leading enterprise AWS Partner in the UK  ;o)  Smart421 had a big presence at the London AWS Summit last week (23 April).

Several of our customers also attended and one of them, Steve Howes, Chief Executive of Rail Settlement Plan part of Association of Train Operating Companies – ATOC) presented as part of the 2nd keynote, and very kindly mentioned us.

In fact, we were referenced thoughout the day, sometimes in unexpected ways. For example, within the opening five minutes of the first keynote, Smart421 was name-checked by Werner Vogels, CTO at Amazon.

Steve Howes of RSP takes to the stage in front of 1,200 delegates

As per the recent Las Vegas event, it was a bit rock’n'roll in the keynotes, with music by Foo Fighters playing over the PA whilst we were waiting for the queuing hordes to make their way through the registration bottleneck and into the venue.  Vogels himself appeared on stage to the sound of Nirvana pumping out of the speakers.

What struck me was the size that this event had become, a significant increase on the 2012 AWS Summit.

In the afternoon, the event split into separate streams. I stuck to the more involved sessions that were digging into the specifics of particular service releases such as Amazon Redshift and Amazon DynamoDB.

As you can see from the photo above, there was barely sitting room only in some of these techy sessions, let alone standing room.

It made me think – would conference attendees be prepared to sit on the floor for any vendor, especially in the corner of a crowded room? There must be few other vendors, if any, that have that kind of pulling power right now.

These are exciting times. Opportunities for enterprises to benefit are enormous.

And this event confirmed my reflections that we’re reaching a tipping point in the market; adoption by the “early majority” in the technology adoption lifecycle is really visible and is happening – albeit with different market sectors arriving at very different stages.

Our conversations continued all day long over at the Smart421 stand, where we showcased three of our customer engagements:
Disaster Recovery on the AWS Cloud for Haven Power,
Big Data Analytics on the AWS Cloud for Aviva / Quotemehappy.com,
and Service Transition to the AWS Cloud for ATOC.

Frankly, we wanted to showcase even more but there just wasn’t the space.

Please Rate and Like this blog.  If you can, please leave a Comment.

 

Third Generation Outsourcing – SIAM

It was great to see National Rail Enquiries (NRE) win an award at the European Outsourcing Association Awards in Amsterdam last Friday (26 April).

In recognition of their SIAM outsourcing strategy (Service Integration and Management), NRE won the award for Best Multi-sourcing Project of the Year , beating strong category finalists 60k and Centrica (Centrica won this category in 2012).

Smart421 is pleased to be a large part of that initiative, performing the Managed Services element on top of an AWS Cloud platform for several key NRE applications.

As customers struggle with the chains of traditional SI relationships, Smart421 is providing agile delivery and innovation methods in the IaaS world.

Many analysts see this as “third generation outsourcing” and a change for good – and so do I.

 

Please rate and Like this blog.  If you can, please leave a Comment.

 

Adventures in AWS EC2 spot land

I was doing some Hadoop demo work last week for a customer and mainly just because I could, I used spot instances to host my Hadoop/pig cluster using AWS’s Elastic MapReduce (EMR) offering.  I thought I’d have a quick look at what the resulting costs were over the few hours I was using it.  I used a combination of small and large instances in the US-East region – m1.small for the master node and m1.large for the core nodes.  Note – these costs exclude the PaaS-cost uplift for using EMR (another 6 cents per hour for a large instance).

In summary – it’s dirt cheap….

What is more revealing is to look at this in terms of the % of the on-demand price that this represents…

So in summary, around an average saving of 90% on the on-demand price!  This is probably influenced by the fact that I was running the cluster mainly during the time when the US are offline.  We tend to get a bit fixated on the headline EC2 cost reductions that have frequently occurred over the last few years, and the general “race to the bottom” of on-demand instance pricing between AWS, Google, Microsoft etc.  Obviously not all workloads are suitable for spot pricing, but what I did here was deliberately bid high (at the on-demand price for each instance type in fact) knowing that this would mean that I was very unlikely to get booted off the instances as anyone bid higher if capacity got short.  As EC2 instance costs are so low anyway, we tend to not worry too much about optimising costs by using spot pricing for many non-business critical uses – which is a bit lazy really and we could all exploit this more.  Let’s do that!

 

AWS CloudFormation (and Chef) on Centos

If you have any experience of supporting large scale infrastructures, whether they are based on ‘old school’ tin and wires, virtual machines or cloud based technologies you will know that it is important to be able to create consistently repeatable platform builds. This includes ensuring that the network infrastructure, ‘server hardware’, operating systems and applications are installed and configured the same way each time.

Historically this would have been achieved via the use the same hardware, scripted operating system installs and in the Windows application world of my past the use of application packagers and installers such as Microsoft Systems Management Server.

With the advent of cloud computing the requirements for consistency are still present and just as relevant. However the methods and tools used to create cloud infrastructures are now much more akin to application code than the shell script / batch job methods of the past (although some of those skills are still needed). The skills needed to support this are really a mix of both development and sys-ops and have led to the creation of Dev-Ops as a role in its own right.

Recently along with one of my colleagues I was asked to carry out some work to create a new AWS based environment for one of our customers. The requirements for the environment were that it needed to be:

• Consistent
• Repeatable and quick to provision
• Scalable (the same base architecture needed to be used for development, test and production just with differing numbers of server instances)
• Running Centos 6.3
• Running Fuse ESB and MySQL

To create the environment we decided to use a combination of AWS CloudFormation to provision the infrastructure and Opscode Chef to carry out the installation of application software, I focussed primarily on the CloudFormation templates while my colleague pulled together the required Chef recipes.

Fortunately we had recently had a CloudFormation training day delivered by our AWS Partner Solutions Architect so I wasn’t entering the creation of the scripts cold, as at first the JSON syntax and number of things you can do with CloudFormation can be a little daunting.

To help with script creation and understanding I would recommend the following:

• A decent text editor with JSON support – I use Notepad++ combined with the JSON Viewer Plug-In
• A copy of the AWS CloudFormation documentation
• Have a look at the AWS sample templates
• Document the template requirements (i.e. what is it the infrastructure that template needs to create)

For the environment we were creating the infrastructure requirements were:

• VPC based
• 5 subnets
  • Public Web – To hold web server instances
  • Public Secure – To hold bastion instances for admin access
  • Public Access – To hold any NAT instances needed for private subnets
  • Private App – To hold application instances
  • Private Data – To hold database instances
  • ELB
    • External – Web server balancing
    • Internal – Application server balancing
    • Security
      • Port restrictions between all subnets (i.e. public secure can only see SSH on app servers)

To provision this I decided that rather than one large CloudFormation template I would split the environment into a number of smaller templates:

• VPC Template – This created the VPC, Subnets, NAT and Bastion instances
• Security Template – This created the Security Groups between the subnets
• Instance Templates – These created the required instance types and numbers in each subnet

This then allowed us to swap out different Instance Templates depending on the environment we were creating for (i.e development could have single instances in each subnet whereas Test could have ELB balanced pairs or production could use features such as auto-scaling).

I won’t go into the details of the VPC and Security Templates here, suffice it to say that with the multiple template approach the outputs from the creation of one stack were used as the inputs to the next.

For the Instance Templates the requirement was that the instances would be running Centos 6.3 and that we would use Chef to deploy the required application components onto them. When I started looking in to how we would set the instances up do this I found that the examples available for Centos and CloudFormation were extremely limited compared to Ubuntu or Windows. As this is the case I would recommend working from a combination of the Opscode guide to installing Chef on Centos and AWS’s documentation on Integrating AWS with Opscode Chef.

Along the way to producing the finished script there were a number of lessons which I will share with you to help with your installation, the first of these was the need to use a Centos.org AMI from the AWS Marketplace. After identifying the required AMI I tried running up a test template to see what happens before signing up for it in the Marketplace, in CloudFormation this failed with an error of ‘AccessDenied. User doesn’t have permission to call ec2::RunInstances’ which was slightly misleading. Once I’d signed our account up for the AMI then this was cured.

The next problem I encountered was really one of my own making / understanding. When looking at AMIs to use I made sure that we had picked one that was Cloud-Init enabled, in my simplistic view I thought that this meant that commands such as cfn-init that are used within CloudFormation to carry out CloudFormation specific tasks would already be present. This wasn’t the case as the cfn- commands are part of a separate bootstrap installer that needs to be included in the UserData Section of the template (see below):

"UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [
 "#!/bin/bash -v\n",
 "function error_exit\n",
 "{\n",
 " cfn-signal -e 1 -r \"$1\" '", { "Ref" : "ResFuseClientWaitHandle" }, "'\n",
 " exit 1\n",
 "}\n",<br /> "# Install the CloudFormation tools and call init\n",
 "# Note do not remove this bit\n",<br /> "easy_install https://s3.amazonaws.com/cloudformation-examples/aws-cfn-bootstrap-latest.tar.gz\n",
 "cfn-init --region ", { "Ref" : "AWS::Region" },
 " -s ", { "Ref" : "AWS::StackName" }, " -r ResInstanceFuse ",
 " --access-key ", { "Ref" : "ResAccessKey" },
 " --secret-key ", { "Fn::GetAtt" : [ "ResAccessKey", "SecretAccessKey" ]},
 " -c set1",
 " || error_exit 'Failed to run cfn-init'\n",
 "# End of CloudFormation Install and init\n", 
 "# Make the Chef log folder\n",
 "mkdir /etc/chef/logs\n",
 "# Try starting the Chef client\n",
 "chef-client -j /etc/chef/roles.json --logfile /etc/chef/logs/chef.log &gt; /tmp/initialize_chef_client.log 2&gt;&amp;1 || error_exit 'Failed to initialise chef client' \n",
 "# Signal success\n",
 "cfn-signal -e $? -r 'Fuse Server configuration' '", { "Ref" : "ResFuseClientWaitHandle" }, "'\n"
]]}}

As the cfn-signal which comes as part of the bootstrap installer is used for messaging to any wait handlers defined in the template this can lead to long breaks at the coffee machine before any feedback is received if they are not present.

The final lesson was how to deploy the Chef Client and configuration to the instances. Chef is a rubygems package, so needs this and supporting packages present on the instance before it can be installed. Within CloudFormation packages can be installed via the use of the packages configuration sections of AWS::CloudFormation::Init which for Linux supports rpm, yum and rubygems installers. Unfortunately for the AMI we chose to use the available repositories didn’t contain all packages necessary for our build, to get around this I had to rpm on the rbel repository definitions before using a combination of yum and rubygems to install Chef:

"packages" : {
 "rpm" : {
 "rbel" : "http://rbel.frameos.org/rbel6"
 },
 "yum" : {
 "ruby" : [],
 "ruby-devel" : [],
 "ruby-ri" : [],
 "ruby-rdoc" : [],
 "gcc" : [],
 "gcc-c++" : [],
 "automake" : [],
 "autoconf" : [],
 "make" : [],
 "curl" : [],
 "dmidecode" : [],
 "rubygems" : []
 },
 "rubygems" : {
 "chef" : [] 
 }
}

Once Chef was installed the next job was to create the Chef configuration files and validation key on the instance. This was carried out using the “files” options within AWS::CloudFormation::Init:

"files" : {
 "/etc/chef/client.rb" : 
 "content" : { "Fn::Join" : ["", [
 "log_level :info", "\n", "log_location STDOUT", "\n",
 "chef_server_url '", { "Ref" : "ParChefServerUrl" }, "'", "\n",
 "validation_key \"/etc/chef/chef-validator.pem\n",
 "validation_client_name '", { "Ref" : "ParChefValidatorName" }, "'", "\n"
 ]]}, 
 "mode" : "000644",
 "owner" : "root",
 "group" : "root"
 },
 "/etc/chef/roles.json" : {
 "content" : { 
 "run_list" : [ "role[esb]" ]
 },
 "mode" : "000644",
 "owner" : "root",
 "group" : "root"
 },
 "/etc/chef/chef-validator.pem" : {
 "source" : { "Fn::Join" : ["", [{ "Ref" : "ParChefKeyBucket" }, { "Ref" : "ParChefValidatorName" }, ".pem"]]},
 "mode" : "000644",
 "owner" : "root",
 "group" : "root",
 "authentication" : "S3Access"
 }
}

The hardest part of this was the validation key, as we had multiple instances wanting to use the same key we decided to place this within an S3 bucket and pull the key down. During the script creation I tried multiple ways of doing this, such as using S3Cmd (which needed another repository and set of configuration to run) but found that using the files section worked best.

Once Chef was installed the client was started via the UserData section (basically a shell script), this then handed control of what additional software and configuration is installed on the instance to the Chef Master. How much Chef does at this stage is a bit of a balancing act as the wait handler within the template will fail the stack creation if its timeout period is exceeded.

As you can probably tell if you have got this far, the creation of the templates took quite a few iterations to get right as I learnt more about CloudFormation. When debugging what is going on it is worth remembering that you should always set the stack to not rollback on failure. This then allows you to access the instances created to find out where they got to within the install, as the UserData section is basically a shell script with some CloudFormation hooks, more times than not the faults are likely to be the same as you would see on a standard non-AWS Linux install. Also for a Centos install remember that the contents of /var/log are your friend as both cloud-init and cfn-init create log files here for debugging purposes.

After watching Werner Vogels keynote speech from AWS Re:Invent it’s clear that treating infrastructure as a programmable resource (i.e. using technologies such as CloudFormation and Chef) is somewhere organisations need to be moving towards and based on my experience so far I will be recommending using this approach on all future AWS environments we get involved with, even the small ones.

Whilst there is a bit of a learning curve the benefits of repeatable builds, known configuration and the ability to source control infrastructure far outweigh any shortcomings, such as granular template validation which I’m sure will come with time.

If you have any comments or want to know more please get in touch.

 

AWS EC2 costs in South America

AWS have been busy launching new regions around the world at an amazing rate recently – Sydney, Sao Paulo etc – and there’s still gossip of a second European region to come. It’s fair to say that Smart421′s business in South America is still in its growth phase , so I hadn’t paid a huge amount of attention to the instance costs for the South America region. As you’d expect Smart421 tend to use EU-West and US-East for all our customer and internal AWS work. I happened to be checking out the costs today for Elastic MapReduce (EMR – AWS’s Hadoop-as-a-service offering) and had a quick snout around to compare EMR costs across regions, so I stumbled across the Sao Paulo EC2 pricing.

In short – it’s significantly more than all the other regions. A standard on-demand large instance is $0.26/hr in US-East but a whopping $0.46/hr in Sao Paulo – that’s 77% more. Now I’m used to regional price variations as power, tax etc are different in different territories (when will the EU-West region drop to match US-East prices eh?), but that’s a lot. That creates a pretty significant incentive to still use the US services, latency and other similar considerations put to one side of course. Also, I wonder if it also broadens the opportunity for 3rd parties to offer cloud brokerage services (a market I’ve been rather skeptical about up until now due to the barriers to workload mobility) that automatically port compute workloads between regions for a percentage of any cost savings made.

Looks like cost harmonisation via the the globalisation of IT still has some way to go then. Ouch!

 

AWS Re:Invent unveils another yet another price reduction and DW-aaS

Unfortunately I didn’t manage to make a strong enough case to travel to Las Vegas in person , so I did the next best thing and watched the live media stream yesterday evening – it was just like being there, but without Tom Jones or any showgirls. The two big things from Andy Jassy (the AWS SVP) were an approx 24% storage (S3) price reduction across all regions from 1st Dec, and the launch of a limited beta version of datawarehousing-as-as-service. On the second of these, AWS Redshift (which is discussed in more detailed in Jeff Barr’s post here) is a direct challenge to the existing column-oriented database world, Teradata, IBM, Oracle etc. It looks really interesting and is a classic cloud use case and so it makes sense for AWS to tackle it – it requires large volumes of storage and compute power and is a traditionally high-CapEx market sector – I’m looking forward to playing with it..

As for the S3 price reduction…well, a 24% price reduction is a pretty amazing step change in pricing. In what other industries would have such dramatic changes in price? I wish it was happening to UK gas & electricity pricing . Having said that, Google storage costs currently start at $0.095 per GB per month, so it looks like AWS are price matching with Google. Microsoft Azure pricing was still at $0.125 per GB when I checked this morning, but presumably they will have to respond (to be precise – this is not quite an apples for apples comparison as Azure replication is over a significant distance whereas AWS S3 replication is between AZs which are separate but within some, but typically undisclosed, kilometres). As discussed before on the blog, I can’t see how the majority of smaller (and by that I still mean very big!) IaaS cloud players can possibly compete with this perfect storm of huge economies of scale and immensely deep pockets. Looking at our current AWS billing (which includes customer’s AWS accounts that we manage on their behalf), S3 storage costs only account for <5% of the total costs as the lion’s share of the cost relates to compute – so more price reductions here as well please!

[Update 30/11/12 - Since reading Jeff's post I've realised that these cost savings also apply to EBS Snapshots (der...of course you'd expect that), so this actually makes the cost saving from this one price reduction more significant, getting up to 8% or so]

 

Never mind the X factor – Cloud Computing showed it has the WOW factor at the UK IT Industry Awards

After all, there was really no need for our MD or our guests to become dispondent.

Having been named as a Finalist in the ‘Best Use of Cloud Services’ category, Smart421 may have been a tad surprised that the judges went for another Finalist at the UK IT Industry Awards.

In fact we were rather impressed with, and pleased for, The Met Office and PA Consulting who together saw off some pretty stiff competition to get the gong at the Awards Dinner in Battersea, London last Wednesday night (14 November).

And I was surprised that there actually wasn’t more gloating by the victors. You know how some marketing types can behave when tanked up on too much champers.

The UK IT Industry Awards did a great job to properly recognise the role of Cloud Computing for the first time when they selected the Weather Observations Website (WOW) which is currently available online as beta. See http://wow.metoffice.gov.uk/

And we think that this actually bodes well for the entire IT industry in the near and long term. It means that Cloud has proven that it has learned to crawl, walk and run. In other words, it means that Cloud Computing is winning its place as a resilient and credible alternative to on-premise-only lock in. And at an enterprise level, we think that must be a good thing.

As our customer Haven Power will tell you, being selected as Finalist at all was very encouraging. Their Disaster Recovery system architected by Smart421 and built in the AWS Cloud drew some significant attention from the press when it was first announced and, most likely, gave The Met Office a fair run for its money in front of the judging panel.

But putting the industry high jinks aside, the real winners are our customers who have fully functioning Cloud DR in place today as part of their business continuity planning strategy. Stuff like this is the sharp end of the Cloud revolution.

It has to be said, attendees were also impressed with our colleagues at Kcom (neighbour brand in the KCOM Group stable) who sponsored the on-site Twitter Wall. It turned out to be the unexpected big hit of the night and Kcom ranked top for tweets.

Never mind the X factor – Cloud Computing showed it has the WOW factor at the UK IT Industry Awards.

 

Cloudcamp London #17

Cloudcamp is still a great event, but it does feel like it’s running out of steam a little – the cloud hype has waned a little just as part of the natural evolution of things, and the attendance seemed marginally lower to me last night. They’ve also tackled all the big crowd-pulling themes. But I’ll still be going, just because the presentations were still really good, introducing you to topics and ideas you just wouldn’t stumble across any other way. And then there’s the sarcasm, red cards (mainly a deterrent it seems as I’ve never seen one deployed yet), beer and pizza.

In this post I’ll just point out some interesting (to me at least!) little snippets – partly so I remember them and partly to share with my Smartie colleagues.

Lock-in – Joe from VMWare made a great point about lock-in – as an architect, really you can’t avoid lock-in, even though this is the language that we tend to use. In reality what you can do is design what you want to be locked-in by and what you don’t. E.g you can implement your own private cloud using OpenStack to avoid being locked into a public cloud vendor, but then you are locked into the OpenStack community and it’s uncertain future, and the hardware you’ve bought etc. Or you can use PaaS to avoid hypervisor-layer lock-in, but they you might need to lock-in to a certain dev language etc. This resonated with me as Smart421 considered this topic on a recent client cloud consultancy engagement, and the feared lock-in was actually not as severe as maybe it was perceived. It’s all choices, no rights and wrongs, just tools in the architects toolbox.

Cloud cost examples – Ali from PlanForCloud gave some costs examples for what it might cost to run TripAdvisor or Pinterest infrastructure on AWS, e.g. $1.7m p.a. using on-demand reducing to $0.9m p.a. if reserved instances are used for TripAdvisor. What I was hoping to hear was the equivalent current on-premise (or at least non-AWS) costs, but he didn’t present those. My expectation is that these kinds of scale on-premise will still be way cheaper, but of course it’s more complex than that – capex, options to mix on-demand/spot/reserved, load distribution across AZs and regions, lower support staff costs etc. It’s a complex area.

Lack of transparency with big data – Chris Swan made an interesting point about the increasing risk of very non-transparent machine generated decisions as we move into a more big data-based world, e.g. credit card fraud detection systems that are so opaque that false positives cannot really be challenged, it’s just “what the system said”. My message to customers is that big data technologies offer an opportunity to gain new insights into their existing data assets at previously unheard of processing costs – but ironically this trend could also lead to less insight, at least from an end user perspective.

There were also some great lightning talks from Kuan Hon re cloud contract negotiations (seen her speak several times – a cloud legal eagle), Phil about why we should be scared of European cloud standardisation initiatives, and James Mitchell on the likely trend towards cloud computing capacity futures/options/derivatives trading etc. In fact – no dud talks this time at all, and you’d expect at least one

 

How green is your cloud and what can you do about it?

I went to a CloudCamp in London back in early July that was all a bit weirder than usual – quite a bit of swearing from the speakers, some very passionate lightning presentations and a generally more militant and chaotic feel to the whole event – which made it all the more enjoyable. There was a mix of the strange, the vaguely self-promotional and the fascinating, followed by beers and pizza. What’s not to like!

I arrived a little late due to “just one more email” syndrome and when I walked in Francine Bennett from MastodonC was already presenting some data on the relative carbon footprints of the various Amazon Web Services (AWS) regions. She wasn’t picking on AWS specifically – but using the market leader as a benchmark to get her point across. I’ve found a similar presentation from Francine at a previous event here.

Her presentation reminded me of the points made by Dr Chris Tuppen in a white paper published on the Smart421 web site some time ago (there’s a link to it here)…

• The data centre industry strives for the mythical PUE (Power Usage Effectiveness) of 1.0, but efficiency does not equate to being green. Being efficient in use of cooling, lighting etc is obviously a good thing, but actually the key issue is…
• The power source – the dominant factor on the carbon footprint of a data centre is its power source. Kinda obvious really, but the variability in the carbon emissions per kWh around the world is staggering – have a look at the following data…the “bad boys” are typically coal-generation based, and the “good boys” are hydro/thermal or nuclear-based. Greenland isn’t in my data set below, but that would be even better.

• So what this means is that if your data centre runs on power from France, it already has nearly 9 times lower CO2 emissions than if it were running in Ireland. So working really hard to tweak your PUE down from 1.2 to 1.1 seems kinda secondary in this context…
• Another key factor is the climate/environment your data centre is in – i.e. is it in a hot or a cold place. Hot = bad as all the cooling required just drives up emissions, and would of course be reflected in your PUE rating. So Ireland wins here as it’s not that warm, and Greenland really wins.
• Applying this to an AWS context – what this means is that you can immediately get a 43% emissions reduction by moving your AWS workload from US-East in Virginia (the cheapest region to use, but it’s hot there and the local power sources are dirtier) to the EU Region in Ireland. [Data sourced from here]. Given that moving AWS workloads between regions is pretty trivial to achieve, for scenarios where bandwidth/latency considerations are not a barrier this is an absolute no-brainer to do. This is where IaaS/cloud computing really wins out – the portability of workloads mainly due to the pricing model. Of course – all the Smart421 AWS deployments tend to be in the EU region anyway as it is the local region for our customer base
• But if you really want to get emissions down, port your IT workload to GreenQloud in Greenland who run a 100% carbon neutral data centre facility – this is only possible because they rely on carbon neutral power sources (geothermal and hydro), and helpfully it’s a bit chillier there too. The reality today though is that latency (an assumption – I must measure this at some point…) and the lack of geographically-separated data centres (i.e. the multi-AZ model in the AWS world) makes this not really fit for enterprise use in my view. They run AWS-like APIs for the basic AWS services of compute and storage but of course you don’t get the richness of the rest of the AWS platform.

So – coming back to my opening question – “How green is your cloud and what can you do about it?”. Answer – probably not very depending on where it is, so think about where it is and move it.

 

Smart421 achieves AWS Advanced Consulting Partner status

It is another exciting day for Smart421 with the news that we have been confirmed as the first UK enterprise to be confirmed on the Amazon Partner Network (APN) as an Advanced Consulting Partner by Amazon Web Services (AWS).

What does it really mean for Smart421 and our Customers?

In some ways, partner ‘labels’ are often seen as just that, labels, and can be given out like confetti. However, for Advanced Consulting Partner status, we had to put up some substantive evidence of various AWS capabilities including Customer references, minimum of $10,000 a month AWS billings, minimum of Business level AWS support (previously called Gold) and at least 10 trained AWS staff.

So before the cynics have a pop either at the program or at us, or both, I can reveal it does require proven AWS capabilities. That will sort the ‘wheat from the chaff’ so to speak

Does it change anything for us? – well yes and no…..

In terms of Operations, we already have a great relationship with AWS (since 2010 as an AWS Solution Provider and since 2012 also as an AWS Direct Connect Solution Provider) with access to a range of valuable contact points, from technical contacts through to Sales and up into Senior Management in the UK and USA. From my perspective as AWS Practice Manager, the existing relationship means regular face-to-face monthly meetings with our technical contacts in AWS, access to the product teams including ‘gurus’ based in Seattle, involvement in beta trials for new features etc. so the APN will just help reinforce those good relationships.

Perhaps the biggest change will be the impact of membership of the APN for our Customers. We are now able to be able to leverage a wealth of AWS resources on our Customers behalf. This translates into concrete deliverables as straightforward as documentation right through to support from technical architects during delivery engagements. It adds up to an improved level of confidence for our Customers that our proven AWS capabilities are fully backed by AWS and its rapidly growing global eco-system.

It means far more than a partner label to us and our Customers….