Hyper-V – Reducing the cost of your BizTalk 2009 farm – really?

IMG_1949

Interesting post on Nick Happleston’s blog entitled: Hyper-V Dramatically Lowers the Price Point for BizTalk 2009 which talks about how Microsoft’s virtualisation technology enables enterprises to deploy BizTalk in a cheaper configuration. It makes reference to Chris Romp’s blog entry BizTalk Server 2006 R2 Hyper-V Guide, but applies the same principles to BizTalk 2009.

My only issue with the cost reduction is that it revolves around the fact that BizTalk is licensed based on the number of physical processors on the box it’s running on. Based on this assumption, you can have a box running Hyper-V where you pay for 2 processors regardless of how many BizTalk boxes are deployed on it. You can therefore double or quadruple the size of your BizTalk farm without incurring additional license fees. The theory is sound, but although the BizTalk roadmap talks about the features of the new version, but doesn’t go into details on licensing implications of the new version. Also, I have one fundamental issue with it.

The question that needs to be asked is “Why are you scaling your BizTalk farm?” If you’re doing it because of performance implications, than 4 virtual BizTalk boxes aren’t going to run any quicker than 2 virtual BizTalk boxes on the same hardware. If you’re doing it because of logical groupings within your application, then you’re not using BizTalk Groups correctly (this is a feature that allows you to deploy different BizTalk applications across multiple servers). You’re certainly not doing it for resilience as you’re running on the same hardware regardless.

So, interesting post; but not quite sure I see the point.

2 comments

  1. Owen – I hear you.
    Let me put it in some context.

    Virtualisation – you can slice and dice your cores, RAM + disk allocated to each VM.

    BTS09 running on W2K8 Hyper-V performs on ‘average’ between 80-95% (MS findings 🙂 of the physical h/w underneath. Which is not bad at all.

    For e.g. A client needs to implement a BTS farm (redundancy is important) so they’re up for at least 2 ent. lic. using the traditional method – when given they are just breaking into the bts world.

    “Show me it working…” is their current mindset.

    Getting 1 ent. lic. and being able to spin up unlimited bts VMs on the one physical machine – makes perfect sense for them…for now. At a later date – they have all the bts infrastructure to spin up a new box, and move a bts vm over there (thus incurring an additional license cost then, not now)

    Given you can get h/w redundancy built into many boxes these days (e.g. psu, nics, RAM etc) a ‘failure’ isn’t as bad as it was.

    Going many core cpus (in my experience) has outperformed many cpus fewer cores.

    So from a MS perspective (I can see what they’re trying to do), they reduce the price tag of BTS while giving you much of the same functionality ‘virtually’ – easing the USD$40K price tag.

    Note: From the field – it’s OK to virtual bts, but not too performant to virtualise SQL.

    HTH,

    Mick.

  2. @Mick: Thanks for your comment. I guess it’s all about giving users options around how their deploy their architecture.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.