|
Desktop Virtualization: Not Quite Ready for Prime Time |
|
Written by Eric Novikoff
|
|
Here at ENKI, I'm one of the few people who uses Windows for
my daily work, since I communicate a lot with customers and have to be able to prepare
documents for them as well as for our website.
Because our services have until now been delivered largely on Linux, I'm
the object of constant teasing about my attachment to Windows. So when my computer started to go on the
fritz, I purchased a new computer and decided to investigate moving to Linux
and running my legacy Windows applications in a desktop virtualization
environment while I figured out how to divorce myself from them. Being that I need my computer for work, I
decided to limit the amount of time I spent trying this out to a couple weeks'
worth of evenings. Despite that, it
turned out to be quite a saga! I ended up discovering that desktop virtualization isn't quite ready for prime time, at least on a Linux host environment. You can read the details below...
My first task was to choose a distribution of Linux to
use. I started by trying out Ubuntu,
since I'd never used it before. I'm also
familiar with PCLinuxOS, which we have on some of our laptops here, and is one of our customers. Both are easy to set up and get working, and
have great support through their forums, but each one failed to support the
silent operation features of my new computer (fan control and the automatic
processor clock scaling.) I'm sure with
enough tweaking I could have made it work, but since I was trying to replace
Windows, I decided to go for a supported Linux solution. I picked SUSE Linux Enterprise 10/SP1, which you can
purchase with support from Novell. Novell
sells SLED10 as a replacement for Windows, claiming that it is usable right out
of the box for office applications. SUSE
installs easily, has a lot of Windows-like features built in (including the
popular open source desktop suite, Open Office) and is easily configurable in
the installer or control panel, similar to Windows. SLED10 also supports Xen-based desktop
virtualization out of the box with easy configuration and no additional cost. We use Xen here at ENKI to deliver our
virtual private data centers and it's a rock-solid, reliable virtualization
environment that I can trust. Unfortunately, SLED10 didn't support my PC's
power management because the hardware drivers in it were too old. I could update them, but then I wouldn't get
support - and some of SLED10's modules were dependent on the old drivers! I'm hoping SP2, coming in a few months, will
solve that problem. I liked SUSE so much
that I tried the free SUSE Linux 10.3, since Novell sells support for it as
well. I was able to get the power
management to work, but I couldn't get the
promised support because the call center in Ireland is only available from 1am
to 9am PST, which didn't do me a lot of good.
However, once I tried to get the Xen-based virtualization
running on SUSE Linux 10.3 and install Windows, I ran into a showstopper. The Nvidia and ATI drivers for Linux do not
support Xen. As a result, you're forced
to run Linux with a VGA driver that keeps you from using all the incredible
whizzy graphical desktop managers as well as any graphics-intensive
programs, slowing screen updates to a crawl. I spoke with the development
manager for Nvidia's desktop graphics processors last week, and he's aware of
the problem and told me that his team is working on it. But I
wasn't quite ready to give up on Linux yet, for two reasonse: Compiz-fusion,
the graphical desktop manager in SUSE Linux (and other distros) is so amazing
and beautiful that both Apple and Microsoft have years of work to catch up - I was totally captivated by it! Also, Linux's easily downloadable repository
of thousands of instantly usable and free applications is a big draw. So I decided to give Linux another try by using
VMWare virtualization instead of Xen.
I downloaded the free trial of VMWare Workstation, and
installed a copy of Windows XP on it. I
ran through the lengthy Windows update process, installed my applications, and
finally ran the files and settings transfer wizard to move my personalization
and files from my old computer into Windows on VMWare. But I ran into trouble right away: despite the fact that I've moved from a
2.2GHz Athlon 64 computer to a 3 GHz Core 2 Duo, Windows ran about 1/3 as fast
in VMWare as it did on the old computer.
A lot of digging around on the VMWare forums found some bugs that were 2
versions old, which keep VMWare from scheduling multiple CPUs correctly. So I turned the number of CPUs that VMWare
supports down to 1, and suddenly Windows was as fast in my virtual environment
as it was on my old computer. Next, I
tried to install Adobe CS2 into my virtual Windows, and ran into another
problem: VMWare "lost contact" with the CD-ROM drive after the first install
disk and the install failed. Back I went
to the forums, where I discovered
another 2-version-old bug and a workaround that allowed me to install CS2. But the problems kept on coming, including
display problems that kept me from controlling the virtual machine successfully
and forced a reboot of Linux; problems reliably mounting the host's file system
to exchange files between Windows and Linux; inability to use USB keys successfully;
VMWare mouse drivers that blocked XP from recognizing my trackball, and on and
on. After finding all these long-neglected
bugs in VMWare's knowledge base, as well as suffering disappointing performance, I came to the conclusion that I didn't want to
pay about $200 to VMWare on top of $150 to Microsoft, only to end up with an
environment that was going to be more problematic than the scary comments I'd
ready about Windows Vista. In the
process, I also realized that I'd have to think very carefully about basing
end-customer services on VMWare as well, since the sheer volume of long-term
unrepaired bugs that I ran into was pretty daunting.
So, it's clear that desktop virtualization isn't quite ready
for prime time, despite VMWare's assurances and advertisements to the
contrary. I'd love to try Xen on the
desktop, but due to lack of video driver support, that's not quite ready
either.
There actually is an alternative that eliminates the need
for Xen or VMWare virtualization at all.
It's called Wine, and it's a Windows emulator. It's even commercially supported by
CodeWeavers as a product called "CrossOver Linux" CodeWeavers has a compatibility database for
Windows applications. Unfortunately, the
ones I use most often - Outlook, Photoshop, and Illustrator - don't have 100%
compatibility yet. I've heard good
things about Wine on the Linux forums, and recently read an announcement from
Adobe saying that they'd work on versions of their software that worked in WINE,
so the future looks bright for it.
In the end, I decided to postpone the move to Linux on my
desktop and installed Vista on my PC. It
wasn't without problems, including - surprisingly - no driver for my favorite
Kensington track ball, but in general it was painless and I'm very satisfied
with the speed and improvements in Vista.
But I miss the beautiful Linux desktop!
|
|
What I learned about Courage and good vendors |
|
Written by Eric Novikoff
|
|
Over the last couple years that we've been growing ENKI, we've seen
how important it is for us to pick vendors that we're really excited
about doing business with - vendors we can see as partners in our
business that help it grow. As a small business, our partners have a
huge effect on our business and the overall impression we can make on our clients,
so picking good ones is critical for us. I was talking to Dave about
this at lunch the other day and we realized there's a pattern to good
and bad vendors that we could see early on and would help us pick
partners that naturally fit in with our win/win business approach in
the future.
First of all, I'm not going to name many names
here - that's not the point. But if I rave about a vendor, you can
take that as a recommendation :) The best vendors are ones where there
isn't any drama in our relationship: we can trust them to deliver their
product or service and we never feel betrayed or taken advantage of by
them, nor do we feel we have to keep asking (or begging) for some sort
of change in our relationship in order to run our business. We can
always enthusiastically recommend them. The worst vendors keep us
constantly looking out for a replacement vendor, or wishing we could
because we're locked in to a relationship that we can't easily
extricate ourselves from. It's hard to recommend them to others.
Unfortunately, despite our best efforts so far, the majority of our
vendors fall into the group which we'd have trouble recommending. (If
you read my Small Business CRM Challenge blog articles, you can see how
frustrating this can be.)
So by now you're probably wondering what the patterns are that
we've seen, and how you can use them to pick your vendors. The
strongest and most determining pattern seems to be where the vendor
lies on the scale of expedience versus complacency. Both states seem
to stem from their views of their own financial success. The
expedient vendors will put on a happy face and say what it takes to get
your business, since they are on the financial edge and need business
badly to stay afloat. In their mind, doing anything for the sale is
justified, but you rapidly become cynical of their promises since they
can't live up to them - often because they're just too strapped to do
so. Just as troubling are the complacent ones, who have a history of
success or a lock-in business model and think they're entitled to your
business as a result, without working to earn it. These vendors betray
your trust by acting unilaterally in their own interest, since they
think they're the only game in town.
So how do you see these
patterns in advance? In my experience, the expedient vendors are
visible up-front because they offer large discounts or a complex
pricing structure with lots of add-on packages that obscure the final
cost to you behind a low buy-in price. In other words, they're
thinking, "just sign the contract!!!" The complacent vendors are more
difficult to spot: you'll probably need to do some research on their
existing customer base, perhaps by searching online discusion groups.
One telltale is a high buy-in price or inflexibility in negotiating a
contract. They're thinking, "we're the only game in town." It's not
always easy to see these patterns, but I'm learning to be a more
feel-my-way-through-it kind of guy and if I feel cynical or betrayed in
my initial contacts with the vendor, I stay away, since these feelings
are harbingers of what is to come. What's going on here in either case
is that the vendor or their
representative is avoiding some sort of humiliating experience of loss
by the way they're dealing with you - and that's a powerful motivator
to keep on practicing this dysfunctional behavior. So the ultimate
thing to look out for is loss-focus (or its littermate, gain-focus.)
What about the opposite - a vendor you can't say enough good
things about? If I'm to believe my own analysis, these are vendors who
are neither complacent nor expedient. What does that look like? I
thought about this for a long time and realized it meant that the
preoccupation with the humiliation of loss isn't foremost in their
minds. They're having fun, they're passionate about their work and
product, and they're connected to their source of internal strength and
resources rather than in a relationship of dependence with their
customers. The one word I could think of to describe this was
"Courage." Good vendors exemplify courage. I know this sounds like
one of those kitschy motivational posters you sometimes see in
executive offices, but there's some truth to it. If your vendor is
courageous, they aren't focused on milking your business like a cow,
but rather building a partnership that benefits both parties: a win/win
relationship. The relationship stops being about them and how they can
survive, and starts being about exploring success together because
business is about drawing on each others' strengths. This aligns with
the practices that most highly successful executives embody.
OK, so how do you recognize a courageous vendor? In my experience, they're willing to listen and then act
on that listening - not just look like they're acting. This takes a lot
of humility - knowing that you don't have all the answers - and that's
rare. In our lives, we usually get humility from humiliation and given
that we spend most of our time avoiding it, it's a dearly-learned
state!
Lately, businesses have realized that looking like you're listening
is important, and have created customer relationship management
systems, customer surveys, and customer service agents dripping with
faux humility to give the impression they listen. Don't get me wrong:
these are good practices, but they have to be backed up with the
courage to truly listen and act. As a small or medium-sized business
principal, you know the value of relationships. So it pays to create a
personal relationship up-front and see if your vendor is listening.
I
had an experience this week with a vendor I already am enthusiastic
about: Kerio Technologies. Their product just works, and is easy to
use. Their support is effective and doesn't waste your time. Their
pricing is reasonable and easy to understand. We went to their offices
to talk about sales synergies and while we were standing in the hall,
their CEO, Scott Schreiman, walked by on his way to get a soda. He
stopped, and listened. Really listened. And then he asked us
into a conference room to listen some more, without making our time
together about him or his company. He wasn't selling or trying to get
rid of us, even though we're a small customer of his. He was relaxed
and open to what was transpiring. It just reinforced my desire to do
more business with his company. I know that whatever partnership I
create with him, even if it isn't working at the time, will be able to
move forward because of that orientation to listen.
Finally, my
personal observation is that Gandhi's famous words, "Be the change you
want to see in the world," still apply more than ever to your business
dealings. If you can be courageous, you'll attract similar partners to
yourself since you will all know what's important in a relationship.
|
|
|
Making Efficient Use of Cloud Computing Resources - Part I |
|
Written by Eric Novikoff
|
Introduction
In response to requests from customers, I'm going to start a series of
irregular blog articles on making the most efficient use of cloud
computing resources, such as those provided by ENKI's Computing
Utility. I will use examples from our customer base, as well as from
the storehouse of experience the staff at ENKI have from working at
start-up and enterprise companies.
Ultimately, making efficient use of resources in the Cloud, where
computing resources are utility-billed, is very similar to simply
dotting your Is and crossing your Ts with respect to efficiency in in
any computing environment: you want to use your allocated resources as effectively as possible. But there are also some interesting new
problems and opportunities that come with being able to resize or re-allocate your
computing resources on demand. Today I am going to write about bursty
loads, such as those involved with media transcoding, image processing,
and database-intensive tasks.
Many of the applications I created in the past, and those of customers
who come to ENKI, are developed and possibly deployed on fixed hardware
such as a PC under their desk, or a physical server in a data center.
In this case, the hardware is typically dedicated to the application
and runs all parts (or tiers) of the application. If the application
is too slow, the choices are to improve the efficiency of the code
(which Dave wrote about in
Data Center Power Consumption, Part III: The software), buy a bigger server, or split the
application into parts, each running on a different server. With
ENKI's Computing Utility service, you can increase the size of your
server on demand, but it won't increase the efficiency of your
application, only your monthly bill! Splitting the application is
where you can get some big efficiency gains from utility computing.
Before we dig into the numbers, please remember that this discussion
involves a tradeoff between the cost of the computing service and the
user experience. If you make the wrong choices, you may no longer have a business to optimize!
A bursty batch processing example
Let's take a look at a sample application which transcodes stored video
files into a customer-selected format for download. We will start by
assuming that a standard server can process 1000 videos an hour. If
you deploy this server to transcode a video when a user requests it,
the user would have to wait (60*60/1000) = 3.6 seconds to be able to
start downloading it, which is not a problem. Suppose we deploy the
application this way and observe how the users use it. For most of the
day, requests come in once a minute on the average, which means that
our server is only at 6% utilization. However, in the evenings, there
are peaks where users are submitting a request about once every 2 seconds for
periods of up to 15 minutes. In this case, after 15 minutes, the last
requestor has to wait for their video an amount of time equal to the
number of backlogged requests submitted times the processing backlog on
each video: 15*30*(3.6-2) = 720 seconds or 12 minutes.
Whether
this 12 minute delay is a problem for your business or not depends on
how you set your users' expectations. If they have to sit and watch a
spinning film reel, they'll go away and not come back. If you tell
them you'll send them an email when their processing job is ready to
download, they will most likely accept that. The very successful
(until the RIAA killed it) music download service, AllofMP3, allowed
you to transcode your music this way, and their customers were
delighted. Similarly, NetSuite submits long-running reports for background execution, notifying you when they are complete.
So, how can we change the deployment of this
application to save you money during most of the day when your server
is only being used at 6%? The trick is to move the transcoding to a
separate virtual machine instance (called an "Appliance" at ENKI) which
is dedicated to processing only the transcoding tasks, and implementing
a processing queue to allow the instance to manage its backlog. You
can then set the amount of CPU allocated to the instance to control
your maximum queue length at peak periods. A side benefit of doing this is that you can reduce the resources allocated to the Appliance with the remaining tasks in your application (UI, downloading, etc.) because it no longer has to process transcoding jobs quickly.
For example, if you
chose to set your CPU allocation to 12% of one standard CPU for your
queue processing Appliance, your processing time for one video would
increase to (1/0.12)*3.6 or 30 seconds. In this case, using the math
above, users would have to wait a maximum of 210 minutes at a peak usage time. However,
most of the day their wait would be 30 seconds. In return for this
increased delay, you save 88% on your resource charges. You could even look at the queue length and offer them the option of waiting or getting an email when it was done if they had to wait longer than 30 seconds.
Making the cost vs. speed tradeoff
This is a
tradeoff that you will have to make based on the best information you
have about your business. You need to know what kind of user experience is
required for your business to succeed before you can analyze
performance numbers. You may want to conduct a focus group or user feedback study. There may be automatic ways to check if performance is unacceptable, such as correlating abandoned sessions to changes in resource allocation, for example. If you are an internet startup company or an internal IT department rolling out a new application, you only have one chance to make a first impression, so it's probably wise to start with a generous allocation and reduce it over time while checking back with your users to make sure they aren't too frustrated. However, by setting the users'
expectations correctly, such as with the email-on-completion method listed above, you can take a lot of pressure off of your
application.
In the next article, I'll write about another technique for making efficient use of utility-billed computing, which is varying the breadth (the parallelism) of your application as deployed in the Cloud in response to increasing load.
|
|
|
How Cloud Computing can make the Long Tail profitable in the SaaS business |
|
Written by Eric Novikoff
|
|
There's been a lot written about Cloud Computing being the wave of the future, but here at ENKI we're seeing that it can save our customers big money right now and enable them to sign a larger number of profitable deals. We're seeing an increasing number of SaaS (Software as a Service) companies interested in our Computing Utility service, many of whom offer middleware services like data translation, data communications services, or data aggregation and reporting. They sell their software as a service to end customers. Most of them have large customers, so their typical sales cycle has been:
- Sell and sign the business
- Engage their professional services and IT departments to build out their own data center or a new data center for the customer
- Set up the application software on the new new data center
- Activate the software and deliver it to the end customer
This has worked well for them, so they haven't been too focused on cost or time to market; but as you can see provisioning a data center or adding significantly to one can take weeks to months, and involve a great deal of labor and capital costs. However, they have been unable to profitably address smaller end customers: imagine using the process above if all you need is a one and a quarter server's worth of computing power! So, they were focusing on a few larger deals and leaving the many smaller deals on the table (the infamous "Long Tail", named for the asymptotically dropping curve of price versus quantity of customers.) And now, with the economy slowing, this ponderous process is beginning to look too expensive to SaaS providers, even when they provision an application for a large customer, due to the large capital outlays required to sign business that might not be around long enough to pay off the data center.
However, using our pay-as-you-go cloud computing technology based on AppLogic, ENKI can reduce the sales cycle for SaaS to look like the following:
- Sell and sign the business OR use a portal where the customer can sign up and pay via self-service
- Automatically provision a new copy of the application in a virtual data center sized to the customer's needs
- Automatically activate the software and deliver it to the end customer
By eliminating manual steps including hardware and software provisioning, the turnaround on the sales cycle drops from months to as little as minutes. Also, the cost - both of the sales cycle and of provisioning the resources - drops dramatically due to the reduced labor component and the fact that resources are allocated without waste (no extra capacity is needed to provide for future growth or redundancy for reliability!) This allows SaaS providers to profitably sign customers in the Long Tail and greatly increase their market.
I've found that the biggest obstacles they encounter in switching to cloud computing are internal resistance from departments who are used to doing things the old way, and switching their financial models from lump-sum expenditures to flow-through cash-basis, often paid with credit cards or ACH rather than invoice and check. But this is a small price to pay for increasing your market penetration and profits.
If you'd like to learn more about cloud computing, there's an excellent summary in a blog article here.
|
|
|
|
<< Start < Prev 1 2 3 Next > End >>
|
| Results 13 - 24 of 35 |