Until now Amazon Web Services (AWS) seemed to me to be a warehouse type of business. Their products were difficult to use on their own, but there were small shops which packed it up nicely and sold it on to the end user. However recently my idea of their business model is changing with the introduction of the AWS Management Console – web application to help one organize instances, keys, firewall etc.

Before AWS Management Console there was just a REST interface and console based programs were simply wrapping the web service into form-based executables. No one seriously treated it as a tool to manage a production environment with; its only use was as a testing tool. And there were companies like RightScale or Scalr which provided usable management applications on top of Amazon’s EC2 REST interface. They obviously add a small charge on top of Amazon EC2 fees so with the free management console from Amazon these guys will have to work hard to add value to their products and keep their customers.

But not only companies which build on top of EC2 ought to be worried. The management console is soon to be extended with UIs for other services from AWS – S3 (data storage), SimpleDB (scalable and schemaless DB engine), SQS (message queue service) and CloudFront (content delivery network).

It looks like Amazon is about to do with AWS what they made their first money on – sell directly to the customer and cut out the middle man.

Since mid 2006 Amazon Elastic Compute Cloud (EC2) has enabled customers to provision a farm of virtual servers in a matter of minutes, automatically via a web service, with no initial cost and no contract, and then terminate it just after an hour and pay for that hour only (conceptually it is quite similar to what we do in Extrasys, but on a hardware level instead of application level). But until now it was located in the US, far away from Europe.

What difference does 3500 miles make? EC2 was available from the Old Continent, but the latency was close to 100ms, which is too slow for today’s Internet users. In a loosely related example, Marissa Mayer, Vice President of Search Product and User Experience at Google estimates 100ms to be worth 4% in lost revenues for her employer.

Finally, in December 2008, Amazon made available two geographically separate locations in Europe, and the latency from one of the servers we provisioned there to a machine located in our Crawley Data Centre was less than 20ms!

Our detailed measurements:

Location from/to Latency EC2 UK Latency EC2 US
Data centre (London) 16ms 85ms
Office on ADSL (London) 52ms 131ms
Data centre (Manchester) 21ms 84ms

Will EC2 be a success in Europe? I think so, but I’d be interested to hear your predictions.

UML – why use it?

December 10, 2008

In the last post I wrote about my experience with UML as a requirements gathering technique. Today’s entry is all about UML again but in a more general context. I’ll explain why, in my opinion, UML is a useful tool in a software developer’s toolbox.

Right now the Unified Modeling Language (UML) mostly serves as a communication aid between people involved in software development. It tries hard not to be ambiguous (often the case with spoken language) and to be easy to understand. The OCL constraint language may be employed to restrict diagrams further. Maintainability of diagrams depends on the software you use, but there are some nice drawing tools out there such as, for example, Poseidon for UML which we use in Extrasys. For a well maintained list of UML tools refer to Wikipedia’s UML tools list.

Covering most of the diagrammatic needs of developers, UML may be used at all stages of the software development process – from requirements gathering to deployment, from structure visualisation to showing interactions between software elements.

Another important feature of the UML is its popularity in the software industry. Huge numbers of practitioners give another benefit – easiness in communication with your colleagues and clients. When a new person joins your team or when you are agreeing on functional requirements with your client, if they know UML you ‘speak’ the same language and it saves everyone time.

UML is also flexible in that it allows you to create diagrams at the level of abstraction you choose to be appropriate at the time, and if you have diagrams at different levels these may be linked together in a drill-down hierarchy of abstraction.

And last but not least, aside from being a very powerful communication tool the UML encourages automatic code generation from the model. It is available in most tools and for most languages. Some tools keep diagrams in synch with the code, applying reverse engineering techniques so code changes will be reflected on the diagram. This functionality is called round-trip engineering; and if you are shopping for a modelling tool this should be an important factor when making your decision.

I’ll write more about code generation and Model Driven Architecture, which is a hot topic among software architects, as and when I investigate the subject further.

Visual Modelling using UML

November 27, 2008

I have been using parts the Unified Modeling Language (UML) for a few years now but as a software developer I hadn’t encountered much more than class, interaction and, occasionally, state diagrams. So when I took an advanced Object Oriented Design course a few months ago, as part of my MSc degree studies, I was pleasantly surprised at the wide spread usage of UML in my fellow students’ organizations. UML has become a standard in the software development process – from requirements gathering to deployment.

Shortly after doing this course I had a perfect opportunity to use requirements modeling techniques in practice. One of our clients approached Extrasys with an informal written description (in email form) of their business processes and asked if we would be able to automate some of them. We decided to make use of the use case and activity diagrams from the UML toolkit to find out what they needed, prove that our understanding of the problem was right and test UML for gathering functional requirements.

And it went surprisingly well. Instead of a series of meetings with the client, which we usually need before agreeing on a formal written specification, we had just one. Use cases where great to visually describe the functionality needed. Work flows, which were not possible to include on use cases due to that diagram’s limitations, were shown on activity diagrams. Nice and simple. Easy to read, understand and spot issues with the model. On top of that when you have functionality broken down to coherent pieces it is a simple task to prioritize what is the most important functionality to deliver.

In the next post I will explain why UML is useful not only for requirements gathering but through the entire software development cycle.

DRM for the office

November 11, 2008

In October 2008 in leaked images from their upcoming Christmas Catalogue Woolworths revealed reduced pricing for the Microsoft Xbox 360, much below market price at the time for the gaming console. It was big news bearing in mind that it was 4 weeks before its publish date. Whether it was a marketing trick or a genuine mistake by a Woolworths employee we will never know. But naively assuming Woolworths didn’t want to make profit from ‘leaking’ it I asked myself a question – How can you prevent people from redistributing content they read on screen?

Film and music media companies have used Digital Rights Management (DRM) for years, but important business documents remain unprotected in most office environments today. People usually don’t watch movies or listen to music in the workplace but they do produce, send, receive, change and print documents, emails, spreadsheets and forms etc. There is, however, a Microsoft solution to this problem – Information Rights Management software to help you protect your content from being misused. It can prevent your Christmas catalogue from being printed before its publish date for example.

We are currently rolling out IRM as part of a SharePoint data room solution for an Extrasys client and I’ll write more on IRM in the coming weeks and months.