I don’t blog much anymore, but this seems a good topic given the past couple of weeks. First off, I am liking azure a lot – and that’s a huge climb from just 6 months ago. I’m playing around with some of the new features of azure and this is absolutely great. I also believe there are some core competencies that are lacking. As azure grows, these core competencies will become more important to adoption.
I am working on a project that could be a good fit for azure and it’s focused enough that the billing doubts I see here are not show-stoppers, but I can see where these could be hurdles for any project.
- Operational Architecture: Ok – so azure is more technically advanced that amazon. We get it, now get over it. That message is sprawled throughout your documentation and comes across as amateurish after reading it the fifteenth time. The solution – message that in one area documenting it thoroughly. When you feel the need to call it out in some deeper document, reference it instead of regurgitating it.
- Developer Communication: So much falls under this. You need a community driver like a Scott Hanselman, Phil Haack or Glenn Block saying “look how easy it is to do [x]” and then showing it in 15 lines or less. There are some msdn blog posts that do this, but good authors tend to be augered-in on what they are doing on the team rather than relating to the customer. And too much of the documentation feels like it’s written for folks on an internal microsoft email group. Your customers don’t have that access path and, as such, it marginalizes the quality. The solution – get a community focused team member working on the developer experience across the board acting as both a writer and a director by pointing people to other content. It gives end-users a go-to guy. Given the breadth of azure, you probably need more than one.
- Off-site Integration Story – this story is great and the tools are slick. Now make them more understandable and accessible to your audience. Show us real life scenarios and build their stories so we can put them to use.
- Queing and Storage Stories – same thing as the offsite story. The capabilities are awesome, communicate them better.
- Onboarding- how can I mention this without saying “appharbor” at least once? My three month demo account keeps getting turned off and the story that comes back doesn’t make sense. It’s annoying. I suspect it falls to my “get billing sorted out” point below and more importantly it casts a doubt on what my real monthly bill will be. That’s not a doubt you want living in your customer’s minds – it will kill adoption faster than anything else listed here. Appharbor is still easier on initial startup, but it’s following points that would have me more concerned.
Get billing sorted out:
I’ve separated this topic out because it is in my estimation the most important one here.
- Is azure boutique priced or usage priced? The difference between the two is that usage pricing is fully traceable and the algorithm is public. If one or more of these conditions is not true, you are boutique priced. Azure tries to ride both and in that respect your message is schizophrenic. This is a hard call, and at its heart is not a technical one. It is also one of the most difficult calls to make because you are exposing yourself to modeling. For that reason alone, communicating this can be harder to do internally than externally. Somone high up needs to step up, back the call and communicate it to everyone.
- Give me the tools to understand my bill. At the end of the day, your customers must be able to understand their expenditures on azure. We also need to model it given our understanding of our solution, our clients and how we see the product growing. These are things the azure team will never be able to internalize so give us the tools to do this on our own.
I suspect that last case would take six months to iron out, but it needs to be done. Hopefully the azure team is already working on it.