Fail: AWS EFS (Preview) on AWS EC2 Windows Instance

Gah! :( Poor show this morning.

Was hoping to write up a disk performance comparison of AWS EFS against EBS on Windows. Alas it wasn't to be. I am still writing this failure up as it may be useful to someone, but this story doesn't have a happy ending.

TL;DR; AWS EFS and Windows Server 2012+ are very incompatible due to lack of NFSv4 compatibility

I was aware of the limited NFS version support by AWS (i.e. only 4, whilst Windows only supports 2, 3 and 4.1). Yet, I wanted to see what could be done. Plus, it all works fine in Linux. Let's walk through it.

AWS Elastic File System

After the AWS Summit this year, which I was disappointed I couldn't attend, I was lucky enough to attend a replay at Amazon's offices at the beginning of June in London. During it, I got to hear about the Elastic File System preview. It was billed as the missing link in the AWS cloud storage offering, allowed flexible storage options to be delivered and charged without having to re-provision storage or manually add another NAS drive.

Creating and mounting the EFS storage instance in Linux is easy enough. It's still in preview in the US-West region (Oregon).

1. Walk through the EFS wizard to create your EC2 instance. Amazon recommend creating this across all the availability zones in a region. You certainly don't have to, especially as they are charged at 30 cents (roughly 18.75p) per GB-month.

AWS Elastic File System (EFS)

2. Set the security groups on mount points. It's important to note that the security groups will manage the connection between the EFS mount point and the EC2 instance you'll create.

Adding Mount point security groups

3. Spin the shizzle! Note, the full creation process can take about 5 minutes before finally marking the EFS volume as available.

When created, it's still spinning up

Creating the mount points

4. Add the NFS port (2049) to the security group in the usual manner.

5. It was at the point of spinning up and logging in to a Windows EC2 instance that the process went wrong. You could reach the mount point through the IP address. You could also use the 'net use' command to access the NFS volume using the IP address. However, despite the picture below, you couldn't write anything to it. Hence, I couldn't really test it, let along run the performance tests on it.

All the utilities, excited and ready to run :)

6. In order to test whether it was me, I decided to spin up a Linux instance to try to access the NFS volume. I'd do this to check if I could access it from there, create a file and read it on the Windows server. The first part of that went without a hitch.

1. Spin up the EC2 instance
2. Add the EC2 Instance's security group to the EFS mount points' security group (The screen is the same as shown above) 
3. Create a private key using puttyGen from 
4. Access it using the AWS Linux ec2-user via Putty
5. Install the NFSv4 client package into the AWS Linux instance using yum via an elevated command > "sudo yum install nfs-utils"
6. Create directory to mount it to
7. Mount the file system onto that directory using "mount -t nfs4 <mount>:/ /<directory>" 

Voila! Perfect!

connecting to AWS Linux instance via Putty

NFS4 installed using Yum

The only other thing I did was chmod the directory to get access (you can take ownership of it as well) and I touched a file into the directory and sure enough...

Windows fail! :(

So side-by-side. You can see Linux and Windows don't have the same access. Refreshing or reconnecting makes no difference in Windows. I changed access to the file to everyone and still no luck. However, Linux had absolutely no issues. Just for fun, I removed the security group access and tested the mounting again and it worked fine to block access.

When you've not set security group on EFS mount points

Conclusion

At the time of writing (08/2015) this issue arises from the annoying lack of [free] support from Microsoft for NFSv4 and the choice by AWS to only support NFSv4 (the only version Windows doesn't support). Here I have to be honest, I don't know which is worse. Whilst there is the possibility this could be shared across a Samba connection, you've got to then run an EC2 instance just to do that and this will increase latency. I'd definitely say that this product isn't ready to take share from Microsoft in this arena in the enterprise, though of course it works on Linux based environment perfectly well. 

The product will continue to mature I'm sure. However, I'll have to put my Windows performance investigation on hold for now sadly.

SAMPLE: Azure v AWS - Judging Trade-Offs.

Judging cloud platforms is one of the things I find myself doing a lot these days. Working mainly but not exclusively on the Microsoft stack, this generally boils down to two main options. AWS or Azure.

Now, personally, I go for AWS by default. However, for various reasons, I refuse to tie myself to any one vendor. Plus, it allow an effective, vendor neutral position to be taken and for those that know me, it cuts straight through sales cr*p to see if what vendors are saying actually matches their promises (in the main a lot don't). I tend to do this in conjunction with the organisation procuring, since it's important not just to check that vendor systems work, but that it works in context. This is especially the case when organisations are aiming to become more agile, since they will have a much closer working relationship with vendors than most vendors may feel comfortable with. So it is another tool in the toolbox to help evaluate how the line of business as a whole (business, data, application, technology, support and security) works.

How Do I Evaluate the Difference for Stories?

Trade-off analysis doesn't start with this question, but with a previous question, which is "What is it I want to achieve?" since this then leads to the all important question "What question(s) do I need to ask to evaluate vendors?" and there may be multiple ones you need answers for.

Throughout this short blog, let's use the example goal:

"Given I have to host a new room booking platform,
 I want the highest on-demand available infrastructure for the lowest monthly cost 
 So that I can extend the application in the most cost effective way"

Once we've understood the value of terms like 'cost effective', we can now look at what the availability needs are.

Let's use Microsoft Azure's own infrastructure diagrams for this. Attached is a snip of a Microsoft Blueprint for Azure hosted infrastructure.

fig 1 - Microsoft Blueprint

Comparing OnDemand costs is simply a matter of adding up all the costs for the components of network, data-store and VM for similarly matched specifications. Comparing the market price of Azure and AWS components, we see:

fig 2 - AWS v Azure Platform On-Demand Pricing

So that's the price... and AWS is cheaper... for 'bigger' hardware (same pricing tier, though did the story contain anything about application hardware specs?). Still, it's one of the two variables you need to determine cost-effectiveness. The other variable is availability guarantee.

Measuring Availability

Using the same techniques found here, it looks like it gets worse for Microsoft when looking at systemic availability. 

Azure: 99.9996%

AWS:  99.9999 %

Note, systemic availability is actually the important thing in every platform. The availability of individual components is next to no use to you as an enterprise. It only takes one component to fail irrevocably and your platform is done. 

Heard the old adage "You're only as strong as your weakest link?" When thinking systemically, such effects are a lot worse than your weakest link, since you can never make up for one weakness without impacting other elements. This is one of the reasons we host on two different, load balanced servers. Since for one single application-services-data stack on 3 VMs, each with 99% availability, we can only have an expectation of 98.01% uptime in total.

Summary and Future Posts

I started writing up comparisons for Reserved and Up-front pricing on AWS and Azure and felt the original post getting too long, even for me. So I've split it into a couple of posts to launch bit-by-bit.

The crux of all of these is to always know the question you're trying to answer. It's not a matter of boiling the ocean on day-1. After all, that's the promise of cloud. You can scale the frying pan later. 

Also, don't forget that you have a number of other options to bring these costs down. MSDN subscriptions and BizSpark give you varying levels of Azure Cloud credits and AWS gives you 'free-tier' infrastructure for 12 months which might cover your needs entirely. So you have to consider a more holistic approach to understanding your options and constraints, since the latter is your job, not the vendors.

AWS Cloud Summit 2014

I have started writing this before the start of AWS' Cloud Summit at the ExCel in London. The AWS Summit is usually a good event and as far as the big cloud players are concerned, is my favourite of the events. There is good attention to detail, lots of vendors, free food and coffee, which is always a major bonus. You get the chance to talk to some of the AWS staff and solution architects, which is always a huge bonus. This isn't going to be a live blog, as you can follow me @EtharUK for that, but at the same time, it will allow me to record some thoughts in more detail as the day progresses.

As it happens, I was at an AWS Bootstrap workshop yesterday and I am trying to hunt down a solution architect who can answer a question I had from that, Sabastian the trainer couldn't answer at the time. Best go find such a target...

Keynote

I was worried that I wouldn't be able to sit through the keynote as it was going to be two hours long. However, Steve Schmidt's presentation was actually quite informative.

Carlos from Just-Eat showing how AWS has facilitated their agility

Carlos from Just Eat was here again, but Channel 4 put in an appearance, explaining how data drives their advertising decisions, which in turn have led to an 8-fold increase in benefit to customers.

The current AWS estate

The top-level AWS service catalogue hasn't seemingly changed much from last time. That said, the number of services, which include addtios to service offerings, which I would have liked to hear more about, has increased dramatically. So much so, they didn't fit on a standard linear graph, which could have had a much stronger impact. Oh well, they're techies :o)

Schmidt showing us the mis-scaled pace of innovaiion ;)

The one thing we heard a lot more of was governance. Whilst AWS provides enough tools to deliver a reasonable level of governance, there was much more a hint around how it was being used in the enterprise sphere.



There has recently been a lot of noise about hybrid-cloud solutions. Steve Schmidt spend a little bit of time mentioning the interoperability of cloud and on premise solutions. In my experience, there is a lot more to it.

My epic fail attempt to win a Kindle

What's the answer to my question?

Yesterday I was at an AWS workshop. In it, Sabastian the trainer, mentioned that records deployed to an AWS availability zone, with a slave availability zone, would synchronously commit changes on the master and the slave. It doesn't commit this to the master until it has been committed to the slave. This gave me some cause for concern.

The aim is if the master availability zone goes down, the slave doesn't goes down. This is sensible form the point of view of the master. However, if the slave availability goes down and the master doesn't commit unless the slave also commits, then unless there is a way for RDS to commit this to the master, you have an issue. Indeed, this situation could technically result in lower availability than running single instances of the DB.

Why?

Firstly, I am pretty sure that this is DB instance independent. Assuming you have a synchronous process that requires two activities to complete successfully. However, I have not seen or heard evidence to suggest this is a two-phase commit process. So to illustrate the issue, an example might be useful.

Supposing the two cloned platforms across the two availability zones each have a 99.95% availability. For a master-slave configuration where the commit of the master is dependent on the slave, this introduces a dependency chain and means that the whole uptime of your entire platform requires both services to be up in certain configurations. The result is this reduces the availability to about 99.90% (i.e. the probability of both systems being up). This is lower than any single server and certainly lower than systems running independently in parallel.

This doesn't mean that it is a problem. After all, you can architect to remove this risk and hence increase the availability of the data sources as a whole. However, I put this to our trainer yesterday and he said he'd go away and ask. Hence, I didn't receive an answer at the time.

I spoke to a solution architect this morning and he too didn't have an answer. So it would be good to get one. I am not too bothered whether it is positive or negative, but it would dictate the complexity of a system design and also provide a theoretical constraint to conduct trade-offs around . Known-unknowns can be troublesome, especially if you've only just discovered it, since it was an unknown-unknown before. I must get round to chasing this up.

**** UPDATE: After chasing this up, it appears that there isn't currently any documentation to corroborate the assertion from a few other SAs that the platform would prevent the saving of data in the event of an AZ failure. However, this also doesn't tell me if it wouldn't. I've had my details taken but no sticker given ;) ****

400 - EBS and EC2 Optimisation

This was a 400 track. There were some extremely useful slides in this track. AWS went through an intro explaining that EBS is basically a storage mechanism with a queue attached and is not like a normal disk. I still think it kind of is, when you include the buffers and caches. Both standard EBS and EBS PIOPS (Provisioned IOPS) were introduced and in the latter case, we briefly touched on the configuration of the IOPS provision.

However, importantly for me, the existence of a formal queue defines a specific need to understand the block size per IOP, as this can significantly affect the throughput of the system. The bigger the ECS instance, the more you can write (specifically, the faster you can write the data), the bigger the EBS queue, the faster it can write the standard 16K blocks.

This suggests that the best way to write the data to disk is to chunk them up in 16K blocks (or multiples thereof) and write them in parallel, which was suggested in yesterday's workshop.

200 - Hybrid Environments with AWS

This was an interesting track, however most of this is pretty standard. For indeed, some of my clients have done this for a while. I have a much greater appreciation of this via some of the security group work I've done since last year. So I am liking the way that hybrid and cloud solutions can work together. There didn't seem to be too much that was new though.

Hybrid Environments - Yes, I was a bit late to this one :-S

300 - Building for availability and cost

Fitz, a solution architect at Amazon presented Here.com's autoscaling solution. Through all Autoscaling demos at this conference, the mantra "scale up fast, scale down slow" was repeated. This is because it takes little time to prevent an AWS EC2 instance from receiving traffic, but it can take an age for it to get to a position to receive traffic. So that makes sense.

End of Day

Not a bad summit. I don't think I will take away as much from this as I did last year... aside from that my weight isn't appropriate for perspex chairs (Sorry Amazon). Amazon always put on a very good show. I'm sat here with a beer whilst I prep to tackle the tube 'struck' TFL public transport system before getting my train to Manchester. There is a lot to take away and I'll have to let that lot ferment as much as the beer before brewing up a new vat of ideas for the future of my architecture work with the new tools AWS provide. I am still to be convinced of the some of them, such as the need for schedule based autoscaling, which I see as a way to circumvent the 15 or 20 minute spin up of a new platform. However, they do solve some problems so are not at all without purpose. Especially in warming up environments for immediate use. 

Additionally, the EBS optimisation session has set off a few ideas around using queuing theory to try to explain some of the numbers Amazon have found in their testing. One thing that appeared time and time again was the experience of other speakers, a large proportion of whom spent a lot of time and effort creating PoC platforms to prove the viability of AWS.

Google Cloud Platform Roadshow: Manchester

Welcome landing slide

I had the good fortune to be at Google's Cloud Platform Developer Roadshow, which kicked off in Manchester's TechHub this week. The combination of my early arrival, never having visited the old TechHub building, not being able to get into the new building, the TechHub website still showing the old address, Google showing the new one did make for an interesting rush as I did wonder where I was supposed to be. When I then incorrectly found myself back at the old TechHub offices, I wasn't alone it seemed as I met a few students who also didn't get that memo :)

In the end, we got ourselves back and were rewarded with coffee and breakfast pastries, which given I hadn't had breakfast, more than made up for it. Even if It did mean my name badge curled up almost instantly due to the amount of very brisk walking my 118kg frame (+7kg laptop bag) had done back and forth.

Curled up name-badge worn by Mr Radiator :-/

Having lost my original seat, I then initially got relegated to the cheap seats, so figured I best move :)

Not a great view :-D

Introduction to Beer and Salvation

Doug Ward (@SimplyDoug1987 on twitter) ran through the usual housekeeping and informed us that we mustn't stop to collect personal belongings but to save the beer. I thought that was a good point as nobody usually likes a warm beer. But as as Brad Abrams, Group Product Manager introduced the agenda, the Fireside chat did make me wonder if avoiding warm beers were really the motivation to save them after all :)

Doug Ward keeping house

Keynote

Brad Abrams ran us through a quick whirlwind of the Google platform. I was pretty familiar with this already, though I don't use Google AppEngine much. I overheard Brad talking to a group and mentioning that they are in the process of supporting SQL Server 2008 R2. Not quite clear as to how as yet myself. Still quite intrigued and so I gather, was Mandy Waite when I approached her about it towards the end of the day.

Google's Cloud offering

Developer Advocates Mandy Waite and Laurence Moroney joined Brad after he presented the agenda, to walk us through a number of deep-dive demos of Google's AppEngine, including presenting the new OnDemand pricing and Sustained Use discounts for any usage over 25% of the month on each platform. This is a very useful discount and after I questioned Brad on whether or not it had to run continuously, he confirmed that it didn't. It just had to use 25% of the 10 minute blocks of a whole month of OnDemand use.

New Google AppEngine Pricing Model

For those outside the Microsoft sphere, together with the drop in OnDeman pricing, this suddenly makes the Google AppEngine a very attractive proposition. I intend to cover why in a later blog post, but like other models on the market, this has the ability to create a maximum amount of compute and storage costs that you have to pay per month, but applies it on what you actually use, unlike AWS and Azure, where you either commit to reserved instance pricing, or 6 to 12 month blocks up-front, which hits agility and also fixes your discount to a level above your real OnDemand usage (if you pay up-front and use significantly less than you forecast). See the Moz story for an example (though this appeared to be an issue with technical best-practise and inefficient use of AWS, which in my experience of PR and marketing agencies, is unfortunately all too common an occurrence).

The focus was very much on mobile development and there was a lot of mobile developers in the audience as well as some familiar faces on the Manchester tech scene (See the back of Saftag's head below).

Shaf Chaudry showing sponsors around  before the start

Demos

Mandy and Brad ran through the creation of a Sudoku solver and Meme Maker using Python, this was supplemented with an Andoird App written in Android Studio (which by the way, I really like! It's much better than Eclipse, which I've done a bit of work in before, and brings a lot of Resharper like functions to the IDE - which I really missed in Eclipse). Requests were made through JSON secured with OAuth tokens.

Mandy and Laurence both demo'ed the boilerplate for hosting through the AppEngine API, demonstrating the use of Python scripts and the gcloud CLI tool to manage the OAuth keys (which is a much more long long winded process) and testing functions through Google's Developer Console. I've used this before to generate requests and test access to Calendar info for some .NET projects I've done and to be honest, it's best of breed at the moment in this particular area, but AWS still hold the balance of power across the board IMO.

Brad explained that the environment gives Google developers a free Git instance and runs your unit tests if you have them. This then displays the results in the console for you to check on. This is a pre-ested commit (gated check-in) so if it fails, it doesn't deploy to live. This is nice, but AWS also has a free git instance. The key difference is that Google's Cloud Developer console has in browser editing, which automatically runs the tests again and deploys it to live, but also puts it in the Git repo for your team (or another dev team) to pull later. This is crucial, as cross team development needs up-to-date and common code bases to use and the ability to force changes for DevOps/App Support staff, but still maintain the consistency of the code base is essential!

Brad and Mandy run through the storage of images in buckets for the meme-maker demo app

Conclusion

All in all, there was a good number of take-aways. Given my current working platform (Microsoft) I don't see myself changing off AWS any time soon. That said, the MS hold has more or less lipped away from a large number of small business and start-up community groups. So I can see this featuring very heavily in interaction with those markets going forward.

Google AppEngine definitely offers a good (and quick) alternative to AWS if you want to host OSS platforms. I think they're still a little slow on the release of new language support, as they pretty much had the same languages on offer as two years ago. That said, there are some very nice touches in AppEngine, such as the ability to SSH into your Linux VMs and work on them locally. However, if your main work is PHP, Java and especially Python, you can be up and running with a fast platform, very quickly and cheaply.

All in all, a good half-day. The beers didn't need saving either :)

Deploying from SVN through Jenkins to AWS Elastic Beanstalk (Part 2): Linking Jenkins to AWS EB

Following on from Part 1 of the blog on integrating Jenkins with AWS EB, this concludes the two part series by focussing on the AWS deployment process within Jenkins. At the end we will briefly outline the limitations of AWSDeploy to EB and what you would need to look to if your needs are more complex.

So what does Jenkins look like?

Setting up Jenkins will basically require executing the following the steps:

1. Create a 'New Job' in Jenkins 
2. Fill in the URL of  your SVN repository
3. Decide on Jenkins' polling frequency for SVN
4. Fill in the batch process details, including MSBuild.exe and AWSDeploy.exe CLI, with appropriate parameters
5. Save the job

Step 1: Create a 'New Job' in Jenkins

Nice and easy, from the main Jenkins page, click "New Job" on the left hand menu in Jenkins.

When the new job page loads, fill in the details of the job you with to create. You'll want to create a free-style software project. 

I Normally prefix the job name with 'RELEASE-' but for this demo, I am being a bit slapdash. When you are happy with it, click the OK button.

fig 1 - Creating a 'New Job' in Jenkins (click to enlarge)

Step 2: Configure the Job

Jenkins then moves to the job configuration page which allows you to set up the SCM (in this case SVN), the Build Steps and Post Build Actions.

Hence:

1. Fill in a display name under "Advanced Project Options" if you want it

2. Under "Source Code Management" select the Subversion radio button and enter your repository URL. Jenkins will poll your SCM and if you need to enter SVN credentials, a validation help link appears and you can click to enter your SVN credentials within that.

fig 2 - Links to enter your server's credentials. This server doesn't exist - just showing the link

3. Select your method of authentication. In my case, I chose Username/Password and then enter your credentials. Important note, the site runs unsecured by default. Once you have entered the credentials, click the OK button.

fig 3 - Subversion authentication in Jenkins (click to enlarge)

4. Complete the rest of Jenkins' SVN config. I always check out a fresh copy so I don't have previous builds laying around and potentially making a mess of the build. Note, you can also check out multiple URL's if you have dependent projects. This can of course, also be done through an SVN 'extern' declaration.

5. Build Triggers - This is an important feature that allows you to configure what sets off the build. For example, if you have a dependency chain of projects/solutions which are already set up as Jenkins jobs, you can choose which project(s) need to complete before this job runs. Projects are separated by commas.

Here you should select the "Poll SCM" step. This then brings up a text box where you can enter the polling frequency in a CRON like language. Jenkins polls your SCM (SVN here) and stores the latest revision that it builds. If there is a change in that revision number on a poll, it then starts a checkout and build process.  

Alternatively you can choose to build periodically, or combine the two.

6. The build steps - This is probably the key elements when it comes to deploying to AWS. For simplicity, I have put all the steps in this demo into one build step so that it completes the steps in one go. However, you would normally want to split them out into multiple steps, such as 'Build', 'Test', 'Deploy' so you can stop at any point. You can pick up the build artefacts between the steps by using the same workspace environment variables.

Putting it all together still works, as long as an errorcode is returned, but it isn't neat.

Clicking on the "Add build step" button open up a text area when you can enter a list of  Windows console commands. In my case, they are:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe "%WORKSPACE%\AProject.sln" /p:Configuration=Release /p:Platform="Any CPU" /m
cd "%WORKSPACE%\AProject"
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe /t:Package /p:Configuration=Release
"C:\Program Files (x86)\AWS Tools\Deployment Tool\awsdeploy.exe" /w /r /v /DDeploymentPackage="%WORKSPACE%\AProject\obj\Release\Package\AProject.zip" "%WORKSPACE%\AProject\AWSDeploy.txt"

You will notice the %WORKSPACE% environment variable in this series of commands. This is the Jenkins workspace that the code has been checked out to. There are a number of environment variable and they are: 

The following variables are available to shell scripts

BUILD_NUMBER

The current build number, such as "153"

BUILD_ID

The current build id, such as "2005-08-22_23-59-59" (YYYY-MM-DD_hh-mm-ss)

BUILD_DISPLAY_NAME

The display name of the current build, which is something like "#153" by default.

JOB_NAME

Name of the project of this build, such as "foo" or "foo/bar"

BUILD_TAG

String of "jenkins-${JOB_NAME}-${BUILD_NUMBER}". Convenient to put into a resource file, a jar file, etc for easier identification.

EXECUTOR_NUMBER

The unique number that identifies the current executor (among executors of the same machine) that's carrying out this build. This is the number you see in the "build executor status", except that the number starts from 0, not 1.

NODE_NAME

Name of the slave if the build is on a slave, or "master" if run on master

NODE_LABELS

Whitespace-separated list of labels that the node is assigned.

WORKSPACE

The absolute path of the directory assigned to the build as a workspace.

JENKINS_HOME

The absolute path of the directory assigned on the master node for Jenkins to store data.

JENKINS_URL

Full URL of Jenkins, like http://server:port/jenkins/

BUILD_URL

Full URL of this build, like http://server:port/jenkins/job/foo/15/

JOB_URL

Full URL of this job, like http://server:port/jenkins/job/foo/

SVN_REVISION

Subversion revision number that's currently checked out to the workspace, such as "12345"

SVN_URL

Subversion URL that's currently checked out to the workspace.

The batch commands perform the following functions.

The 1st command builds the solution containing the project, using the release configuration. In a normal project I at least use the web.Debug.config and web.Release.config files with the MS Build match and replace mark-up into the main web.config file. A tutorial blog can be found here.

The 2nd command enters into the directory of the built project. This is just so we can run the package verb for MSBuild.

The 3rd builds a standard deployment package out of the project.

The 4th line is the AWS Deployment line. This actually carries out the deployment of the package created in batch step 3 previously using the AWSDeploy.txt file we created from within Visual Studio.

Post-build actions
A post build action in Jenkins is an event that takes place after the build steps. They occur regardless of whether or not the build has completed successfully and encompass one or more of the steps shown in the screengrab below.

fig 4 - The Jenkins post-build actions (click to enlarge).

In email post-build steps, Jenkins allows users to be sent emails for unstable builds (it builds but tests fail), build failures and send separate emails to the people who broke the build.

You'll notice form the screenshot that there is the option of publishing JUnit tests. Obviously, MSTest results are not exactly in the same format. However, you can run a build step to convert MSTest's TRX to HTML files using tools such as the MS Test Report Generator. There is a similar process for NUnit results.

Recommendations:
Don't forget to set up e-mail alerts within Jenkins for job events as a "Post-build action". You can also tie events to an RSS feed. In either case, you have the option of using them for failed builds and all builds. Plus the email benefits identified above. Note though, Jenkins doesn't automatically set up an (or your) email server. You have to have a mail service/daemon running to send emails.

Also, I definitely recommend post-build steps to publish your test results. This may include a step to post to your build monitor if you have one. Maybe naming and shaming the individual breaking the build... not that you want a harassment suit on your company's hands of course ;-)

Step 3: Run the darn thing!

When you check in some code, at the intervals specified for the Jenkins cron, Jenkins will poll SVN, clean checkout the code, build, test and deploy the code. Any failure will cause the build history to include the usual red light.

fig 5 - Build history, including failures 

You can of course, run the build using the "Build Now" menu link in the top left menu to kick it off manually. In either case, there is a significant increased delay over any local process, but that is to be expected since the deployment is going over the wire and EB is incrementally building the environment (it would be longer first time out. I've had to wait over 10 minutes sometimes. However, )

The following is the example deployed to AWS using the above process. As well as using AWS Elastic Beanstalk, for my own work, I have a route 53 entry to the domain name and a back end DB.

fig 6 - Deployed EB example site (click to enlarge)

Conclusion

Jenkins has always been a really easy to use system for CI. I've found it easier to use than ThoughtWorks Go. However, both Go and TFS give you more customisation options out of the box. You can certainly expand Jenkins using custom plugins. Obviously, there is quite a bit more to do to set up a CI system from the above. But it gives you a framework to modify and work with. 

Also, the use of the AWSDeploy.exe makes it really easy to deploy fairly simple environments. 

Limitations

When you get up to the level of having to manage large, custom architectures and deployments, where detailed configuration and set-up of multiple AWS resources are requires with EC2, ELB, SQS, S3, SWF, RedShift and big data instances for example, a basic AWSDeploy text file won't cut it any more. 

At that point, you would need to consider moving from just using an EB setup to using CloudFormation to set up a more complex cloud architecture. As it happens, EB does basically generate a JSON Chef  Cookbook which is used as the CloudFomation template. You can see this if you go to the ClouseFormation stacks page in the AWS Console. I suspect there will be times when you'll need to roll your own.

AWS Summit 2013 - London

AWS Cloud Summit

At the beginning of the day I fell out of my bed into the cloud summit. Seeing as I was less than a stone's throw away, it was one of the easiest journeys to a conference I had managed.

We registered with our bar-codes from the original e-mail, though this proved to be somewhat of a problem technically, since the bar codes didn't seem to appear on everyone's e-mail. this caused a bit of a technical glitch which delayed some poor souls, but mine worked fine so I was in fairly uneventfully.

The geographical layout was available a day prior to the summit via the Guidebook app, which I have to admit has been one of the most solid platforms that I have encountered for this sort of thing and beat the Azure backed Eventboard app from last year hands down. AWS obviously put some work in to get this right. 

What was interesting about the layout was the location of a labs sections near the entrance, with the keynote area cordoned off with high cloth walls which hid a stage where Werner Vogels, CTO of AWS would introduce the summit. The labs areas where we got to try out some of the infrastructure, including the just released (as of today) S3 storage and RedShift storage platforms to the European market. This area also contained large yellow beanbags for the more bohemian amongst us to use to sit, write, blog, experiment etc. I didn't try them out because knowing me, I'd not be able to get back up again because of a) Sleeping or b) Imitating a turtle on it's back.

The infamous beanbags! My nemesis :-)

Upstairs, near the black cloaked keynote area, sponsoring organisations and the supporting acts were plying their trade and demonstrating their wares. in the centre of that area was the AWS exhibit itself, manned by a number of architects of the platform, whoc were showcasing some of their logical reference architectures. I had a useful conversation with Andreas about availability, since this is an area I am interested in and have blogged about before. I pointed to various potential single points of failure and and Andreas managed to explain to me the points of availability and how they have solved some of their high availability problems in the reference architecture, which I could read up on and use as case studies. All very interesting stuff.

The chaps make last minute checks for our arrival

I was also lured, stomach first, to the Smart421 exhibit by the temptation of boxes of Smarties stacked pyramid-like on their desk. What was interesting about this chat was that they reminded me that unlike the Azure platform, Amazon has a very robust mechanism for having PCI-DSS compliance. After all, they do this every day for their own business. Indeed, Stephen Schmidt went on to introduce the security model under AWS and in particular, the very inspiring and competent VPC (Virtual Private Cloud) offering which uses CloudHSM as a hardware security management option where the client holds the keys and not Amazon. Indeed should anything happen to the physical media, such as tampering or accidental damage, the keys are wiped immediately. This was something that I heard hide-nor-hare of at the Azure conference and PCI-DSS, to the best of my knowledge hasn't been adequately addressed to the same level by Microsoft and certainly isn't as mature. 

A little behind schedule, Dr Werner Vogels opened the summit with a comprehensive (read long) keynote on the AWS now and in the future, including some of the new services that have come about recently (53 in the first quarter of 2013 alone). He introduced a number of customers who have used the AWS platform, including a number of very large names in the UK, such as Shell and as well as smaller start-ups such as Shutl.

Big Werner Vogals on a very big stage

Werner outlined the strategy for the company and gave us little insights into the internal workings of Amazon. In particular, how Amazon believes in and practises lean principles at their organisation. The insight into how some of the cloud based operations at other organisations seemed to, in part, back up some of the stereotypes associated with the governance of data, such as don't put most sensitive data online. This didn't seem to be a concern at all points and was certainly not one imposed due to any technical limitation, but it did show that some organisations do still have some concerns surrounding the non-colocation of their data.

Steve Schmidt then took over and introduced a number of key information security objectives. He had a lot to say and there was a lot of detail about the AWS security processes and policies. Very impressive as it happens but given they have DoD clients, this is hardly surprising. One of the implicit things that both Steve and Werner introduced without 'saying' in both their own and case study examples was the need for good governance. Indeed, shell were very explicit about their data governance and as such, cloud should never be considered something that should allow your governance processes to become lax. Indeed, the opposite is true in cloud environments. An important lesson there, especially in VPC environments where the clients manage their own keys.

After lunch, which was very popular (So I started to write this blog post until the queue died down), the breakout sessions began. I stuck myself on the bootstrap sessions mostly, but wanted to head into the Architecting for High Availability thread. My phone's battery was being a bit 'negative' and I worried that I would run out of juice from taking all the pictures that I was taking and sure enough, by the time it got to the HA presentation by Ianni Vanvadelis, I had no more juice to take any pics of relevant slides. As it happens, for the customer case study, presented by Dan Richardson, Director of Engineering at Just-Eat, the slides were not there anyway. It was unfortunate, but he actually did a brilliant job in winging it and still managed to get his message across.

Prior to that however, I attended the Bootstrap tracks of "Your first week with Amazon EC2", "Agility and Cost Savings: Achieving the IT 'X-factor'" and the Keynote tracks of AWS OpsWorks, presenting a deep dive with the OpsWorks environment by Thomas Metschke, which was a very technical example of how to combine Chef, Ruby, Git and Jenkins with OpsWorks to deploy to different CM configs. OpsWorks is an excellent platform for this, I have to say.

Thomas takes us through an OpsWorks deep dive. I really like this tbh!

I went to the X-factor track and my phone died completely. It was tough going from that point onwards, but obviously means I should have known how long my battery would last. However, not being big on photography (with a face like mine, it isn't something that I do much of ;-). Comparing the costings of cloud versus on premise platforms is something I tend to do a lot of anyway, so there wasn't really much new there. However, there is a TCO tool that has been created by AWS for just this purpose. Also, the different costing models were introduced and made very clear. What was interesting was the use of 'Spot pricing'  models, which I finally figured out a use for, especially in non-mission critical/off-line work. Reserved instancing is also something I am going to be looking more into. However, it is good to know that I value things the same way AWS do. Having grown up in a house full of economists and financiers hasn't gone to waste ;-)

AWS Pricing Models presented to us by Dan Roger

Dan shows us the break even with the On-Demand services

What was interesting about what Dan Roger told us about was what he didn't tell us. In that session he drew   comparison of On-Demand against reserved instances at various levels. you can see the slide above, but what he also shows is the break even with Heavy, Medium and Light Utilisation Reserved instances with each other. In this example, at 8 months it makes no difference which option you choose. This is on top of the very obvious comparison with 1 or 2 month on-demand services.

I spent a lot of time getting a lot of valuable information from the AWS guys playing piggy in the middle with the vendor space about their platforms. In particular, the AWS reference architectures will provide a lot of very useful information, not necessarily in how I would do it, but in providing patterns of best practise from which to work.

As an architect, I have certainly not had anywhere near as valuable a day as I've had today. So I am quite a happy bunny. Plus, having played around with AWS EC2 already, I am much happier than when I was playing around with Azure. There are a couple of blog posts that I can see spinning off this, especially in the area of highly available systems.

All-in-all, a very productive day :-)