New case study: Nisa Retail Mobile app on Amazon Web Services

Amazon Web Services have recently published a new AWS Case Study, looking at how Nisa Retail have implemented an innovative mobile application to make their members’ lives easier. Nisa engaged with Intechnica to design and develop the app, which is built on AWS technology.

As an AWS Consulting Partner in the Amazon Partner Network, Intechnica was well positioned to leverage the power and flexibility of AWS to deliver a scalable solution that would not impact on Nisa’s core IT systems such as their Order Capture System (OCS).

The full case study is available to read on the AWS website.

If you need an application built with performance in mind from the outset, or specifically built around the flexibility of the AWS infrastructure, Intechnica can help. Fill in the form below or use our contact page.


AWS Chief Evangelist pays a visit to Manchester’s AWS User Group North

The group has seen tremendous growth in the past few months, going from 167 members to 219 in June alone

The group has seen tremendous growth in the past few months, going from 167 members to 219 in June alone

There was a very special edition of the Amazon Web Services User Group North in Manchester last night, as the Chief Evangelist of AWS, Seattle’s own Jeff Barr, was our guest speaker. After a 5,500 mile road trip visiting user groups across the US, Jeff is in the UK to talk at conferences and various user groups across the country, with his first stop being on Monday night’s AWS User Group North (@AWSUGN).

TechHub Manchester was cram packed with 60 AWS users of all experience levels. Everyone had plenty to take away from Jeff’s fascinating talk, as he covered each AWS service. This was a unique opportunity to ask one of the most senior people in AWS direct questions about the various services, and one which was seized by the group members!

AWS Chief Evangelist Jeff Barr takes questions from the packed TechHub Manchester

AWS Chief Evangelist Jeff Barr takes questions from the packed TechHub Manchester crowd

The questions came in thick and fast, but Jeff did get a break at the halfway mark upon the arrival of a mountain of pizzas, provided by event sponsors Intechnica. As AWS consulting partners, Intechnica have supported the user group since its inception 2 years ago.

If you missed out on Jeff’s talk (where were you?!), he’ll be at the London AWS User Group on Thursday 27th June.

7 Great Lightning talks at Amazon Web Services User Group North

We’ve been organising the Amazon Web Services User Group North (or #AWSNorth on Twitter) for about 2 years now. The group brings AWS users and experts together in one place to foster learning, discussion and networking, and it’s always an interesting evening – typically we have a guest speaker showing an AWS related tool or sharing a use case.

We usually have an Amazonian in attendance, which is great for the AWS users to voice their opinions and ask for help in person. At the previous meetup, Ryan Shuttleworth from Amazon told me about the Irish AWS User Group that recently started up and their success with lightning talks – quick-fire 5 minute long talks from members of the group. The idea of lightning talks is that you get to hear from a variety of speakers on all sorts of topics in a short space of time. It’s also somehow appropriate that a group about “clouds” produces “lightning” talks…

So last night we had our first go at lightning talks. First in the firing line was David Hall, from the night’s sponsors TeleCity Group, who explained the history behind TeleCity’s AWS Direct Connect service. This was followed by Amazon’s Data Scientist extraordinaire Matt Wood, an old favourite speaker from the early days of our group. Since the first few meetups, though, Matt has relocated to Amazon’s home of Seattle, so in this case he returned in Skype form. Matt(‘s giant head on a screen) gave a great lightning talk on provisioning throughput “like a boss” (click link for Matt’s slides).

Matt Wood gave his lightning talk live from Seattle

Matt Wood gave his lightning talk live from Seattle

Next up was‘s Sam Bashton, who talked in depth about their experiences with AWS CloudFormation, followed by Alastair Henderson. Alastair took the opportunity to open the floor to suggestions on the best way to solve a specific problem he was having, utilising both his presentation time and the expertise of group members effectively. Smart thinking! Richard Bosomworth took his turn, giving a detailed hands-on demonstration of using Scalr to manage EC2.

Alistair Henderson took the opportunity to seek advice from his fellow AWS enthusiasts

Alistair Henderson took the opportunity to seek advice from his fellow AWS enthusiasts

Tom Chiverton gave an interesting and open presentation about his experiences in moving away from “spinning rust” to quote Linus Torvalds, with a focus on Amazon Simple Storage Service (S3). And in the final talk of the evening, Channel 4’s Ric Harvey returned, having been our headline speaker at the previous meetup. Like Tom, Ric talked about using S3, but this time using it a little bit differently.

Thanks to TeleCity Group for sponsoring the drinks and pizzas, and to Tech Hub Manchester for once again being great hosts. If you have a requirement for a great venue to host your tech meetup, I would highly recommend talking to Tech Hub!

And of course, thanks to David, Matt, Sam, Alastair, Richard, Tom & Ric for making the evening a success with their brilliant presentations. We’ll be sure to do more sessions like this in future in the hopes the lightning strikes twice (sorry!).

If you’re interested in AWS, consider joining our Meetup group or one of the many user groups around the world.

How to create templates of Amazon EC2 environments

Sometimes, when you’re developing an application (or even in the testing stage), it’s really useful to be able to regress back to a previous iteration or even branch off into several unique environments. You might also want to set up identical environments to send off to other people, such as team members, clients or even sales teams. Cloud platforms like Amazon Web Services and its Elastic Compute Cloud (EC2) service offer a cost effective solution to this problem, especially compared to traditional (“tin”) infrastructure, but managing all these environments and machine images in the Amazon Management Console can quickly become confusing. It would be easier if you could set up a template for each environment iteration and fire up said environments directly from the templates.

This is actually very simple to achieve – even for those without deep technical knowledge of AWS or similar IaaS offerings – by using a neat application called CloudFlex (disclosure: yes, it’s made by Intechnica, but we find it very handy).

Step 1: Set up the template

CloudFlex uses a step-by step wizard to guide you through the process of defining what your environment should look like. This includes the number and type of AMIs (Amazon Machine Images) that should be deployed, their security groups, elastic IPs, load balancers and everything else you might need. You can also give it a descriptive name to help you identify each template at a glance. All of your templates are shown in one place so you can see what you have saved and launch environments from them easily.

Step 2: Launch an environment

Once you have your template set up, you can start an environment from it. You can either do this manually or schedule it to start up whenever you like, or as frequently as you need (such as every morning at the start of the working day). When you start an environment manually, all the details are pre-populated by your chosen template, which keeps everything consistent across multiple environments. After the environment has finished spinning up, CloudFlex gives you quick access to details such as its public DNS; you can also connect to a machine image’s remote desktop through this screen. From there you can do whatever work you need to do on said machine.

Step 3: Save environment snapshots

Now that you’ve connected to your AMI and done your work, you might want to keep a snapshot of that image, in its current state, to go back to later (or to distribute to team members etc). You might not want to allow access to the AMI you’re working on in case something gets changed. The best solution is to create a new template from a snapshot of your AMI. To do this, from the details page of your environment in CloudFlex, click “Create Machine Image” (after giving it a name) and the AMI will be copied in its current state to your AWS account. Now, repeat steps 1 & 2, this time choosing your new AMI as the machine image for your template. You can then start up as many concurrent versions of the environment as needed and send remote desktop files for each to whoever needs access.

CloudFlex is available from Intechnica from £99 per month. If you want to know more, visit the website where you can sign up for a trial or leave a comment below.

Webinar: Designing Applications for the Cloud

This webinar, from 6th March 2012, was hosted by Intechnica‘s Technical Director, Andy Still. Andy talked about the key principles of designing and migrating applications to the cloud. This includes scaling out, taking new and imaginative approaches to data storage, making full use of the wide range of products and services on offer from cloud providers (beyond hosting), and exploring the many flavours of hybrid solution which can mean all types of business can leverage the benefits of the cloud.

Andy has architected and built a number of cloud-based applications, specialising in highly scalable, high-performance, business critical applications.

If you’re planning or considering moving to the cloud in 2012 then this webinar is essential viewing.

More Intechnica webinars

What are the options for testing in the Cloud?

I’m in the final stages of preparing my presentation and workshop session for the UK Test Management Summit next week in London and its making me think more about cloud computing in general as well as performance testing. Either testing in cloud environments or using the cloud to deliver more scalable performance tests.

Intechnica’s research paper last year, entitled “How Fast Is The Cloud?” investigated the relative performance of a simple eCommerce application on various different cloud platforms including IaaS and PaaS options. We demonstrated that a well implemented cloud solution could out-perform traditional hardware but that poor implementations would confirm cloud-sceptics suspicions about poor performance in the cloud.

At Intechnica, as well as using cloud environments to functionally and performance test code that we’re developing for clients, we use cloud based performance test tools to test our customer’s own test environments. By using cloud based load generators (injectors) and the Intechnica TrafficSpike product, we can quickly provision tens of load generators, use them for a few hours and then decommission the servers. This allows for highly scalable, comparatively low cost performance testing particularly when compared to trraditional models where multiple servers sit idle waiting for the one day per week or month where they’re used to their full potential.

The trend in performance testing seems to be a move away from traditional performance test tools and towards cloud-based load generation. This is demonstrated by the growth in companies such as SOASTA, LoadStorm, and BlazeMeter. Our workshop at TMF will give test managers the opportunity to discuss these different test technologies and obtain a better understanding of cloud performance and the implications for their business. As well as this we’ll be giving attendees the opportunity to use Intechnica’s Cloudflex product to see how easy it can be to provision multiple, identical test environments for themselves.

I’m looking forward to meeting attendees next week to discuss the implications of cloud computing for those of us in the testing industry.

AWS instances, their ever-changing hostnames and the implications for software licensing

I’ve recently been doing some performance testing for a client and evaluating the use of dynaTrace for monitoring application performance under load. As well as an installation of dynaTrace at the client site, we have a demonstration/evaluation licence which is installed on an AWS cloud server. As well as being useful for client demonstrations, this gives us the opportunity to perform proof of concept exercises and “try things out” away from production systems.

Last week, in an effort to save on the cost of keeping the AWS instance up and running all the time, I decided to shut the server down using the AWS console. When I went back to the server and restarted it, I had the following error message in dynaTrace.

I did some investigation and I found that dynaTrace locks the licence key to the hostname of the server on which it is installed. This is all well and good in a normal environment, but I noticed that the name of the host server changed each time that I rebooted. When I installed dynaTrace, my machine name was ip-03a4d76 and when I restarted the server the name had changed to ip-0a3b11c9.

I looked at the server IP address and saw that as the server restarted (even though I was using an elastic IP address to address the server externally), the hostname changed when the private (internal Amazon) IP address changed. The hostname was a hexadecimal representation of the private IP address.

My IP address was and the hostname (which has since changed again) was ip-0a3b11c9 (0A = 10, 3B = 59, 11 = 17 and C9=201).

I spoke to the dynaTrace, the supplier of our software, and they told me that it can be tied to a MAC address, rather than a hostname if required, but that didn’t help me since I understand that MAC addresses change each time AWS instances restart. Instead I looked at ways of fixing the hostname and found that it was remarkably easy (when you know where to look).

On each Windows AWS server there is a program on the start menu called “EC2 Service Properties”. Run this program and uncheck the box “Set Computer Name”, you can then set a HOSTNAME normally which persists after each reboot. Your hostname-dependent software can then be reinstalled or re-licensed and you can relax in the knowledge that your software will run properly next time you restart your server.