Skip to Content

AppZero

Amazon

Cloud market: rites of passage

Blink twice and “Can we get a puppy?” becomes “Can I take the car tonight?” Cloud computing took a little longer. By my calculation, it’s taken roughly 8 Cloud Expos to move from “Cloud what?” to “Cloud how?” -- I know because I’ve been at all but the first. So, returning from New York where last week 7,500 people attended the 8th, I reflected on how much the questions being asked about “the cloud” have changed since the first Cloud Expo in 2008. 

2008 – What is cloud computing?

Translation:  Okay, what is it?  Does ‘The Cloud’ = Amazon Web Services or what?

What are the key capabilities of a cloud? What is AmazonWS?  How is cloud computing different from virtualization?  Self service, pay for what you use, SaaS … are hot topics. Amazon WS does $100M in revenue.

2009 – Is the cloud real?

Translation: Is this something I’m going to have to pay attention to?

Does cloud computing mark a generational epoch on a par with Mainframe, Minis, PC and Web? … or is it a fad that will pass?  Saving money, CapEx vs. OpEx, agility, and ‘why wait on IT?’ are core issues of the day.  AmazonWS does $250M in revenue.

2010 – How do we define the cloud?

Translation:  What’s going to be my best approach to clouding-up my organization?

Every presentation opens with the question: “What is the Cloud?”  Most speakers cite Wikipedia or Nist, others have man-on-the-street videos asking people what cloud computing is. Vendors define it in terms most favorable to their own offerings…. IaaS, PaaS, SaaS, what color is your cloud? Cloud company acquisitions begin.  AmazonWS does $500M in revenue.

2011 – Where do I go from here?

Translation:  How do I make this work?

Many have tried to leverage cloud with mixed results.  Cloud Roadmaps and solution presentation abound in attempts to fast forward through the experience curve, but the devil is in the detail.  Cloud company acquisitions accelerate.  AmazonWS on track to do $1,000M in revenue.

2011 and beyond:  It’s pretty clear that Cloud is the next generational computing epoch, likely to dominate the next decade plus, unless the Mayan calendar turns out to be right. Today, the market is moving from the Wild West to the beginnings of settlement – a time in which companies are building stonewalls to stake their claims.  

IT professionals also have moved past the obvious low hanging fruit of dev/test and brand new apps on to moving existing applications to a cloud. Companies want to be able to install, configure, clone, run and …. then …. move ….. multiple instances of an application unchanged. The reality of Amazon being down for a few days only reinforced the requirement to have multiple copies of any important application ready to go at a moment’s notice.

Mu$ic to my ears. 

I actually had fun manning the booth and walking the floor, telling the AppZero story, which is a great match to this generation of questions: We offer the fastest way to move existing applications to any cloud – letting companies change clouds and workloads to match evolving strategies.  Here’s the flexibility to learn, adopt and change cloud foundation rapidly, without lock-in.  This cloud agility is a differentiator that will separate the winners and losers in many markets.

On that note, now seems like a good time for the next installment of GregO's cloud valuation exit/acquisition score-card

Time             Company                                          Valuation*

Q1 2010        3Tera/CA                                           $90M   @ 30  EV/R(ttm)

Q2 2010        3Para/HP                                            $2.4B   @ 12  EV/R(ttm)

Q1 2011        Facebook/Private IPO (GS)               $50 B   @ 25  EV/R(ttm)

Q1 2011        Terremark/Verizon                             $1.9B   @ 5.4 EV/R(ttm)

Q2 2011        Navisite                                               $230M @ 2.1 EV/R(ttm)

Q2 2011        Savis                                                    $2.9B   @3.0 EV/R(ttm)

 *Valuation – includes debt

EV – Enterprise value or market cap + cash + debt

R(ttm) – Revenue for trailing twelve months

 

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.

Amazon EC2, Solaris 2.6, and the San Andreas Fault

As it turned out, the brilliance and competence of Amazon’s technocracy were no match for simple human error. An incorrect manual update to the network set up a domino effect of Catch-22-esque compound failures to Amazon’s EBS (Elastic Block Store) details of which can be found in a 6 page explanation the company offered last week.

Although cloud naysayers will no doubt try to make this event the poster child for Luddite agendas, it won’t work. Data was lost. Business was lost. News was made. But overall, the fallout has not been too bad as users have quickly come forward to stand by Amazon and the choice to use its services.

And the risk was largely knowable. As Jason posted in an article On Cascading Failures and Amazon’s Elastic Block Store  “This is not a “speed bump” or a “cloud failure” or “growing pains”, this is a foreseeable consequence of fundamental architectural decisions made by Amazon.“ 

The gains surpassed the risk. And will continue to do so. Though still in its early stages, life in the cloud is really a lot more of a learning experience than it is an adventure. Everyone involved will continue to get a little wiser in the ways that only experience – usually bad ones – can confer on those gaining the wisdom. 

As the only software vendor offering patented technology to virtualize Windows, Linux, and Solaris server applications – AppZero is a huge fan of all things cloud. We invite our customers to move their applications to and from datacenter and cloud(s) and cloud to cloud, with no lock-in. I’ve seen the hesitancy that comes from skepticism and trepidation as well as the high fives and smiles that accompany seeing and believing.

But here’s something I’ve also seen that I will never understand: Organizations running very important (though not “mission critical”) Solaris 2.6 applications on hardware that is past the hope of life support. The hardware will fail and take with it the applications. When I say, “It’s not a matter of if … it’s when.” I get knowing chuckles and head shakes as IT pros tell me how very right I am. 

When I go on to tell them that AppZero software can encapsulate their Solaris 2.6 and 7 applications, pick them up, and deposit them on Solaris 10 and bright shiny, inexpensive, reliable machines, all without a line of code … they are intrigued. Of course they are. Here’s a very cost-effective solution to a guaranteed problem.

Okay.  So here’s the question: Then why doesn’t every one of them just jump up and sign on with AppZero? Human nature or human error? Have they lived so long in denial that they’ve crossed over into magical thinking, convinced that because it hasn’t happened … it won’t? Or do they expect to be in new jobs before the when = now?

Cloud risks pale against cloud gain. Life on the San Andreas Fault brings a great lifestyle until the big one. But important apps on Solaris 2.6?  I don’t have a clue so feel free to send me one. In the meantime, let’s cloudify those Windows and Linux client/server apps – no code, no lock-in, no pain.

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

Verizon and Terremark hookup with promises of respect in the morning

Although I’m a sucker for short term prophecies, I’m pretty sure that no “Top Cloud Predictions for 2011”said anything about Terramark being sold for close to $2B when you factor in the $524M debt that comes along with the deal. 

In a press release that featured a 14 word title, with 30 word sub-title, telecom service provider Verizon announced that it will acquire the provider of IT infrastructure and cloud services to help speed up its strategy to offer “everything as a service” (their words, not mine) to enterprise and governmental clients.  But I have to wonder if the folks who crafted a 44 word headline for an announcement heralding the union, will be able to navigate a smooth path to cloud effectiveness.

The first logical question is, as a vassal state to a telco, will Terremark remain carrier neutral?  Lowell McAdam, president and CEO of Verizon thinks the answer is “yes” saying, “We have very specifically set Terramark up as a wholly owned subsidiary, and Manny [Manuel Media, Terremark chairman and CEO] and his team will be independent.”  He went on to say, “We’re not going to try to cramp their style at all.  There will be no moves to take certain customers out of play.”  (I also trust Mark Z with my home address on Facebook.)

Back to the deal.  A quick look at the financial metrics compared to Rackspace comes out like this:

Terremark Worldwide, Inc. (TMRK)

Revenue (ttm):320.70M

Qtrly Revenue Growth (yoy):23.00%

Price/Sales (ttm): 3.91

Enterprise Value (EV)/Revenue (ttm): 5.40

Enterprise Value(EV)/EBITDA (ttm): 23.14

Total Debt (mrq):524.14M

Rackspace Hosting, Inc (RAX)

Revenue (ttm):735.34M

Qtrly Revenue Growth (yoy):21.60%

Price/Sales (ttm): 5.79

Enterprise Value(EV)/Revenue (ttm):  5.81

Enterprise Value(EV)/EBITDA (ttm): 20.48

The numbers clearly show that Verizon is paying almost the identical ratio on an EV/Revenue and EV/EBITA for Terremark as the current valuation of Rackspace.  The Price/Sales ratios are not close because this ratio does not reflect the large debt that Terremark has compared to almost no debt for Rackspace.  Enterprise Value (EV) is a much better way of getting to real apples to apples comparison.  It’s interesting to see that on market prices alone, Rackspace is 2 times as large as the take out value of soon to be VeriMark (yes, I did make up the name).  Although the growth rate for the two companies are almost identical, Rackspace’s far greater top line makes their growth a higher degree of difficulty factor yielding much more revenue in total dollars.

If Geoffrey Moore were reissuing his chasm crossing work, he’d definitely need to identify a phase where companies throw vast amounts of money to stay competitive in a cloud economy.  Because that’s where we are now.  With apologies to Mr Moore, let’s say that Cloud Computing is in the Tornado phase.  In this phase, everything has a cloud label stuck on it whether the micro-burst fits or not. 

In Tornado times, winners and losers make visible moves on a chessboard-like market: 3Terra, 3Para, Terremark, and Steve Ballmer’s email to the troops firing sending Server and Tools Business Unit President Bob Muglia “to the cloud”.  (I hate that commercial of the women editing a family picture to the obnoxious repeated call “to the cloud”.  Talk about cloudwashing …..)

So who wins?  Who loses?  Here are Greg O’Connor’s top predictions on the topic:

  • Verizon will make money with the acquisition.  But the distraction of integration and learning how to be agile within the Verizon conglomerate will consign VeriMark to the “me-too” cloud category in the long run.
  • Unfettered, Amazon and Rackspace will be free to innovate.
  • Rackspace will acquire 2-3 companies over the next 24 months to gain more competitive distance and market share.
  • Amazon will spin out -- or report separately -- the Web Service business because the market can not adequately distinguish and value cloud revenue/profits from the retail business.  Both will prosper.  I will invest.
  • Cloud provider leaders will remain independent for a long time because we are in the 2nd inning of the ball game and we know that winners will be rewarded with Facebookesque valuations.
  • Terremark shareholders ….. cachink.  Or as Manny put it, "This transaction, first and foremost, provides Terremark's stockholders with the opportunity for immediate, maximum value and liquidity for their investment in our common stock.”  As I said, “cachink”.
  • The market will recognize and reward the genius of independent, cross-cloud tools …. For example, AppZero’s patented, OS-free, application virtualization, cloudification technology.

First installment of GregO’s cloud valuation exit/acquisition score-card:

Q1 2010        3Terra /CA                                          $90M @ 30  EV/R(ttm)

Q2 2010        3Para/HP                                             $2.4B @ 12  EV/R(ttm)

Q1 2011        Facebook/Private IPO (GS)          $50 B @ 25  EV/R(ttm)

Q1 2011        Teremark/Verizon                          $1.9B @ 5.4 EV/R(ttm)

The Death of Cloud Computing the Birth of Dream Computing

I do dream in color, not always vivid color, but color just the same. Today, I was awakened by one of my 5 boys in the middle of a great dream about the future. In my dream, I was in a big white room just as a door was opening and someone was about to walk in. Who was that? That’s when I was awakened.

Don’t you hate dream interruption? Or Idruption? Quick note, I heard the iPad comes with an Idruption finisher, those guys at Apple are so innovative.

What I do recall from my dream was that it was the summer of 2012, and Jeff Bezos, Paul Sagan and I were celebrating the 2 year anniversary of the merger of our three companies. There was a lot of talk about how 50% of the Fortune 1000 had shut down their data centers and moved all their operations onto our Dream Cloud. So much for that Gartner prediction –“By 2012, 20 percent of businesses will own no IT assets.”  The other thing that was clear from the conversation was that Dream Computing as a category had completely replaced the term Cloud Computing.

Akazon’s (the combined company’s name) market capitalization had just crossed the trillion dollar mark. We had over 10 million physical machines or 10 billion virtual instances all around the world thanks to the new Dream chip from Intamd. Close to 70% of the internet traffic was flowing through the Akazon Dream Cloud. The year had started with Paul convincing the board to turn down Eric’s request for us to acquire Google. Paul’s core argument was that Google’s search and ad businesses were going to be replaced by our Dream fulfillment engine. The search-to-decision-to-Dream fulfillment evolution had taken hold. We had solved the issues in China and had a commanding share in this huge piece of the world market. Eric, Larry, and Sergey were not happy but it was clear they were becoming a legacy supplier, and we found a dream number even more magical than √2.

2011 was very busy for Jeff as we divested our online shopping division. I was really surprised Jeff took the lead on this and got such a great price from Larry at Oracle (he never really believed in Dream Computing or its predecessor Cloud Computing). By selling databases, applications and hardware direct in their new online store, Larry had replaced almost his entire sales force. It did do wonders for their margins and profitability.

2010 had been the year in which the Dream was defined. The public Dream, the private Dream, the hybrid Dream, and the enterprise Dream were now clear to the world. Where the environments are located, security concerns, how to move applications from the enterprise to the Dream and back again were completely nailed. The Dream economy was born and unemployment was under 5%. As a side note, national health care had not come to a final vote.

Yes, 2010 was the year Dream Computing was born. The market understood what Cloud Computing (infrastructure as a service, platform as a service) was. Amazon was leading the pack, delivering the self-service, pay-as-you-go, resources-on-demand, utility-in-the-sky. Topping the 1 million developers mark. The challenges to Cloud Computing adoption were surfacing for those in the business.

Secure distribution, and moving existing applications unchanged to the cloud were beginning to slow the paradigm shift down.

Akamai saw competition coming from the roll-it-yourself CDN developers using geographically-distributed clouds, and the world saw more and more content being part of everyday applications. Not as demanding as streaming a Victoria’s Secret video, but delivering more content to the edge faster was a foundation of Dream Computing. It also occurred to Akamai that they had a ton of compute horsepower for serving up those images to millions of eyeballs focused on Heidi Klum and the Black Eyed Peas, which they could sell during the other 364 days and 21 hours. Talk about a spiky workload and over-provisioning. Why not just build out the data centers Akamai had around the world and extend them to have the capabilities like those in Amazon? With global real-time distribution, low latency, and the ability to limit network attacks as the next layer added on to that old concept of Cloud Computing, the transition was underway.

The last piece of the puzzle was the application containment and provisioning provided by Virtual Application Appliances (VAA) from AppZero. The ability to scoop up and move existing applications to any of the Dream Computing nodes, or across any node and back again, was the grease that finished off the legacy concept of Cloud Computing. Moving just an application, not the whole machine, and being able to determine what has changed from provision to provision, made utilizing the dream fabric in the ether easy. Separating and isolating the application or workload from the OS became a “duh.” The death of installing applications and commingling them with OS had gone mainstream with dynamic provisioning replacing standard operations. VAA had become a movement that is now being taught in high schools today. Whoever came up with installing applications anyhow?

Dreaming about Dream Computing  – Now I remember how it ended. It was Paul Maritz at the door. He was there to get us to buy Zimbra from him. Funny how the pioneers and thought leaders of today become a distant legacy dream so quickly. I recall sending him over to see if he could sell Zimbra to Apple. It would be a good service for their iDream offering that we run and manage for Steve while Paul focused on the Bed Bath and Beyond business.

In Practice: From your machine, to EC2, and back in 1 minute

Agile development and deployment workflow

This series describes a development and deployment process optimized for the needs of software-as-a-service in terms of cost structure, agility, staging and test requirements.  The resulting system will tolerate the failure of a local hard drive and crashes of a machine - physical or virtual.  Offering good performance / low cost via Amazon's EBS and EC2 services, the system will provide the ability to rollback changes both on the deployed and development system (independently or together) using Subversion.

You can enjoy instantaneous feedback when you are developing code without affecting existing users of your website by using a two machine development and deployment lifecycle.  Deployment can be a 5 second experience (as opposed to 5 minutes) using AppZero technology.

I have tried a number of lifecycle workflows for the development and deployment of Drupal websites. In this series, I will describe a two machine approach involving a local development and test machine and a deployment machine. Deployment of files will use the Subversion Version Control System; the local machine is Windows to make tools like Photoshop convenient to use; the deployment machine is a Windows machine from EC2; and we will use Apache, Drupal, and MySql.

The one-machine approach, topologically simplest, involves developing directly on the deployed machine on the Internet. I've found this approach, while seemingly simple, to have two serious deficiencies:

  • developing a new feature for a site can often involve accidentally breaking existing functionality or look-and-feel. This topology makes it difficult to evolve a site without showing the public every intermediate change.
  • tools like Photoshop  are not convenient to use on a remote basis and ftp'ing files back and forth is a cumbersome process. Even text editing on a remote machine incurs painful latencies.

For these two reasons, I advocate at least a two machine approach. This allows you to develop on your local machine, disconnected from the Internet if necessary, with all the tools you like, and deploying when you desire. Of course, in a two machine topology approach, deployment agility becomes paramount. The difference between 5 seconds to deploy and 5 minutes makes the difference between wonderful and painful.

In Practice: Agile and Scalable Site Development with Drupal, Appzero, and EC2.

Like a lot of folks, I'm excited about the possibilities that arise when you combine the agility of modern CMS's (like Drupal and Wordpress) with the scalability and administrative control offered by Compute Clouds (like Amazon EC2 and GoGrid).

In my work as VP of Technology here at AppZero, I've had the opportunity to work with a number of web site and web app developers who are trying to realize this potential. I've seen first hand that there are a lot of unwritten, but critical, details we must know to capitalize on this power.

This entry is the start of a blog series in which I'll share my viewpoint -- and I welcome your participation.

I'm going to kick off this series by sharing my experiences in developing, deploying, updating, and scaling out a Drupal installation in Amazon's EC2 Compute Cloud. I'll let you know what's worked and what's failed. I'm hoping I can make your life a little smoother so you can avoid some of the pain we've gone through -- and get right to the good part.

I'll be writing at least one entry a week.  Here's my plan:

Part 1: An agile development and deployment workflow: from your machine, to EC2, and back in 1 minute.
Part 2: Getting Drupal on your Windows machine in 5 minutes.
Part 3: Developing your site.
Part 4: Provisioning an EC2 machine.
Part 5: Moving your Drupal development site to the EC2 machine.
Part 6: Updating your Website and redeploying in a matter of seconds.
Part 7: Scaling out your website.
Part 8: Concluding comments.

Join me on this journey by commenting on the blog or writing me directly at chu@appzero.com.

 

Syndicate content