Thursday, June 2, 2011

Without a Net(work)

Synergy Day 1.  Mark just finished evolving us from the PC to the Cloud-era and now it's demo time! We were so excited to be introducing everyone to our personal cloud vision.  The audience was leaning forward in their seats with anticipation.  As the "official Synergy keynote blogger" I was holding my breath and waiting...and waiting.  And then froze.  What do I type next?

Demo #failed because we lost wireless? Or:

Yikes peeps, the wireless network is flooded and the demo failed!  That should loosely translate to---the wolfhound ate my homework.


It seemed like a lame excuse. And granted, we're all programmed to get a wee bit nervous when a demo that worked brilliantly in the dry-run, suddenly has a problem when the whole industry is watching. Trust me, I certainly felt this real-time while thinking about my next sentence.

Then I saw a tweet come through: Watching Demos at tech shows are like watching Nascar; deep down, you really only want to see a crash. #citrixsynergy


Well,  #Schadenfreude to you too buddy.

Of course, our incredibly composed CEO and Chief Demo Officer went on with the show until they got to another demo.  The wireless still wasn't fixed.

So, you may be wondering...whose head is going to roll?  Surely someone is in serious deep merde over this?


Well, the answer is no one.  We have always been adamant about showing how it all works without the smoke and mirrors - or even a back-up network.  As Mark said in his keynote, "There's no wire in the clouds."

Most companies in this industry build all sorts of failsafe backups into their big stage demos - e.g. flash recordings, backup systems that get switched on seamlessly from behind the curtain if the primary system fails...

We don't do this. Everything people see on stage is real.

Do we feel bad when we can't do a planned demo because 6,000 customers are flooding the wireless airspace? Of course!  But would we change it? Is it what our customers would want?

I know some would argue that's foolhardy---because isn't showing how the technology works more important than doing something without a net?   For Citrix, it's akin to the sizzle without the steak.
The fact that we don't fake it is one of the key things that makes us different. Said another way, "no lip-syncing!" When you come to Citrix Synergy, you're getting Train (literally!) not Britney Spears. Does that mean we sometimes go off script, and it doesn't always sound exactly like the studio recording? Yes. But given the auto-tuned alternative, we think our customers prefer it that way because it's how they work in the real world.

HBR just dedicated their April issue to what we can learn from failure and in it, Peter Guber, head of Mandalay Entertainment said: I make movies and I own sports teams; those are two things you can't do without a significant amount of failure. And public failure at that. Not every movie you make will succeed; every sports team eventually loses. If you're not willing to confront failure, you'll become risk-averse. And if you're risk-averse, you're doomed to fail and get stuck there. Failure has been my handmaiden on the road to success.


For Citrix, Being risk-adverse is not in our DNA.  Failure is something we do and then get over quickly.  You don't get fired for failing at Citrix---although you might find your way out for not taking risks.  Authenticity is core to our culture.  It's not just idealistic lip-service - it's actually something we deliberately factor into how we hire, develop and promote employees.

Don't get me wrong.  It would be rather disingenuous not to point out that much of what we do assumes connectivity to the Internet.  But our vision does not depend on this. That's the point of things like XenClient, app streaming, and Follow-Me-Data. If you're in a situation that's always connected, great. If not, our vision increasingly allows for that too. A world where people can work or play from anywhere includes places and times when you can't connect.

At the end of the week, the real value for our attendees centered around a connection with people---the healthy debate and discussion that took place throughout the conference, in the technical sessions, GeekSpeak and the hands-on learning labs.

Ultimately, it's about what happens once our customers leave San Francisco bringing what they've learned back into their own enterprises.  For them, it's about creating better ways for people and IT to work.

For us, that's the real net.

By: Kristin Taylor

Wednesday, June 1, 2011

Xen celebrates the final step of a four year odyssey

The Xen team celebrated the final touch to over four years of work last week, when Linus Torvalds pulled xen-blkback into the Linux mainline tree. This tiny move has great consequences, because it means that the next release of Linux – Linux 3.0 as we found out yesterday – will have everything necessary to run as both as a management domain and as a Xen guest.

It's been a long journey from USENIX 2006, when IBM, VMware, Red Hat and Citrix first discussed the paravirt-ops interface. Since then, a tiny team of engineers has worked tirelessly with the Linux community, bringing new features every few weeks into the kernel, enabling first guest support, and then feature after feature towards complete control domain support. This work is now complete, and what a way to celebrate Linux 3.0!

I met Jeremy Fitzhardinge last week, architect of this epic slog, and instead of the haggard shell that I expected, I found him as bouncy and cheerful as always. I asked him how he'd survived, and he explained the debt that we all owe to Konrad Rzeszutek Wilk at Oracle, for shouldering the burden of the upstreaming effort recently. So thank you and congratulations Konrad, and Jeremy, and while I'm at it, to Ian Campbell, Stefano Stabellini, and the other people who leant their time and strength to the cause.

I was going to use this blog post to describe the history behind this in a bit more detail, but Wim Coekaerts beat me to it. Go read his post if you want to hear about the past, and I will instead talk a bit about the future.

This upstreaming is so important because it means that there is no longer any need for distros to carry different kernels for their Xen support. This is great, because it greatly reduces the burden of Xen support. One single kernel means no more Xen patches to maintain, no more forward porting, and no need for separate kernel packages. For Debian in particular – who's maintainers are all volunteers of course – this should make supporting Xen a lot easier, and will help the XCP team in their drive to make "apt-get install xapi" a reality on Debian and Ubuntu.

And once you've done all of that, you can have OpenStack on Xen on Debian and Ubuntu. And that's what makes all of this hard work worth celebrating.

By: Ewan Mellor