For the past month, during my nights and weekends, I’ve been working on a new fitness web application.  In an experiment on transparency, I’m going to completely over-share on the business plan, design, process, stats and feedback.  Expect to see some code snippits, anguished tirades on money woes, and maybe even a glimmer of hope here and there.

So where to begin?  How about what, and why? As will come as no surprise to any who know me, I’m addicted to gadgets.  Combine that with enjoying biking, running and working out, and I now have at least 3 different “human telemetry” (a term I love, and picked up from a collegue at Sun Microsystems, Tony Kay) devices.  A Garmin Forerunner 405, a Polar RS400, and a Nike+.  I use the Garmin when outdoors, the Polar when inside, and the Nike+ not so much anymore.  The Nike+ was the first device I picked up however, and opened my eyes to what combining human telemetry with a great social experience can do.  

For those who haven’t played with the Nike+ site, it’s quite frankly one of the best uses of social networking I’ve seen.  After each run, you upload your data to the Nike+ site, where you can see how you performed.  More importantly, you can enter into competitions with friends, no matter where they are.  Even strangers.  For example, my sister and I competed to see who could be the first person to run a total of 30 miles.  She could run on one day, me the next, and Nike+ would let us see how it’s going.  It’s motivating, fun, and interesting.

Eventually, my toy addiction meant I outgrew the Nike+.  It’s notorious inaccurate, there’s no HR or other real-time data, and it requires that you have an iPod Mini with you.  As I moved on to my other devices, I missed having the social aspects. There are vendor specific sites, like Garmin Connect, but if you have a Polar, I have a Garmin, and Tara has a Nike+, there’s no way for us to get the competitive juices flowing.  From that simple disconnect, Zed9 was born.

Zed9 is like mint.com for fitness.  The idea is to aggregate data from as many sources as possible, provide you with meaningful analytics, and compare and contrast your performance with others in your network, demographics, and interest groups.  I’m planning on launching a private alpha this week to start getting feedback.  

As I develop and launch this, I’m planning on blogging about the experiences, technical hurdles, marketing and product management challenges.  Next topics specifically will be around balancing hobby vs. job, moving forward (or not?) in the face of overwhelming competition, setting milestones for determining just how much of my damn time I should put into this, and what does success even look like.  If there’s anything you want to know, from trivial to intimate, let me know!  And if you’ve got a Garmin of Polar device, go sign up for Zed9!

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.

A topic very near and dear to my heart has picked up some steam recently: Enterprise software pricing. Kicked off by ReadWriteWeb, and picked up elsewhere, the basic point is that value is not correlated strongly with per-user pricing.  All these “Enterprise 2.0″ companies are out charging on a per-user model, but that’s at odds with the value derived by the customer.

Let’s first take a step back and look at the big picture.  Business model and pricing is a means to an end.  Ultimately, as software producers, we are in a VERY strange world in which our incremental cost is $0.  As with any intellectual property sale, since their is no intrinsic cost to our product, all pricing is simply a matter of playing with funny models to make the customer feel like they’re not getting ripped off, and the vendor able to generate enough revenue to survive, and in rare cases maybe even thrive (rarer every day it seems).  As a previous boss of mine used to say – software pricing is all insane, it’s just a matter of agreeing on the insanity.

At the end of the day, all that really matters is what $ amount changes hands.  A total $ vs. value graph for these Enterprise 2.0 companies looks very different:

In this graph, value still goes up quasi-exponentially with the users.  Total cost also scales, but it’s quasi-logarithmic. Instead of being inversely proportional, we’re now just looking at a gap in the middle. Further, it’s a gap that companies are used to paying.  Yes, I’m ignoring all the capped deployments and models that are “packaged” vs. per user, but in general the vast majority of scaling 2.0 business models net out to the above graph. 

Our entire life experience, plus all previous experience, tells us that the more you buy, the less you pay per item, but the more overall it costs.  Trying to go against this is probably impossible.  Software pricing is about putting a framework in place that makes your customer feel like they’re not getting ripped off, and enabling you to run your business.  Everything else is just hand waving.  Make sure the general curve of your overall monetary exchanges is correct, and focus on the value in the product.  Pricing is necessary, but not sufficient.  It’s easily possible to setup a pricing model that’s so broken it kills your business, or doesn’t scale to support where you need to go.  On the other hand, you’re not going to make your business through a pricing model (as proven through Sun’s numerous attempts with Project Orion, network.com, etc…).

Come up with a model that scales.  Something that if your assumptions work out, enables you as a business to succeed.  Then focus on the business and value to the customers.

Rich Miller (CEO of Replicate) posted about our search for some larger ESX shops.  If you’ve got >40 ESX servers in one virtual center instance, and are interested in a 1 year free subscription to RDA, please get in touch!

We’ve been encouraged by the response to the announcement of RDA 1.0.  The number of visits, registrations and people downloading the free evaluation version of the product has been terrific.  

But we’re not yet satisfied: We are particularly interested in finding organizations with sizable VI3 virtualized datacenters who would like to evaluate the datacenter analyzer.  The majority of our users have indicated that the number of ESX hosts under management by Virtual Center (or should I say vCenter ?) is 20 or less.  We’d like to find the installations with 40 or more ESX hosts under management.  

To that end, we’re extending to three organizations with more than 40 ESX hosts in their datacenter, the opportunity to become a Replicate Technologies design partner.  In exchange for providing us with modest amount of feedback on your experience, design partners will receive one year’s free subscription for the full compliment of servers in the datacenter.  If you’re interested, give us a call or use the sales inquiry submission form here.

New research report out from EMA today that’s well worth looking into.  SearchCIO-Midmarket.com has a great article on it.

Behind these figures are management challenges that companies are only starting to recognize, let alone address, the surveys found. Only 24% of respondents to an Enterprise Management Associates Inc. survey of 627 corporate IT decision makers published last April said they thought virtualization makes security administration easier — as compared with 42% in 2006. Just 32% said software control and distribution is easier in a virtualized environment, down from 58% two years ago. And configuration management numbers plummeted from 58% to 32%.

That’s exactly one of the problems we set out to solve with RDA.  We recognize that administrators are being thrust into administrative positions that challenge them to broaden their expertise dramatically.  Managing a virtualized datacenter requires deep network, storage, server, and virtualization skills, often in very short supply.  RDA helps, by providing clear guidance and prescriptive remediation to help administrators find and fix problems in their datacenter quickly and easily.

Another favorite quote:

ndeed, everything from performance and capacity management to troubleshooting and security administration becomes more difficult in a volatile, multilayered and often heterogeneous virtualized environment, Mann said. 

And finally:

Unfortunately, there aren’t a lot of software tools that manage virtual and physical environments or multi-platform virtualized installations in an integrated fashion, the EMA report stated. Only 21% of management tools in use can integrate effectively with other enterprise system management tools, according to EMA’s Mann.

If this sounds like you, go check out RDA!

It’s a sign of just how great and busy we’ve been that it took me 4 days to post this!

As of Monday, November 11th, Replicate’s first product – Replicate Datacenter Analyzer – is officially launched.  

What is RDA? From our website:

Over 60% of downtime, security, and performance issues are due to configuration errors, and virtualization is only going to drive that percentage up. To ensure proper virtual datacenter operation, it is critical to have a holistically configured datacenter based on industry best practices.

Combining empirical data from our IP network probes with configuration information obtained from other individual datacenter elements, RDA constructs a unified view of how the entire datacenter works across different administrative domains. Ensuring that administrators can quickly see the relevant information, RDA “knowledge packs” apply industry defined best-practices to highlight latent problems and overt mis-configuration in a virtualized datacenter that can impact security, reliability, or even downtime.

Go check it out!  We’ve got a free trial, screencasts, and all sorts of other goodies on our website.

Here’s one that I’ve been thinking about for 6+ months:

Oftentimes when you’re going out, looking for a new job, you’re going to fight for highest salary.  I mean, of course, right?  Who wouldn’t?  That’s why we’re in this rat race – more money!

It’s important to realize that there’s are ramifications.  It may seem obvious, but I’m not sure everyone thinks this through.  If you are offered 70K, and negotiate to get 80K, your employer will likely be looking for 12% more work.  The boss may not come out and say it, they may think you’re a great candidate and want to get you on board, but every month, they’ll be looking at your salary, and thinking about what you are worth.  Frankly, it’s easy to negotiate yourselve into a position that you can’t actually perform at yet.

Keep in mind that your “job” at a new position is to make your boss happy.  Most of the time that means doing the work you signed up for, but there’s a whole host of other requirements you have to meet as well. Your negotiation isn’t just getting you more money, it’s piling on the requirements as well. I’d strongly recomend everyone who’s starting a new job read The First 90 Days.  

On the other hand, if that isn’t how your new employer works, you may be getting into the wrong job!  You want to work somewhere that puts personal responsibility on each employee.  If they’re free with the money, what else are they free with?  If they’re desperate to get you on at any cost, are they equally desperate elsewhere?

After all these posts on agile process and tools, if you’re interested in hearing live how I’m using Jira and Greenhopper, then sign up for this webinar Wednesday.

After introductions from Atlassian and Pyxis, I’ll be talking for 15 min on how we’re using them here, on our live dataset.  I’m talking about why we choose Jira/Greenhopper, how the entire team uses it, and what some of my favorite features are.

We’re at that stage right now where the whole team is clicking.  Every 24 hours I’m seeing improvements that blow my mind away.  The more we get done, the fewer items left for us to do, the more I’m looking back and realize how TOTALLY INSANE my expectations were when we started.

When I first joined Replicate, our founders had already spent a bunch of time on the core databae and inference engine that drives everything we do.  Their up-front investment is what has enabled us to get to where we are today.  The rest beyond the core engine was good, but not what I was hoping for.  After a month of getting to know what’s going on, we emabarked on a massive push to completly overhaul our UI, the workflows, and everything about the product experience.

User experience is incredibly important to me, and I wasn’t happy with our state.  I confidently laid a plan for ripping the entire thing up, changing everything to the very core.  I committed to my boss that we could get this, “no problem”.  I signed up for all sorts of improvements, from new visualizations, new interface paradigms, new toolkits, and more.   Now, as we’re just two weeks away from release, I know I was totally nuts.  Not because we didn’t deliver everything I hoped we would – we did/have/are!  No, I was nuts because looking back, if each and every little thing hadn’t gone just right, we would never have made it here.  If we hadn’t hired an AWESOME UI engineer.  If our lead engineer wasn’t a rock star.  If we hadn’t managed to get an automation engineer and harness to remove the friction.  If the entire team wasn’t flexible enough to deal with massive change daily.  But we did, he is, we did and they are.  And so now, on time and on schedule,  we’re two weeks away from launching a product that I’m really excited about.

We’re a startup.  Odds say, we’re going to fail.  It’s only by having unrealistic expectations in the first place that any of us even can get into this job.  If we don’t keep having unrealistic expectations every day, we’ll get trapped by what we can’t do, and deliver just another piece of software.  IF we can keep being unrealistic, signing up for insane deliveribles every day, then I think we just might make it.

Over at my job, we’re just two weeks away from our first release!  I thought this would be a great time to look back a little at our tools and process.

Process

From the day I joined, we’ve been developing via a scrum process.  For those not familiar, the highlights are:

• Everything you want to do goes onto a prioritized list called the backlog.
• Write requirements in the form of user stories.  (As a <USER> I can <FUNCTION> so that <REASON>)
• Anyone can add, only product owner can prioritize.
• Team agrees on what backlog items they are going to work on during a planning meeting.
• Create todo list from user stories.
• Track progress through iteration.
• Repeat!

Tools

Say what you want about pen and paper, but I’m a geek, and love the toys. We use a bunch of tools here:

• Jira as the single source of truth
• Greenhopper as the plugin that makes Jira usable in an agile enviornment
• Confluence for all our wiki needs
• Bamboo as our build server
• Subversion for version control
• Balsamiq to mock up our front end.

Overall, this set of tools has been fantastic.  We’ve spent right around $5,000 for all the software.  That’s a significant chunk for a small company like us, especially when there are such great free tools all around, and I’d spend it again in a heartbeat.  The quality of these products is just outstanding.  The support is great from everyone, and Atlassian in particular needs to called out.  I’ve had 4 issues worth submitting as tickets, 3 of which they handled in < 2 hours, and 1 was my fault.