Doyenz: Cloud based disaster recovery

Robin Meehan just pointed me to an article in Information Week describing Doyenz Shadowcloud, an interesting product cloud-based disaster recovery solution.

Basically, the product allows SMEs to wire up the servers in their data centre so that they are incrementally backed up to the Doyenz cloud. When disaster strikes and your basement floods after a storm, you can restart your servers in the Doyenz cloud, getting back up and running as quickly as possible.

It’s an interesting proposition, particularly for tech savvy but lean SMEs out there who are maybe still relying on tape backups and insurance policies for their DR plans. How well it works, and how big this market is remains to be seen…

 

WebSphere CloudBurst: More details and musings

I’ve been at the IBM WebSphere User Group meeting in Edinburgh today, and attended a couple of sessions about IBM’s shiny new WebSphere CloudBurst Appliance.

For the un-initiated, the CloudBurst appliance is a hardware appliance which provides an easy means to deploy WebSphere products to virtualised infrastructure. We’ve written about this a couple of times before (first on 6th and again on 17th of July), so I won’t repeat it all over again.

Firstly, a bit of an update on one particular area which was confusing us here at Smart421 Towers. IBM WebSphere Application Server Hypervisor Edition is a version of WAS which is tuned for virtualised environments and pre-packaged into a VM image. Each image is 20 GB. Each of these images is encrypted and stored on the Cloudburst’s built in hard drive. These images can’t be stored on a LAN or SAN, so the maximum number of images you can store is limited by the size of the hard drive. So, let’s assume this thing has a hard drive that’s 500GB; that means the maximum number of images is 500/20=25 images, right? Wrong.

CloudBurst takes every image it owns, and cuts it into little pieces (I’m not sure on the official terminology, but I’ll call them shards), and then builds a manifest that describes how to put them back together again to make the image. When you create a new image (usually based on an existing one), the appliance analyses this image to work out what’s different between this image and the one it was based on. It then only needs to store the differences between this image and its parent. This way, the cloudburst can store a load more images than you’d otherwise expect. Almost certainly hundreds, I would suggest.

Talking about the appliance got me thinking. What are the use cases for this beast? It’s a serious piece of kit, and it has a significant cost; certainly enough that it needs justification.

The most likely short term use for it seems to be self-service access for creating new WebSphere development and test environments. The machine cannot yet be clustered (although I understand that’s coming in a future firmware release), nor can it create elastic environments that scale up and down on request, which makes it unlikely to be attractive for managing production environments right now. Delete production environment, create larger production environment doesn’t feel like a viable workaround to me.

Whether this business case makes sense will depend on the size of your organisation and how many WAS environments you create/destroy. Many organisations don’t do this that often, but that’s often for all the wrong reasons: It’s hard to create a new environment, so we piggy back on an existing one. Even so, environment build can be a major stumbling block, and if you don’t create a fresh environment for the project, you’re putting yourself at the mercy of the last bunch of cowboys who used it (unless, of course, that was you).

To help navigate this minefield, IBM have developed an ROI model for CloudBurst which can help you work out how much benefit you’re likely to get. Ultimately though, the proof of this particular pudding will be in the eating – if the business case stacks up, then fairly soon we’ll see adoption rise significantly, particularly among the large blue chip companies that make up Smart421’s customer base. When this happens, we’ll be there to help.

There are currently only two CloudBursts in the UK. We get to get our corporate grubby hands on one for the first time sometime in early November, and you can too. Drop us a line and we’ll put you in touch with the right people in IBM.

P.S. If you’d like to see a CloudBurst in action, check out the YouTube video.

 

Google Wave: Panacea or daydream?

I finally got around to watching the Google Wave developer preview video last night. I’m a great fan of any tool that helps people work better together. If you’ve not heard of Wave, or not had time to investigate, it feels to me like a hybrid of e-mail, instant messaging, Wikis and SubEthaEdit. Users can create new waves (documents/conversations/communications), make them available to others, and work on them. Wave manages to (surprisingly elegantly) bridge the gap between e-mail, instant messaging and wikis. When you edit a wave, the other person can see your changes as you make them, one character at a time. On the other hand, if they aren’t online, the next time they come back online, they’ll see your wave waiting for them. This is pretty difficult to describe, but beautiful to watch, and it scales. Watch the video to see what I mean, but suffice to say something which starts off feeling like an e-mail can transparently become a discussion and the reverse is just as true.

There’s no doubt in my mind that the technology involved is amazing, but from my perspective, the most interesting thing about the video is that it makes the scale of Google’s ambition clear. Google are pretty openly hinting that this thing could become a rival to, or even replace e-mail, IM, Wikis and a whole bunch of other collaboration approaches with a single unified solution. Read that sentence again. A replacement for e-mail; a protocol and metaphor for communication that’s been around in more or less its present form since 1982. That’s 27 years. 7 years before Tim Berners-Lee wrote his first proposal outlining the workings of the World Wide Web. Google are either seriously confident, or seriously arrogant. Or both.

But. They might just succeed. Unlike many other Web 2.0 services such as Twitter, Google are (at least outwardly) trying hard to ensure that Wave doesn’t become a walled garden. Even services such as Google Sites, which offer integration with the outside world using standard protocols (in the case of sites through HTML linking and RSS) don’t provide the same level of integration seen in the standardised protocols that support e-mail, IRC and other ‘old school’ services.

So, what makes Wave different? Google have built, and more importantly released to the public a protocol that allows any old Tom, Dick and Harry to create and implement a Wave server. Moreover, because the protocol is not trivial, Google have open sourced reference implementations of the protocol, and in the video suggest that they’re intending to open source the majority of the code-base of Google Wave itself so that competitors can download, tweak and run their own competing Wave services. These services will all federate, and make the experience broadly seamless regardless of which provider you choose to use. Like E-mail, USENET and IRC, information is only sent to the servers supporting users actively involved in the wave, opening the possibility of the (perhaps justifiably) paranoid running their own organisational Wave servers to ensure that content only leaves the corporate network when it is actively shared with a third party. This approach potentially eliminates a major barrier to adoption in the commercial world. Lastly, Wave provides support for Robots (intelligent agents) that can accomplish a multitude of tasks. Google demonstrated Robots that did things like integrating with Google’s blogger service and it seems clear this technology could be extended to support integration with existing communication mechanisms, and in particular the big threat: e-mail.

How this all pans out remains to be seen. Google are not an academic organisation, and they must deliver value for their shareholders, but it’s fair to say that they have a history of taking relatively large risks by taking on large scale projects with no obvious revenue model that would scare your average VC witless. Despite this, they’re still here, and still profitable. I think it’s reasonable to say that there’s an excellent chance that Wave the product will be a success. I’m much more sceptical about Wave the global infrastructure, due in part to the complexity of the technology and consequent barriers to entry for competitors, but mainly due to something much more human: Inertia.

Regardless of the success of the Wave platform, the debate Wave is likely to stimulate can only be a good thing. The Wave preview opens its doors on September 30 2009 to the next 100,000 users. I have my fingers crossed.

 

Can SOA governance technology be distracting?

In a recent post, David Linthicum asks “Can SOA governance technology be distracting?“. His answer is yes, and he offers the following sound advice:

First, only purchase SOA governance technology, if it’s indeed needed, after you have a complete semantic-, service-, and process-level understanding of the problem domain. Never before.

Amen to that. In my opinion, for all but the most mature and involved environments, the procurement of an SOA governance platform should be well down the list of priorities. I’d add to David’s list of things that need to be ‘worked out’ before you get that cheque book out:

• What is your vision for governance itself? Do you want to adopt a ‘iron fist’ or ‘hand in glove’ approach? Is your registry going to be a mechanism for governing or a side effect of it?
• Who’s going to populate it? Have you got your analysis, design and development processes sufficiently honed that your repository isn’t going to turn into a dumping ground of candidate services?
• Have you actually got any services live yet? Governance is a whole lifecycle thing. Until you’ve worked out how you’re going to deploy and manage services in the production environment and demonstrated that this works, how do you know what capabilities your governance platform needs to offer?
• Most importantly: What are the use cases for your governance platform? Can you demonstrate that these use cases can’t be addressed using your existing tooling (even if that’s Microsoft Excel)? Be honest with yourself about when you’re likely to implement these use cases. If the answer is further than one year away, then for the time, you might be wise to forget them. There is little point in spending good money on runtime governance or automated deployment technology when in a year’s time you’ll be able to get more for less.

A lot of projects using SOA governance tools at the moment treat them as glorified databases. If that’s where you’re at, consider using something less specialised that allows you to evolve your ideas, understanding and schema before you commit to something that will make this innovation harder and more time consuming. When you’ve spent six to twelve months getting your ducks in a row, so to speak, you’ll be in a much better place to make decisions.

I’d really welcome stories from people about how they’ve implemented governance platforms in the past, whether they’re informal (e.g. Wikis, bugtrackers, spreadsheets) or formal (e.g. IBM Websphere Registry and Repository, CentraSite from Software AG): What did you implement? What worked? What didn’t? What would you do differently next time?

 

Choosing an Open Source ‘ESB’ technology

I’m currently working to find the best Enterprise Service Bus for a project. Nothing unusual there. Something I’ve done a few times before. Except this time the requirements are a little more unusual than which kinds of transformation the tool supports.

Functional requirements:

1. The ESB must fit with Smart421’s SOA patterns.
2. The ESB need not be a one-box solution. We’re happy to mix and match tools around the outside. BPEL in particular is not necessarily a mandatory part of the core product.

On the face of it, not too tricky. In practice, maybe a little harder: In our view, the ESB isn’t a piece of software in the first place, it’s a collection of (continuously changing) standards and policies that govern the interactions that take place across the essentially empty void between two services, so we’re looking for something that’s compatible with that view, rather than something that wants to sit at the centre of the SOA universe (more on this later, perhaps). Let’s look at the non-functionals:

1. The ESB must be Open Source, be based on an Open Source product, or there must be an Open Source version available.
2. The ESB must have an established presence in the market – the latest and greatest features aren’t enough. We’re looking for something that has some industry buy-in.
3. It must be possible to buy in support for the product from a third party, should we need it.
4. The ESB must support light weight development. We must be convinced that easy things are easy achieve, and hard things are proportionally (and not disproportionately) harder.
5. The ESB must offer a non-functional envelope that allows it to support a large scale enterprise application, preferably without restricting us to vertical scaling.

I’m intending to follow a fairly standard product procurement process to help select the technology, so the next step is to set some more formal selection criteria and identify some candidate products to form the ESB core.

At the moment, the obvious candidates for me are:

• Mule
• OpenESB
• Apache ServiceMix + IONA Fuse
• JBoss ESB
• Apache Synapse + WSO2

I’ll keep you posted as I progress… Comments/suggestions/vitriol welcome!

 

Simulation Based Estimating

I’m sat on a train at the moment, from Norwich to Ipswich. This train will take 39 minutes to reach its destination. It’ll then take me 7.5 minutes to walk to the office, 1.3 minutes to make a coffee. I’ll be ready to work at 08:17:48. Obviously, I’ll stop to take a sip of coffee at 08:17:57, 08:18:20 & 08:18:50, and a large, cup emptying slurp at 08:19:20. Other than that though, it’ll be working straight through ’till 17:30:00. I will not get peckish and stop to raid the snack machine. There will be no interruptions. Nobody will, at short notice, book a meeting or pitch up at my desk for an impromptu chat about the current status of Project X or Initiative Y. My fiancé will not send me an SMS asking me to pick up a bottle of wine on the way home, and absolutely no recruitment consultants will call. All my days are like this. I never have a bad day, never fail to get my head around the task at hand first time, never struggle to think where to start. All my tasks are predictable, have well defined goals and require no assistance from anybody who might be having a bad day. Of course, in this environment, I deliver what I said would, when I said I would with 100% certainty, every time.

Of course, I’m dreaming.

The reality is that nothing about the average day of the average employee is in any way precise. My train might take 39 minutes, or it might take 41, or if I’m lucky and there’s a northerly wind, it might take 38 minutes and 59 seconds. My walk will be marred by traffic lights, and I (shock) will have bad days. If I were to use the fingers of every occupant of this rush hour train to count the number of times I’ve been asked by a project manager over the last 10 years “How long will this project take? How much will it cost?”, I’d probably have no more than two fingers left to type the remainder of this post.

The trouble is, you see, I don’t know.

Don’t get me wrong, I can estimate things as well as the next guy – it’s just counting widgets at the end of the day, but I know I’ll be wrong. Of course, project managers are reasonable people, they say things like “Well, we have to be 100% confident in this estimate, so we’ll add 10% contingency to your total, ok?” No. Not OK. The issue here isn’t that I under-estimate routinely (although that might well be an issue), it’s that adding ten percent will not make any estimate 100% confident, and nor will adding thirty, one hundred or even three hundred percent, regardless of how good an estimator I am.

Anyone who remembers the whale and bowl of petunias from Douglas Adams’ Hitch-hikers Guide to the Galaxy will remember that according to Adams, the sudden appearance of flora and fauna in deep space is unlikely, but none the less has a real finite probability. Perhaps somewhat shockingly, this sort of thing is a reasonably well accepted side effect of quantum mechanics; this could happen at any time in any place. You could be just tucking into a medium (sorry, Grandé) cappuccino at your local Starbucks when something, anything, appears. House, car, cat, dog, frog, you name it. Now, just to stop you panicking over your caffeinated beverages, the chances of this happening are infinitesimally small, but it serves to illustrate the point that you never know what might get in the way of your project.

So, finally, to the point of my post. I think it’s time estimating grew up a bit, and stopped pretending that it knew all the answers. What’s needed is a way of estimating the cost and duration of a project that softens the boundaries a bit, and gives a truer picture not of how long a project will take, but how long it might take. Imagine for a second that a programme manager knew that there was a 66% chance that the project would be in by Christmas, and a 88% chance it’d be in by June. He’d probably be much more likely to give the board a sensible message than if all he had was a vague message from you that it could conceivably be done before the turkey gets cold. Equally, those of us who sometimes work on fixed price contracts would have a much better way of assessing the risk of a given project, allowing us to reliably turn a profit while offering a good deal for the client.

It strikes me that there are two approaches that could be taken to this:

• Use probability theory to attach a probability distribution to every input parameter in the estimating model, and then carry these through the model and give a final probability distribution at the end. Complex, nasty, not much fun unless you have a PHD in applied statistics.
• Make the input parameters to the model fuzzy (more on what I mean by this later) and then run the estimating model over and over again, collect all the answers and build a histogram (chart) out of the results.

I’ve thought long and hard about this over the last few years, and frankly the former option is beyond the capability of my AS-level statistics. Even if it wasn’t though, I’d be recommending the latter, and here’s why: It’s intuitive. What you’re doing is running the project over and over again, and seeing how long it takes. Project leaders can be old and wise without being old and wise; they’ve already done this project 1000 times (albeit in the mind of a machine), so they’ve got a good idea how long it might take.

Using this approach, you could build absolutely anything into your model; Productive day averages 6 hours, but varies between 2 and 20 hours on occasion? Sorted. 0.04% chance of aliens abducting your senior developer? No problem, at least for the project. The options are endless.

Nicer still, because this approach uses simulation rather than algebra, we don’t need to be too anal about how the parameters are set. If it’s easier to say “95% of the time it’ll take 5 hours, but 5% of the time it’ll take a random value between 8 and 10 hours”, then that’s fine. We don’t have to put together some strange combination of probability distributions that models this; we just run with it. Equally, if you have a set of example data to use as a basis (well, this system has N classes, and it took X long), then these values could be used directly, without having to build a complex model from them first. That said, if the guys doing the estimating do understand probability, then they can use a Poisson distribution to determine how many use cases will be delivered by a week next Friday if they so desire.

Equally, because we’re actually running the project, we can apply all sorts of interesting things to the model that would be impossible using a purely statistics driven approach. For example, in an agile project, we can simulate the team size and length of sprints against the simulated sizes of the products to determine the optimum length of a sprint for the project. We could simulate the quality of deliverables based on whether code reviews are expected, and use this to estimate the impact on the length of the test cycle. Obviously, this stuff is a bit trickier to achieve than answering the usual how long/how much question, but it’s always good to know there’s scope to develop things further in the future.

The architecture underlying this kind of estimating machine is pretty trivial. I’d say, with 100% certainty, you could deliver the underlying engine in 27 hours, 5 minutes. Elephants and petunias not withstanding.

 

บ้าน (home)

I crawled into bed at 1am last night, no less than 25 hours after getting up. Paradoxically, I only got up at 7am. Aren’t time zones wonderful? I’ve just got back from a business trip to Bangkok and thought I’d post some lessons learnt. In no particular order:

• The weather in Bangkok is hot. Wear short-sleeved shirts. Don’t wear ties. Wear a suit jacket when you go out in the evening, you’ll look like an idiot. And I did.
• Don’t cross roads until you’ve looked left, right, up, down and have resolved any outstanding issues with your life insurance.
• When you enter your airport taxi, note that it will take exactly 27 minutes before you realise you are not about to die. It’ll take another three minutes before you take your hands away from your eyes long enough to notice that none of the cars weaving between lanes have dents, and decide that they are clearly made of reenforced diamond. Or decide that Thai drivers are considerably more talented than you, I or Jeremy Clarkson. Yes, really.
• The people in Thailand are friendly, polite, and remarkably tolerant of our lack of aptitude for their language. Say “thank you” using the feminine version of the phrase for three days, just to keep them amused. We did.
• You’ve not seen value for money until you’ve been to Bangkok. Stay in a hotel room as big as your house for £70 per night. Spend 45 minutes watching the meter in a cab slowly reach the £2 mark. Now try doing the same in Farringdon.
• Towers in Bangkok are tall and numerous. Ours had 38 floors. Take pleasure as the high-speed lifts make your ears pop. Bring sweets. Yawn liberally.
• The Starbucks franchise covers all corners of the earth. I strongly suspect they have spread to all nearby star systems.
• Jet lag is a killer. As is the dawning realisation on your exit from Heathrow airport that the English weather is, frankly, rubbish.

More seriously, spending a few days talking to these guys taught us a thing or two about how to communicate with people when you don’t speak their language:

• Don’t underestimate the people you’re talking to – remember the issue is one of communication, not capability.
• Explain things in simple, but not patronising terms – using colloquialisms or slang won’t help. Remember that some phrases that are in common usage in the UK might well not translate: We spent two days using the word ‘business partner’ before realising that this had been misunderstood.
• Use diagrams. “A picture is worth a thousand words” has never been truer.
• Give it time: You might find you need to explore new ways to explain things in order to hit the right buttons. Talk around the subject a bit, go back to basics, find the hooks in their heads that will allow them to understand.
• Find time to swap stories and compare cultures. Not only will this build rapport, but it’ll help you to understand where your audience is coming from and what drives them.
• Solicit feedback and encourage questions; you’ll get a far better picture of your audience’s level of understanding by allowing them to challenge and push back than you will by blindly blithering on at them for days on end.