As I mentioned here, I’m exploring the viability of Python as a way of programming the newly-announced Microsoft cloud platform, Azure. Partly that’s because I love Python, but mainly it’s because I believe that the culture surrounding Python and other open source dynamic languages can fruitfully cross-pollinate with the culture that infuses Microsoft’s platforms.
One of the reasons these cultures face each other across a great divide is religious attachment to low-level operating systems. In the cloud, though, the differences among these low-level systems are increasingly hidden behind interfaces to higher-order constructs: compute nodes, storage objects. These, in turn, are building blocks for still-higher-order services that will be created — and consumed — both by platform vendors and by the developers who are their customers.
It becomes possible, in this new world, for platforms to support a continuum of access styles. You want object-oriented? Do it that way. RESTful? Go for it. You know the Python or Ruby libraries best? Use them. The .NET Framework? Use that. Or even mix and match according to convenience and taste.
Consider this Python module written by Sriram Krishnan, which wraps the RESTful interface to Azure blobs. It’s written in standard Python, using OpenSSL-based cryptography. When I tried it on my machine, though, I ran into an inconsistency in my local Python installation.
Normally a Python developer would debug and fix the installation. But I was planning to deploy this module in IronPython on Azure, and IronPython doesn’t run compiled modules such as OpenSSL. It can, of course, use equivalent .NET functionality — in this case, the method implementing the SHA-256 flavor of keyed-Hash Message Authentication Code. So I made that small change.
At this point, having eliminated my module’s only dependency on unmanaged code, I thought I could run it in the Azure development fabric, and then deploy it to the Azure cloud. But no. Azure’s security model currently won’t allow Python even to import pure-Python modules at runtime. A wacky solution might be to use Python’s custom import mechanism to load those modules over the network. More practically, the modules might be provisioned into Azure.
I don’t know how this will play out. Meanwhile, there’s another option: Eliminate all use of Python modules, and rely only on the .NET Framework. So as an experiment, I switched over from Python’s minidom, httplib, time, and base64 modules to their .NET equivalents.
The good news is that this works. I can deploy the module to Azure, and use it in the cloud. The bad news is that, in some cases, I’d rather use the standard Python modules. The .NET equivalent to Python’s httplib, for example, is the HttpWebRequest/HttpWebResponse pair. But these APIs differ from those provided by httplib in a couple of ways that annoy me.
First, there’s an inconsistency in the way headers are handled. You get and set most headers using the Headers collection. But you get and set a few special ones, like Content-Type and Content-Length, using special named properties.
Second, status codes are handled inconsistently. Most responses return status codes. But for codes in the 4xx series, an exception is thrown.
To me these behaviors are quirks that make it trickier to create RESTful interfaces. I’m sure there are reasons for them, and people who prefer them for those reasons, but I’d rather just use httplib. In any case, if both styles are available, there’s no need to argue. Everybody gets what they need.
We’re not there yet in the current Azure preview. Those of us chomping at the bit to run IronPython in the cloud will have to be inventive. I expect things will get easier as both Azure and IronPython mature, and as Python technologies like Django and NWSGI are — I hope — woven into the fabric.
Why might this matter? Again, I’m looking for cross-pollination. Python culture will be able to make really productive use of higher-order Azure services such as identity, access control, workflow, Live Services. And it will also exert a positive influence on the future evolution of the Azure platform.
November 26, 2008 at 12:43 am
A reasonable solution would be to implement the httplib API around the .NET services. This is what I did for the App Engine environment (https://appengine-monkey.googlecode.com/svn/trunk/module-replacements/httplib.py) to get around their unnecessarily quirky urlfetch library. As a side benefit, if you accurately implement the httplib interface all the other interfaces built on it (urllib/2, httplib2) also work.
November 26, 2008 at 6:20 am
“A reasonable solution would be to implement the httplib API around the .NET services.”
True. I’m hoping, though, that an acceptable way can be found to provision the standard pure-Python modules which, outside of Azure, IronPython can happily use.
November 26, 2008 at 8:11 am
“One of the reasons these cultures face each other across a great divide is religious attachment to low-level operating systems.”
Hmm. This is making a strawman of deep and serious differences. Microsoft may be slowly changing for the better, but it has been bad for very long. Not least for just this kind of disingenuous misdirection. Not like you at all.
November 26, 2008 at 8:32 am
“disingenuous misdirection”
Why? We’re through the looking glass now, it seems to me. Who would have thought, 3 years ago, that today you could buy Linux in the cloud, or Windows in the cloud, from Amazon?
All I’m saying here is that in this fungible environment, cultural cross-pollination can happen more easily.
What I have /always/ said is that mixing the best of different cultures is a good strategy.
December 2, 2008 at 12:42 am
“We’re through the looking glass now, it seems to me.”
No way. Quote from Zooko:
“”"
My presentation on Tahoe went well. At the end a fellow named Zhuowei Li, who works on Microsoft Azure, raised his hand to ask a question. [...] “How do you keep track of all the users’s files, to see if they have some bad files like pornography or something in case the police ask for it?”.
“Well, uh…” I hesitated for a second, “in general, we don’t. [...]”
“But you have to!”, he exclaimed.
“What? Why?”
“Legal tells me that we have to keep a catalog of files such as pornography so for example if the FBI comes.”
“”" https://zooko.com/log-2008.html#d2008-11-13
There’s also Microsoft’s shameful role in the office document format standardisation effort. This was prolonged and global. An eloquent testimony on the costs of their strategy from India:
http://deepakphatak.blogspot.com/2008/05/this-is.html
Similar stories played out in many countries.
There’s also Microsoft’s involvement with the OLPC. If they had joined to make Sugar better, they would have won a lot of people over. Or even if they helped port Sugar to Windows and offered it as an alternative. But they didn’t. They moved in with the goal of displacing the primary OS of the OLPC, and getting Windows on there, no matter what the costs, treating the philosophy of the project with contempt, and without the slightest intention of listening to opposing voices. A good, if rather tortured, screed on the troubled project is here (worthwhile discussion in comments):
http://radian.org/notebook/sic-transit-gloria-laptopi
My issue was with your characterisation of wariness of Microsoft as due to a quaint “religious attachment to low-level operating systems”. It’s not. It’s due to a culture valuing self-determination and independence in opposition to the sociopathic culture of a corporation. I’m not talking about the many great people at Microsoft who are changing it from the inside. I’m talking about the continuing behaviour of the corporation.
(Links to the “sociopathic corporation” idea:
http://www.amazon.com/review/RAF8IGRQOON0E
http://en.wikipedia.org/wiki/Psychopathy
)
No one should argue that “mixing the best of different cultures is a good strategy”, but it’s not a love-in. It’s a wary approach against a history of hurt. It’s not a meeting of equals. It’s exploring how to coexist with a powerful corporation without getting wiped out.
January 22, 2009 at 12:01 pm
[...] success and failure in .NET Posted by Jon Udell under Uncategorized In an earlier installment of the azure+elmcity series I griped about some inconsistencies in how the .NET Framework deals [...]