Skip to Content

AppZero

VM

Measuring cloud agility in lunches, not days

Question: Why did the server application cross the network?  Answer: For the same reason the chicken crossed the road – to get to the other side … (in this case) of the datacenter and clouds.

Follow up question:  If all a server application ‘wants’ to do is get to another server – physical or virtual – why would it drag along an OS?  Answer: Because it didn’t know it had a much more agile and faster option – OS-free server application virtualization.

And here we get to the heart of the matter …. Server application virtualization is frequently misunderstood because when they think about virtualization, most people think of:

  1. VMs – close cousin to hypervisors; the packaging of server applications with an OS
  2. Desktop application virtualization – for desktop applications, not server applications.

In fact, server application virtualization is different in type and kind from these market mates – not better – different.  AppZero does server application virtualization -- well suited for different use cases and requiring a different market lens than the ones formed by either VMs or desktop.

Agility is the benefit that showcases our use case and brings clarity to the discussion.

The basic math of server application virtualization agility over the VM approach is multiplication of results, by subtracting the OS.  When you separate an application from the OS, the resulting image size is 50 – 1,000 times smaller than a VM image, which can easily surpass 30 GB.

So what?

Well, try on this dirty little cloud secret:  If an enterprise uses the Internet to connect to their cloud provider, it will take DAYS to move that 30GB VM image to the cloud.  Yes, days

By contrast, AppZero virtual application appliance (VAA) images are most often measured in MB, not GB.  AppZero math means that you can provision your server application to a cloud, or multiple clouds, over lunch instead of days.

Lunch is agile.  Days are not.

I’ll do a deeper dive on server application virtualization in Cloud and ISV use cases in my next few blogs.  But for now, if you want real enterprise application agility, server application virtualization is probably as close as you’ll get to a silver bullet.

I am always looking for a way to communicate better and cut to the heart of any discussion. So, if you have thoughts on this subject drop me a line at GregO {@} Appzero {dot} com or tweet me at http://twitter.com/gregoryjoconnor

Moving ISV applications in a Sales 2.0 world -- What a difference an “A” makes

Innovative technology deserves new words. Back when “EJB” was the new shiny, bright center of Java standards, I was part of the team that created “ESB” – both the moniker and the market. It was a natural for me to christen AppZero’s patented, OS-free server application virtualization technology “Virtual Application Appliance” (VAA). Why VAA? To compare with, and contrast against, the well-established “Virtual Appliance” (VA) concept. To both build on the known and to differentiate from it. 

The compare part is that, packaged either as a VA or a VAA, applications travel fully configured and arrive at their destination ready to run – for instant deployment. The contrast part is that, whereas VAs travel on a Virtual Machine (VM) complete with a fully functioning OS, AppZero VAAs travel OS-free.

The difference that the contrast makes? Let me count the ways:

  • An application packaged as a VA of 40+ Gigs is going to be 10 to 100 times smaller as a VAA
  • Sending a 40+ GB file over a network with an average file transfer rate of 1 GB every 4 hours – is measured in days; AppZero’s VAAs will most likely make the same trip over lunch (see my last blog:  (Size matters for apps on the move: physics for ISVs and IaaS providers)
  • Sending Microsoft OS around in VA/VMs is pretty much prohibited by Redmond-crafted license agreements. For that reason, of the 1667 matches found on VMware’s Virtual Appliance Marketplace today, you will find many, many, many Linux based VAs. Windows? Not one.
  • Sending applications that run on Microsoft OS, in AppZero VAA OS-free packages, is quick, easy, and Microsoft compliant.

Put another way, AppZero VAAs let Microsoft-based ISVs deploy their applications across a network for instant PoCs and demos. Something they can’t do with VAs. And, while we’re in the VMware and Microsoft neighborhoods, let me mention that AppZero VAAs are hypervisor and cloud agnostic - happy on any machine (physical or virtual), anywhere (datacenter, private or public cloud).

Which brings me to Sales 2.0. Debate over the definition of Sales 2.0 fuels blogs. But, by any name, successful sales for ISVs in today’s technology-shaped economy require that an application be readily accessible to its buying public, at a click of a mouse. 

When an ISV uses the OS-free AppZero VAA approach, the application arrives swiftly, and ready-to-run – requiring no installation. The potential customer sees hassle-free implementation and can concentrate on using an application – not the laborious process of installation and configuring it.

And that just makes plain old-fashioned good business sense for ISVs. I’ll take a look at some of the specific Sales 2.0 benefits in my next blog. In the meantime, check out our ISV Accelerator http://www.appzero.com/content/appzeros-isv-accelerator-program, or join us for a brief webinar Thursday, May 12th: “ISVs: Provision your App in a Snap for Labor-free PoCs

I’m always looking for ways to sharpen my discussions.  So, if you have thoughts on this subject, drop me a line at GregO {@} Appzero {dot} com or tweet me at http://twitter.com/gregoryjoconnor

Size matters for apps on the move: physics for ISVs and IaaS providers

Give me physics over art any day.  Something nice and measureable.  Something really difficult to argue against.  Here’s some AppZero Physics 101 for you:

Moving an application packaged as an AppZero Virtual Application Appliance (VAA) is 30 – 600 times faster than moving that same application on a Virtual Machine (VM).

I will gladly – and probably unstoppably – use follow-on blogs to tease out the details and reasoning that back up my physics.  But I’ll give you one set of real-life data points from an ISV who shall be nameless until approved for PR by their legal department.

  • Scenario:  using FTP from Cambridge, MA to an Amazon instance at a Virginia-based cloud center, we were getting an average transfer rate of 29/30 kb per second – or 1 GB every 4 hours.
  • 40 GB is the size of the ISV application packaged on a VM as a Virtual Appliance (VA), complete with necessary OS elements.  At the average transfer rate of a GB/4 hours, the application would have taken 160 hours, or 6.7 days to move.
  • 300 MB is the size of that same application packaged as an AppZero, OS-free VAA.  At the average transfer rate above, we are talking 1 hour and 20 minutes to move.

Let’s be really conservative:  1.5 hours vs 6+ days = a huge time savings at 100x faster.

While actual numbers will vary with the complexity of the application and some other variables, physics will prevail:  small, OS-free VAA packages will always … without exception … travel faster than OS-bound VMs.  Furthermore, no matter what the transfer rate may be, the ratio between moving VMs and VAAs remains constant.

Question: Do you know how big your application is when it is separated from the OS?

Thought:  No wonder Amazon Web Services offers a data import/export service base on Fed-ex delivery

A major provider of IaaS told me last week, “When you talk about reducing a package from gigabytes to megabytes, you have my attention.”  Why?  Because physics makes dollars and sense when you’re in the business of moving applications for a living.  And that’s exactly what ISVs do all the time when you consider demos, proof of concepts (PoC), and software distribution. 

So, with this blog, I am kicking off a series that calls ISVs to do themselves and their bottom lines a favor …  Take a look at AppZero’s ISV accelerator program (http://www.appzero.com/content/appzeros-isv-accelerator-program) -- the poster child for good things that come (and go) in small packages – literally. 

I am always looking for a way to communicate better and cut to the heart of any discussion.  So, if you have thoughts on this subject, drop me a line at GregO {@} Appzero {dot} com or tweet me at http://twitter.com/gregoryjoconnor

Moore’s Law: the future of Cloud Computing from the bottom up

I’m a serial entrepreneurial leader.  It’s an art/science, left/right brain thing. I have to say that one of the most challenging parts of creating a compelling strategy, leading a company or building products is getting people to see the possibilities, transitions and tipping points. Imagineering the future calls me to look back at what made companies great -- specifically, how they capitalized on paradigm shifts while the rest missed it. Reading the recent bestseller, Outliers, it struck me that, not only do you have to be smart, but you have to be in the right place with the experience to see and grab the brass ring.

Moore’s Law is one of those history lessons that have traditionally been a touchpoint that points the way to the future. Simply put, Moore's law describes a long-term trend in the history of computing hardware, in which the number of transistors that can be placed inexpensively on an integrated circuit has doubled approximately every two years. 

Translation:  compute power has reliably doubled at a decreased cost every two years.

In a recent announcement, Intel gave a glimpse of what the future will look like. The “Cloud” chip will have 48 cores, is available to Intel’s ISV partner today and will be shipping in volume in less then 18 months. The quote from the Intel dude stated that it will increase the power of what is available today by 10-20 times.  Oh my…. Buckle your seatbelt …. Moore’s law just took a giant step up the paradigm.

In one of my discussions with some folks from VMware I have heard pretty much a uniform response that the tipping point for VM adoption in the data center was the introduction of dual processor chips in 2007. Two core CPUs + VM isolation means I can consolidate physical boxes onto 1 machine. How simple is that math?

Gartner says that the average number of VMs in the data center per CPU socket is 10+ or 5 per CPU.  VM Density is how many environments can run on CPU socket. VM Density increase is due to better through put of the CPU and more efficient VMs and is “the new measure of IT efficiency.”

Fast forward to the data center of 2012. For a moment lets ignore other bottlenecks in the stack that might stop us from drawing a straight line from today to then. VM density will be 240 (5 * 48) per CPU socket. Think of all the empty space in those data centers. Certainly enough to store a few hardcopy versions of the US’ accounts payable to China.

What are some other data points that we can look at today that can help us see the future more clearly? Today’s VM landscape breaks down close to 80% Windows, 15% Linux and 5% other. Why is there such a high concentration of Windows in the data center? Not that I enjoy poking a sharp stick in the eye of Microsoft, but I have to say that it is because no one that wants to keep there job will run more than one application on top of  a Windows 2003 or a Windows 2008 server.

Running multiple applications on Linux? No problem. It is this 1 to 1 OS to app ratio that is one of the things that has made VM adoption so compelling. Fix the fragile Microsoft OS by using a hypervisor to create the isolation between applications that Linux has out of the box is sweeping the industry. So Windows app density is high in Linux, and 1 for on Windows server.

Let’s take a use case where all the VMs are Windows based in the data center. That means there will be 240 copies of the same operating system (assuming the market has actually adopted Windows 2008 server by then). There has to be a more efficient way to deal with the fragility of Windows than running so many copies of the same thing.

Enter application isolation technology or Virtual Application Appliance (VAA) for server side apps. A VAA is a container (a cloud container?) that isolates an application from the OS and other applications. This isolation makes Windows de facto more reliable and eliminates the challenges that force the 1 to 1 App to OS deployment design pattern. VAA makes Windows deployments as robust as Linux, increasing the app density on Windows. Who wouldn’t want that?

Now I am not suggesting that it would be a good idea to run all 240 apps on one Windows 2008 Server OS, increasing the app ratio from 1 to 240. But running 6 applications on 1 OS?  That is very doable and it will reduce the number of concurrent OS from 240 to 40.

Think of the memory savings (recommended memory configuration is 2 GB per OS or 480 GB of memory in this use case). Think of how much you could shrink the checks you have to write from Microsoft by increasing the app density ratio from 1 to 6. An 84% reduction in #OS running. Intuitively, you know it's cheaper to run multiple apps on one OS, but how much cheaper? Well, Amazon is expert at pricing cloud services, and on a simple example of 3 VMs running Windows with 1 app in each VM, the monthly cost would be about $260 on a standard small instance. Therefore running on Amazon with one VM running Windows and 3 apps, the price is $86. Get the picture?  Less OS licenses, less VM licenses, less CPU cycles, less disk, less management

So here are my predictions for 2012:

  • Intel cloud chip will be shipping a 48 core piece of silicon for less then $500
  • VM density will exceed 200 on this chip in the data center
  • Windows OS will be over 75% of the VMs that run in the data center
  • 200 copies of same the Windows operating system running on 1 chip is silly
  • The industry over time removes silly inefficient execution stacks
  • Application isolation will have crossed the chasm addressing, even eliminating, this inefficiency

Assuming the Mayans are wrong and there will be life after December 21st, 2012, you can see my take on the market.  I would love to hear how others see the impact of the cloud chip on virtualization and cloud computing. Greg Ness how will it affect the infrastructure 2.0James Urquhart impact to the Wisdom of clouds is just around the corner?  What is the next tipping point? Drop me a line at GregO {@} Appzero {dot} com or tweet me at http://twitter.com/gregoryjoconnor.

 

Syndicate content