Monthly Archives: June 2011

Lately I’ve been working with startups who are interested in Windows Azure, but they want to use PHP, Ruby on Rails, or Python. Sometimes they also want to use Macs for their primary development machines, and they want to retain the tools they are comfortable with (e.g., github), which are typically Unix commands.

You absolutely can use Windows Azure for PHP, Ruby on Rails, or Python web development, and you can keep your Mac and all your usual development tools for those platforms. However, there is a bit of upfront work that needs to be done to get you to that point – and currently, some of that upfront work needs to be done on a Windows machine. As this scenario becomes more and more popular, I’m pretty sure that this upfront process will get simpler and simpler (whatever Microsoft doesn’t get to, the community will).

So until we reach a point where you can be blissfully unaware of what’s happening behind the scenes to run these languages on Windows Azure, somebody on your team needs to take responsibility for understanding how it all works and how to set things up.

I want to help. For simplicity, I’m going to talk about PHP for the rest of this post, but the same techniques would work for Ruby on Rails, Python, or Java (or Perl or any language that supports FastCGI and has an implementation that works on Windows Server). These concepts are useful for developers using C# or VB.NET as well, especially if you would rather use a tool like WebMatrix instead of Visual Studio.

Thanks to Bizspark, a startup can use Windows Azure for FREE for up to three years (and cheaper than retail after that). So while this might take you a couple of days to figure it out and set it up, it’s pretty worth it. This isn’t shared hosting … we’re talking a 99.9% uptime SLA and dedicated cores!

If you’re not ready to join Bizspark, go to www.windowsazurepass.com and use promo code PFOLEY to get a free 30-day trial – no credit card required.

Architecture

Windows Azure has a hierarchical model for deploying compute resources (note that I’m leaving out some details):

At the top level, you have a service, which is a logical grouping of functionality. A complex solution might have multiple different roles – a role is essentially a specific definition of a virtual machine. For any given role, you can have multiple instances running, but each instance will look the same; this is a “stateless web app” model of scalable development – data is stored in SQL Azure or in Windows Azure storage (neither is shown on this model). You want to have at least two instances running in order to get high availability. If your traffic increases, you simply up the number of instances. Windows Azure seamlessly balances load across these instances.

This is amazingly powerful and flexible, but if you are building a web startup, you probably want to focus your energy on the actual web site – the grey boxes inside the instances. You probably want to start with an architecture that you know will work – that’s “good enough” – without having to think about all the possible fancy permutations.

And there are indeed fancy permutations – most enterprises will take advantage of Windows Azure’s excellent support for production and staging environments (the outer green box represents a subscription – a unit of billing which can contain multiple services):

Architecture is always driven by context. And a big part of a startup’s context is cost. The MSDN benefits in Bizspark include enough free Windows Azure resources to keep two instances running full time. While it might be super convenient and more “safe” to keep separate production and staging deployments running all the time, it’s not cost-effective for a startup on a tight budget.

A startup also needs to iterate quickly. You need to be able to have multiple versions of your site running at any one time so that you can perform A/B tests on the effects of various changes. In addition, you probably want a separation between your homepage and your “app” – and maybe even a separate site for administrative activities:

If you’re on your way to becoming the next facebook, it might make sense to put each site in a separate role … but you can support a significant amount of activity on a pair of instances, and you might as well use up all your free capacity before you start paying for more. It makes sense to run a bunch of sites on a single role.

There’s one more detail – most web solutions have some amount of background processing. The canonical way of doing this in Windows Azure is to have separate separate web roles and worker roles in the same service:

This is a great way to architect a solution – it provides for excellent resiliency and separation of concerns. However, it also adds more cost. Most startups can get by with a single web role that also contains the background processing:

In summary, if you own a web startup, you want to join Bizspark and use the MSDN benefits to get free Windows Azure compute resources. Your free resources are enough to run two instances full-time, so you want to get the most out of those instances. In practice, these means you are going to have a single role with two instances (two are required for high availability), and you are likely going to run several separate sites within that role. You are also going to run your background processing in the same role.

Implementation

To implement this architecture, I recommend running a synchronization process that lets you publish site changes by copying files to Windows Azure storage. This has two big benefits:

Site changes show up instantly (and you can rollback a bad change instantly as well)

For most website changes, you won’t have to change the role at all

If you’ve set up your role to support PHP, then you don’t need to change the role just to change some .php files. While using a separate staging environment is technically safer, you can justify running test and production in the same role so long as it’s really easy to rollback bad changes. The only time you really need to fire up a staging environment is if you’re installing support for a brand-new technology or doing something like upgrading PHP itself. Since that’s a fairly rare occurrence, you can just do this manually. Extra small instances cost 5 cents/hour, so it’s not much of a financial burden to upload a new deployment for a few hours when you do need to test with an increased level of safety.

But if you’re like me, you don’t want to work through all the details – you just want to get started. The best resource I’ve found for that came from IRhetoric. This post provides a zip file that has everything you need to get started developing php on Windows Azure.

To go past “getting started” and get closer to production-ready, I think at least two more things are needed:

A command-line utility for uploading files to Windows Azure Storage in order to deploy them (so they can be sync’d by the utility above)

Once running it looks something like this:

Using a zip file is handy for this sync process, because it makes uploading changes all-or-nothing. You could get fancy and do diffs, but I think it’s better to zip up whole sites – that makes it easier to rollback to previous versions if something goes wrong.

Progress

I’ve begun experimenting with an implementation of this … you can see what I’ve done by downloading this zip file. This is NOT production-quality code – I have not thoroughly tested it, and I haven’t implemented everything that’s needed (handling multiple sites, for example). This is just an example to give you an idea of what can be done.

Creating a command-line utility that can be added to your build script is fairly straightforward – just use the Windows Azure SDK for PHP and do something like this:

After I do a bit more exploring and testing, I’ll record a screencast showing how these things fit together. Eventually, I’d like to show an example that could be used as a complete, production-ready scaffold for a web startup. There are several additional items to check off before reaching production-ready:

Polish the sync utility (support for multiple sites, clean up old files, support for background processing, better error handling/tracing/logging, documentation)

Set up the role for Remote Desktop so that you can diagnose problems more easily (this can be a bit tricky the first time)

Develop a build script that handles source control and deployment (and strive for continuous integration)

Adopt reliable patterns for using SQL Azure and Windows Azure storage – potentially adopt different techniques for disposable development (prototyping) vs sustainable development

Adopt patterns for local storage for development and UX testing – can’t rely on the dev fabric, because it must also work on non-Windows environments

Adopt a reliable unit-testing practice for sustainable development

Test, test, test

Rinse and repeat for Ruby on Rails and Python (and whatever else startups seem to want)

I’ll keep experimenting, and I’ll write about these issues as I learn.

As I work through a “standard” architecture for web startups using Windows Azure, I can even envision automating the process of setting up and maintaining the Windows Azure role, similar to the way Windows Azure Companion works. It might even be possible to allow a simple Windows Azure role architecture to be enabled without ever requiring a developer to download the SDK – or even have to be on Windows. I envision a way to do that, but I have to work through the details.

If you’ve read this far and find this approach intriguing, I’d really like to hear from you. Feel free to leave a comment or email me at Patrick.Foley@microsoft.com. Let me know what you are working on and how I might be able to help.

I often hear from smart software developers who don’t yet have an idea to pursue. Andy Brice recently published a guest post from Joannes Vermorel with three really good ideas in the retail industry. If you are looking for an idea, read that post.

If you have more ideas than you can use, share them. Our industry needs more posts like that to help light a fire under some smart people who are still on the sidelines.

Does your company own a piece of web-based software? A product or utility written in .NET (or php, ruby, python, or java)? Simply check a box to verify that it works on Windows Azure, and Microsoft will send you a check for $250. Full details and terms here (notably, this offer is for US companies only and ends June 17), but I’ll summarize below. If you Know your app is already compatible with Windows Azure, this should take you less than 10 minutes.

Profile your app in Microsoft Platform Ready

Microsoft Platform Ready is a key resource for partners to get step-by-step guidance and support on our platform technologies. It also helps you test applications and earn Microsoft partner competencies.

If you have more than one app, please profile all of them (hey, it’s how I’m measured!), but only the first app you profile qualifies for the $250 (and you must be based in the US and verify compatibility between April 15 and June 17, as the terms state).

For each app that you profile, go to Test | Verify and check the box to verify that the app is compatible:

Finally, take a screenshot (Alt-PrtSc) of the following page after you verify compatibility and email it ALONG WITH YOUR PHYSICAL MAILING ADDRESS to appplatformready@microsoft.com, preferably using THIS TEMPLATE, before 6/21/2011 noon PDT (if you think of it, cc Patrick.Foley@microsoft.com so I know that you read about the offer here).

That’s it!

Again, only the first app qualifies for $250, but please verify all your apps that are compatible with Windows Azure.

More about Microsoft Platform Ready

Even without this incentive and even if your apps aren’t compatible yet, you should sign up for MPR (yes, of course we shorten it) and profile your apps anyway. Doing so gives you access to free email and phone technical support. If you want to go beyond self-verifying your applications, you can download the testing tool for Windows Azure, which will help you identify possible problems in your code. When your app is released and you have submitted the results of using the test tool, then you can qualify for the “Powered by Windows Azure” logo and earn points toward Microsoft Partner Network competencies. Similar benefits are available for our other platform technologies, including Windows Phone 7, Windows 7, SharePoint 2010, SQL Server, Windows Server 2008 R2, and more.

There is another, more subtle reason for profiling your apps in MPR – it makes you visible to Microsoft. There are thousands of ISVs in my part of the world alone (I work with software companies in the middle of the US). When we come out with new products or new features or marketing incentives of interest to ISVs, we use MPR to know who to connect to. If we don’t know you are working on Windows Azure, for example, we don’t know to reach out to you to offer help, ask for feedback, and to tell you about this easy way to earn $250.

How to try out Windows Azure for free

If you haven’t tried out Windows Azure yet, you should … the easiest way to do so is to go to www.windowsazurepass.com and use promo code PFOLEY. This will give you thirty days to experiment – no credit card required. If you are thrilled with what you find and want to keep going, you can even migrate that to a paying account (note that you get free Azure via MSDN – and you can get free access to MSDN via BizSpark).

There are a LOT of tutorials on developing for Windows Azure – start here if you are brand new (I’m a fan of the Training Kit in particular). For languages other than .NET, you’ll have to do a bit more upfront work to set things up (read the blogs of Steve Marx and Wade Wegner), but Windows Azure is still a great fit.

$250 is $250 …

I’ll be writing a lot more about moving applications to Windows Azure in the coming months, but if your app is currently compatible with Windows Azure, you might as well get that 250 bucks now. In fact, the offer is limited to the first 250 people who submit, so do it NOW! Follow the simple instructions above and email me at Patrick.Foley@microsoft.com if you have any issues.

About a month ago, I started a new role at Microsoft. I have the same title (ISV Architect Evangelist) and the same boss (Nathan Hancock), but my responsibilities are quite different. For the previous 4.5 years, I worked with 10 to 20 “managed ISVs” – software companies who are large enough that if they switched from Microsoft to one of our competitors or vice versa, it would have a noticeable effect on our revenue somewhere down the line. Now I work with everyone else – the 6,000 or so “unmanaged ISVs” in the middle of the US. The effect of any one of these software companies adopting our platform might not be immediately noticeable, but the cumulative effect certainly is. That’s why Microsoft invests in my role.

So what do I do? Simple. I help software companies. It doesn’t matter whether you use our technologies or not – I’m here to help.

My role is mostly technical (my background is as a developer and architect), but a lot of the challenges facing software companies are business related (“what’s the right way to license xyz from Microsoft” or “how should I monetize this functionality” or “why should I use the cloud”) – I help with those, too.

For the foreseeable future, I’m focused on our cloud offering, the Windows Azure platform (which includes SQL Azure and Windows Azure AppFabric). It’s an offering I’m quite passionate about, so it’s easy for me to rally ISVs to support it. Most of the things I’ll be writing and speaking about over the next year or so will be related to Windows Azure and how it can help software companies succeed.

Because I need to reach thousands of software companies, Microsoft has several programs that allow me to “scale,” including

Microsoft Platform Ready – the place for partners to get step-by-step guidance and support on Microsoft platform technologies

BizSpark – the way for startups to become partners and get no-cost access to Microsoft technologies for three years

Sometimes it can be confusing to navigate all our different resources, so I like to think that I put a human face in front of these programs. If you wonder what programs are right for you, don’t hesitate to ask me – Patrick.Foley@microsoft.com.

I’m based in Grand Rapids, Michigan and primarily serve the Central Region of the US:

I have peers who do what I do in the East and West and in other countries around the world. In case you are curious, the region is divided into sales districts as well, colored on the map: South Central (orange), North Central (yellow), Midwest (green), and Heartland (blue). I serve the whole region.

At Microsoft, we measure what we do, and we put those measurements into yearly commitments – for the rest of this fiscal year (which ends in June), I am measured by how many partners in the Central region profile applications that are compatible with Windows Azure in Microsoft Platform Ready – I will blog about what that means for you soon, but that’s how my boss will evaluate my effectiveness this fiscal year (though it is only a couple of months long for me). Next year, we’ll probably adjust that measurement a bit.

A quick aside on commitments … it’s easy to measure the effectiveness of sales people, because money is a really good way to keep score – it ultimately rolls up to regulated income statements, so sales estimates (goals) HAVE to be tracked for public corporations. For people who don’t bring in direct revenue, it’s harder to find a suitable measurement. Joel Spolsky argues cogently that companies shouldn’t even try. Management by Objectives is deeply ingrained in Microsoft culture, so we try our best anyway.

One last thing about my role – a few weeks ago, my twitter friend Sasmito Adibowo questioned how I can give advice to startups and small software companies when I work for the largest software company in the world. I think that’s a fair point – I haven’t delivered code into production for a couple of years now, and I haven’t worked on a startup or small software company for several years. I have never been the driving force behind a true software startup (though I did build a small consulting company). I have learned an enormous amount from working with successful software companies of all sizes in my role as an evangelist and through interviews on the Startup Success Podcast. Still, I lack the credibility that can only come with building a successful software company from scratch. I’m more like a food critic than a chef.

Sometimes I feel a tug to leave and start my own company, but that’s not going to happen anytime soon. I really like working for Microsoft, and at the moment I think I can make a bigger impact here than on my own. I also have a wife and an eight-year-old son, and my family has grown to appreciate the stability that comes from working for a large, successful company.

I still want to create software, and I want the real-world credibility of building my own company, so I plan to follow in Patrick McKenzie’s footsteps and build a MicroISV as a side project (Patrick was eventually successful enough to quit his day job). Microsoft is surprisingly cool about this. I have lots of ideas, but whatever I do will definitely involve Windows Azure and will probably involve Windows Phone. Unfortunately, I’m not as disciplined as Patrick McKenzie, so I have nothing to show for my efforts, yet. It might take me a while to get off the ground, but I won’t give up. And of course, I’ll write about it here.

In the meantime, remember – if you work for a software company, don’t hesitate to reach out to me. I will do my best to help.