Ontic Oren

That would be William Shakespeare or Stephen Sondheim.

The IT team and developer team look more and more like the Sharks and Jets or the House of Montague and Capulet every day.

Check out some quotes from VMworld this week:

The SpringSource CTO is on stage, hopefully to explain this. Unfortunately people start to leave as soon as they see code. — Virtualization.info Day 2 liveblogging

And just one from the many on twitter:

Can’t help notice the number of attendees leaving the keynote as VMware demos SpringSource :-( — @markbowker

Over the past 40-50 years, the world has evolved an order to the IT world.  Developers create, IT deploys, Ops manages, and we’ve got vendors that cater to each.  Each silo has it’s own jargon, procurement process, goals, etc.  Each has it’s own self-reinforcing feedback loops strengthing the status quo, from press to analysts, to the vendors themselves.  IT is a $1.66 trillion business.  Down from previous years.  Trillion. Larger than 50% of the annual US budget.

The most brilliant thing VMware has managed to do is introduce an amazing new (or really old) technology, without disrupting the process in any way.  Each silo still gets to work the way they have in the past.  Macro processes remain in place.  Developers still code.  IT still provisions stuff.  Ops still manages stuff.  Some of it just is running on other stuff now.  VMware enables IT to deliver what they’ve been promising for years.  Finally, IT teams are able to deliver servers at a pace, reliability and capabilities that they’ve promised for decades.  For once, IT is a rock star!  Frankly, if you’re IT team isn’t using some kind of virtualization, you may want to look real close at that team.

PaaS, though, is a whole different beast.  When you start talking about letting developers code AND auto-deploy, it begs the question: what are those IT guys gonna do?  Sure, some still need to be around.  But not 1 for every 50 vms.  If this actually catches on, it might get as low as 1 for every 500, or even 5000 VMs.  That’s disruptive to the very people who’ve built the 1.66 trillion business.  Of course they’re gonna walk out of the room – what possible value is in it for them?

Show that same demo to a room full of Java developers though – say at the next JavaOne (er, oracle world?  What is the conference for Java developers these days?), and see what kind of reaction you get.  If our experience with ruby developers is any indication, I’d bet they’ll get a standing ovation.

For those following along at home, as Olivia and I have been developing Zed9, I came across this amazing PaaS cloud provider, Heroku. The second I heard about them, I was totally entranced. In a nutshell, they make deploying, scaling, maintaining and living with Ruby based apps trivial. For those who have lived through the application deployment lifecycle before, you know how huge this is. I knew I needed to work with them. And today marks the close of my first month anniversary with Heroku.

It’s been a great first month – with over 30,000 applications deployed, it’s a product managers dream. We have engaged passionate users, and a team who started day one understanding just how important listening to customer feedback is. I’m ecstatic to be part of the team, and help make the cloud talk and vision a reality here.

As easy as using Heroku is, setting up DNS seems to be one of the trickier parts. Heroku has some decent instructions, but the dirty secret is that their required config is actually in violation of the DNS RFC.  While I’m sure they’re trying to fix this, I’ve been running this for a few months and it does actually work, email and all.

Show don’t tell, so here’s a 2 minute screencast that walks through the process of setting it up.  For those who want the one piece of magic: when you want to setup your domain to point to heroku so that http://yourdomain.com actually works, the trick is in the “host” field of the CNAME, put yourdomain.com. <— NOTICE that there is a trailing period there.  Put your domain name, plus a period at the end of it, and you should be good.

Configure Go Daddy DNS & Heroku from Oren Teich on Vimeo.

You’ve got an application.  Maybe a bunch of applications.  You’ve heard that the “cloud” is the place for these things today, so hooray, that’s done.  Then you read discussions on corporate cost efficacy, or untold other random things, and the buzz is so loud you can’t hear yourself think loud enough to figure out anything.

Step back, just for a second.  At the most basic level, that collection of apps is gonna run on some hardware.  Somewhere.  No matter how fancy, when pushes comes to shove, it’s got some physical folded sheet-metal somewhere.  Basic part II: Folded sheet-metal is all the same.  WHAT! I know, I know.  HP, IBM, Dell, Sun (er, Oracle), are dying to not make this true, but it is.  It’s all the same.  Yes, there are differences, and they are important to the technicians running this stuff, it won’t make a damn bit of difference to your application.  You spend $3K, you get $3K worth of performance.  Spent $30k, you’ll get something better/faster/more reliable.  For the same price backet, all the vendor’s differences are 95% the same.  Some people care about the 5%, some don’t.  Most don’t.  

So it’s all the same, and you only care about your app.  Sadly, between caring about your app and getting it to run, there are some other concerns.  You care about nice things like reliability.  Or response times.  Or # of credit card transactions.  And getting those things requires some complexity.  Maybe more hardware.  Or some fancy programs.  Maybe some additional people time.  None of it’s rocket science, and frankly, it’s all been done a million times before.  Specify what % uptime you want, how many customers you really want, and there’s a solution for that.  Let’s say you decide you want decent uptime, protection from SPOF (single point of failure), and have a small-ish app that has only 5,000 light users.  Easy peasy, let’s get you two servers, setup some kind of failover arrangement, and you’ll probably be fine.  Yeah, it’s a bit tricky to get this setup, but it’s just tricky, not actually hard. 

Now you want to do this in the cloud.  You look at moving it to Amazon EC2.  You’re team runs the numbers, and SHOCK and HORROR, it’s MORE EXPENSIVE than your in-house team.  OF COURSE IT IS.  They’ve got the same computers.  They’ve got the some damn fancy software, but if you’re doing the same thing on someone else’s equipment, it’s going to cost more.  This shouldn’t surprise anyone.  And if that’s what you’re looking at, you’re an idiot.

The point of the “cloud” (and for this example, while I’m using EC2, please don’t limit your thoughts to them.  This could be any provider, in-house or outside.  It could be higher level like Google App, plain old IaaS, or something new we haven’t thought of) isn’t doing the same thing the same way.  It’s about the flexibility it offers.  The new way you can do things.

So first thing first.  Were those two servers 100% loaded the whole time before?  No?  Great, so why not go with a smaller resource pool.  Either in house with Virtualization, or just use some smaller instance in the cloud.  What’s that, you don’t like “sharing” your resources with others?  Get over it.  Whatever excuse you have, you’re wrong, you just don’t realize it yet.  I’ve spoken with companies who don’t trust VLANs (a way of putting two networks onto a single cable, VERY useful in any real datacenter) for no good reason.  They’re doomed.  The technical constraints are getting taken down daily.

Great, so now we’ve got better utilization.  That’s step #1.  Now my app is doing well.  Really well.  The latest stupid congressional bill is requiring everyone in the company to use this thing 10x as much, and I can’t handle the load!  Oh, you’re in the cloud?  You can provision new resources in 2 seconds instead of 2 weeks or months?  Hey, that’s worth something!  Even if I was on my old dedicated machines (so much cheaper, remember!) they couldn’t handle this load.  I’d be dead if I had to wait for new HW to show up and get provisioned and…

Wait, the app is getting so much attention, my trivial failover mechanism isn’t sufficient.  I need a real disaster recovery plan.  Maybe something in two datacenters, in case California really does fall off into the ocean.  How much would it cost you to spin up a new datacenter again?  Why not let someone else do it for you, and pay a bit more per CPU hour?  

And this is all just in an IaaS world.  Why are you even bothering with virtual computers.  Chances are all you really care about is the application.  Why not just use some PaaS provider, who can do all the sysadmin work for you.  Rails has a great ecosystem here already, with some truly amazing companies like Heroku out there.  Google has python covered.  Even java now.  Now you’ve just cut out a whole huge chunk of management cost in house.  And it turns out it’s even cheaper per app since you’re sharing even more now.

This isn’t rocket science.  Hardware costs are fixed.  Everyone is adding their own technology costs on top.  The more fancy goo, the more it costs on a per CPU cycle basis.  You save money through efficiency, be it using less resources or getting quicker agility.  That’s it.  There is no magic in the cloud.  It’s just another way of making your life easier.  If you actually try and use it as it’s intended, and not just shove your existing inefficient ways of doing things up into someone else’s outsourced HW farm.