This may come as a surprise to you, but if your website uses cookies to validate its users, then anyone accessing it over public wifi can easily have their identity hijacked.  A Firefox plugin called FireSheep allows anyone in range of your users to see that they're logged in and take over their identity.   This actually applies to applications like Facebook and Twitter, in case you think this is a obscure corner case.   The next time you try to use one of them in a cafe,  you'll be looking over your shoulder...

Most sites collect password information via HTTPS, however they then switch back to HTTP for further interaction, after they place an identifier cookie on your computer.  It's this cookie that FireSheep grabs, allowing the user to impersonate someone else.   The only solution is to encrypt your entire session - yes, all pages - via HTTPS.

In the past this has required expensive dedicated hardware such as encrypting load balancers or front-end servers sized to handle the encryption load.  For cloud deployments, it meant going to a provider that offered the encryption hardware, or paying a lot extra to run your encrypting load balancer hardware - or so everyone thought.   At the recent VMWorld and Oracle OpenWorld conferences, I was lectured by equipment makers such as F5 that their hardware was absolutely essential to handle encryption loads in our cloud service, and that otherwise customers would experience slowdowns or even network failure.

A good story for the hardware vendors, however Google has done some experiments and found that the extra compute power needed for SSL is negligible!    This is a combination of improvements to OpenSSL as well as updates to processor hardware over the last few years.

What this means is that you can take advantage of the flexibility of a software load balancer like HAProxy, content caching with Squid, or your favorite software firewall in building your own fully virtual private datacenter in the cloud without paying - literally - for the privelege.    It also validates ENKI's all-virtual approach to datacenters, which VMWare is embracing as well with VCloud Director, on which PrimaCloud is based.

One of the most often-asked questions of our sales people during the sales process is "What is your pricing?"   However, simply answering the question doesn't seem to satisfy most of our potential customers.  Some customers are quite satisfied with simply comparing the cost per hour of CPU, but most realize very quickly that the actual computing resources you are purchasing for those pennies per hour varies so much that the price is almost irrelevant.

First of all, there is an alphabet soup of units of computing resources that various vendors offer, including compute cycles, Ghz (gigahertz), cores, ECUs, instance-hours, RAM Gbyte-hours, and the list goes on.  Comparing them is almost impossible since, even if you fully understand what they mean, you still don't know how much computing speed you're going to get.

While I cover this in more detail in my Cloud 101 class, the essential reality is that you're using a portion of a computer that has real RAM and real CPU that you are being allocated.  Since the cloud vendor wants to monetize all their hardware, they will try to sell you resources  (RAM and CPU, sometimes networking and storate) in the same ratio as their computers contain.  For example, if their computers are built with 2 6-core processors and 96GB of RAM, you will most likely be offered some kind of computing with 8GB of RAM per core.   

But what is RAM and what is CPU... and even worse, what if they aren't specified, or an obtuse unit like "cycles" is used instead?   For CPU, a GHz can have radically different performance depending on processor architecture and how much RAM is attached to the processor (since more RAM slows communication speed to the CPU).  If quoted in "cores", those cores could range from 1GHz to over 3GHz, which when you take into account different architectures could represent 5x difference in performance!

Unfortunately, where there's smoke there's fire, and I've never seen vaguely or confusingly quoted resource allocations that don't also end up cutting corners in your resource allocation, to the benefit of the cloud vendor.  Some cloud vendors have a long lineage as mass hosting companies and have 20+ years of experience ekeing the maximum number of customers out of their colocation or shared hosting services, and follow the same philosophy with their cloud offerings.   This can include quoting maximums when over-allocating memory or CPU such that your application only gets the quoted amount in short bursts.   Virtualization frameworks such as Xen or VMWare offer the ability to over-allocate resources, which can result in inflated specifications.   Now, don't get me wrong: there's nothing wrong with over-allocation to reduce prices, but you must also be prepared to accept that you can't compare such specifications to other vendors AND you will probably get performance that is only suitable for hosting small web sites.  In other words, you are getting what you paid for!

Adding to the headaches of comparing cost/benefit for clouds is the fact that almost every provider over-allocates network bandwidth.  If their network connection to a 12-core server is 1GB, can you really expect to get more than 80Mbits (10Mbytes/sec) to your VM (1Gbit/12 1-core VMs)?  Probably not.  And what happens if your application needs more bandwidth than it is getting?   It sits and waits for the I/O, burning CPU time.  If your I/O wait is 80% (typical for congested servers), then you're paying 5 times more for CPU than you thought you were!  For example a recent study showed that customers of a major cloud vendor were over 50% I/O wait during business hours.   It's inevitable with ethernet technology: even with 10Gbit networking, the CPU vendors keep adding more cores every year so that the bandwidth, when divided up between the VMs on the server, is inadequate and going down year by year.

And finally, most people don't really know how powerful today's cores are, so they inevitably ask for more than they need because it's hard to assess how well your application will perform in a cloud.  The only way to know for sure is to install it and then meter it under load.   This is what we do for customers before recommending a resource allocation.  But just for curiosity's sake, here's what we've seen customers do with just one 2.8GHz 3rd generation Opteron core in our high-performance infrastructure:

• Serve audio, pictures, and video to 200,000 registered streaming users (not all at once.)
• Host sales call automation for 10,000 seats of CRM users
• Serve 5000 media metadata lookups per second on a 1TB Oracle database
• Host 800 marketing websites

In conclusion, with the state of today's cloud market, you can't compare on price alone, nor can you be sure that a given resource allocation will meet your needs without testing it.  Then again, the elastic nature of cloud resources means you can just deploy and figure it out later.  The only downside is that the price may be a surprise.  Or, if you fix your budget, you'll find that what is elastic is not the cloud, but the speed of your application. 

ENKI offers monitoring, predeployment performance assessments, and auto-adjusting tiered discounts to help cushion you from cost surprises.  And we allocate guaranteed, known resource levels to your application so that you can count on your measurements, as well as the performance of your application.

NimSoft, ENKI's monitoring systems partner, released an SAP probe today.   The probe provides comprehensive monitoring of all SAP Basis events and core components. It was developed by AGENTIL, a NimSoft partner and certified SAP services partner.  Drawing on AGENTIL’s extensive SAP expertise and the scalable, secure, and stable NMS architecture, NMS for SAP Basis provides a unified and detailed view of the performance of SAP and the entire IT infrastructure. As a result, administrators gain the insights they need to optimize the performance of SAP-powered business services.

NimSoft also has probes for SyBase SQL Server, Windows, Linux and other components of standard SAP technology stacks.    

As a result, ENKI can now deploy and assure the performance of your SAP implementation in the cloud, as well as deploy NimSoft-triggered automation to manage performance.

A while back I wrote about a customer of ours, ClickAndBeFree, who is using the ENKI cloud to teach marketing seminars.   They rent a large room in a hotel in their target market area, and teach a class to 500+ people in how to market on the internet by building their own marketing website.   Their business is successful and growing and they've decided to expand their operations overseas to Australia, Singapore, London, and further.

Unfortunately, the road hasn't been without bumps: hotels or meeting facilities that they have used in the U.S. so far didn't always have good internet connectivity or adequate wifi to allow 500+ people to show up with their laptops and all click "submit" at once and get acceptable responses.   Now, as they venture abroad into areas where the connectivity may even be worse - including longer latencies to the point-of-presence - they needed a solution that would allow them to run the seminars without the distraction of poor access to the cloud.  

ENKI's solution - drawing on our roots as a consultancy - is to create a mobile version of PrimaCloud to provide a cloud point-of-presence that has the performance to serve up to 1000 simultaneous users, packaged with wifi infrastructure to connect to their laptops.    The mobile cloud POP will have the same reliability features as our public cloud, but be small enough to be portable.  Our customer will deploy code to allow the students to use the mobile point of presence as their development environment while syncing their data to ENKI's public cloud for live (if slightly delayed by slow internet access) deployment.  ENKI will remotely monitor and manage the customer's cloud POP, giving them the same level of service as we provide in our public cloud.

This is the reason that ENKI built PrimaCloud as well as the Computing Utility out of standard technologies, allowing higher- or lower-end hardware to be used to build the cloud so that the cloud could easily move into customers' premises as a private cloud, or even on the road with them.  And by keeping proprietary code out of the deployment path, customers have the flexibility to move their applications in and out of any cloud POP - even from other providers - that uses the same technology, breaking vendor lock-in and geographic limitations.

In my experience doing sales for ENKI, I've begun to form an idea of why companies are not seeing the savings from virtualization and cloud computing that they have been expecting.  I call it the "virtual physical server problem" because I think they're treating their virtual servers like physical ones, from specifying them all the way through managing them.

It all begins with specifying the server.  I find that most of my prospects don't know how much computing they really need.  But they think they do ... and the conversation goes something like this:

Me: "How much horsepower do you need?"

Prospect: "Oh, I'm running on an 8-core, 16GB server and it works well, so I really need 8 cores and 16GB."

Me: "Have you done any monitoring or used your systems performance tools to check that?

Prospect: "No, everything is working fine, so why should I do that?"

Since the industry average even for virtualized servers is less than 30% utilization, this prospect will end up spending three time what he needs to in the cloud.   Even considering that cloud is often 50% more expensive than leasing a server (in part because it delivers other benefits like scalability and reliability), this prospect is throwing away a potential 55% savings by specifying his cloud deployment to look like his physical deployment.

The next place that the virtual physical server problem costs organizations is in deployment.   On physical servers, applications are designed avoid hitting the resource limits of the server and crashing, and scaling is a arduous affair in which reserve servers must always be running, since they can't be allocated on demand.  Surprisingly, prospects often order the same amount of "extra" servers for the cloud as they would in co-location.   If, for example, an application only needed 10x the base server count for 10% of the time, the deployment would cost over ten times what would actually be necessary if the scalability of the cloud were appropriately used.   With PrimaCloud, it is even possible to scale on end-user SLA compliance rather than the common CPU utilization, allowing you only to pay for what you need to meet your SLAs.

The last place that the virtual physical server problem impacts cost is in management.    This is the single largest cost factor that prevents cloud from delivering savings, and it's invisible to most consumers of cloud, because they're locked into physical virtual thinking.  Companies that move to the cloud from colo - or even move from one cloud to another - all end up hiring administrators for their applications and "cloud datacenters" which cost about the same as managing physical servers.    Let's face it, most applications don't need a true 24x7 Ops team, which can often consist of as many as 6 or more people if you want to avoid burnout.  Instead, they just need someone to be there when there is a problem or a code push.   These companies have virtualized their computers, but not their IT, and so the bulk of their costs are still there.  I can't tell you how many times I've spoken to a prospect who ended up going with Amazon and heard that they didn't save any money.

The solution is to treat your cloud deployment as Virtual IT - everything is in the cloud, and everything scales as you need it: servers, IT operations, costs.