Read the open letter to insideHPC readers.
Pure mudslinging about conflicts of interest based on things that don’t seem to be true. I won’t mention the mudslinger, but I can tell you that if I bothered to read that other blog — which I don’t — I would unsubscribe.
Build your brand on merit like InsideHPC did, not on publicity stunts.
PDC10 is coming up in late October. I signed up for it knowing it was Azure-centric, but I am glad to see that there is also a .NET track. I hope this will include non-Azure server side technologies (e.g., EF, AppFabric for Windows Server and the like). Of course these other pieces all have their place (or counterparts) in Azure, but I don’t think I’ll be using Azure directly over the next year.
PDC’s are quite valuable to attend (access to Microsoft product teams, exposure to their roadmap, opportunity for light-bulb” moments, etc). That said, I may decide not to go after the session list is released – a simple balancing of priorities.
Anyway, I’ll likely keep my registration – I would actually love it if Microsoft could change my plans about Azure this October.
Are you going? Or not? If so, please share your reasons.
We recently released the Digipede Network 2.4. Among other things, this release provides support for hosting .NET 4 applications, some new features to improve management and control, and enhanced server-side performance. The entire list and downloads are available on the community site. You can read more about it on the Interwebs:
Those paying close attention might ask "what happened to 2.3?" The answer is Digipede trivia.
The actual reason dates back to the days when .NET 2 was released. Back then, we were ready to release Digipede Network 1.1 with .NET 2 support. To avoid naming confusion with .NET 1.1, we decided to skip the “.1” and went straight to “.2”. Was it in fact less confusing? Probably not materialy.
So, why no 2.3? It is an ever so slight (and obscure) homage to those early days: for .NET 4 we decided to release something that ends in “.4”.
Like I said: trivia.
Lots of improvements to EF for 4.0:
Pandelis, what do you think?
Tags: .NET4.0, Entity Framework, PDC09, PDC2009
At last year’s PDC, I posted
It is the openness of this platform, the ability of developers to mix and match the different components, and to do it between the cloud and in-premises solutions that makes this such a winner.
This last point is an important one. Microsoft is in a unique position to help enterprise IT bridge to the cloud. While I don’t think Amazon and Google will cede that market to Microsoft, their current offerings aren’t a natural fit.
The offering was rich then, but since then Microsoft has continued to push these offerings forward dramatically.
At the time, my biggest concerns were the one-size-fits-all approach to their provisioning model and their lack of full trust (two things that could make it harder to deploy the Digipede Network onto Azure). Today those issues have been taken off the table and help support many more use cases, opening up Azure even more to non-Microsoft technologies and fortifying the extremely important IT bridge.
So what are the improvements in openness?
Allowing full trust opens up the door to, well anything. Unmanaged code, PHP, MySQL, Java, TomCat, etc. can all run on Azure. Matt Mullenweg of Automattic demonstrated a WordPress instance running that way. Kind of anti-climactic, because it would have been a big deal if wordpress.com was moving to Azure. Simply running a WordPress instance isn’t really that interesting.
Custom VM images are also coming to Azure which will make it much easier to put whatever you want on a VM and deploy it efficiently.
For IT?
Too many items here to enumerate. SQL Azure integrating into SSMS; Azure integrating into MOM; SQL synchronizing with cloud instances; (this list really does go on and on . . .).
Another important part of this IT bridge? Not Microsoft’s new App Server, AppFabric. Though I am excited about this – it is something that has been missing from the Microsoft stack – the key point here is that it runs on premises and in Azure.
Conclusion?
These new features in Azure push Microsoft out even further than the other cloud vendors. No one else has the depth and breadth in tool support and service offerings. No one else is innovating so quickly on so many parallel fronts.
Will Amazon and Google cede the space? Of course not, but I think they’ll need to reposition their cloud brands.
As I noted recently, I have been working with Giles Thomas and Glenn Jones at Resolver Systems on a sample mixing distributed IronPython objects with Resolver One spreadsheets.
I like those guys. They are smart and do excellent work.
Anyway, they released the sample earlier today. From their site:
As of version 1.5 (which is currently in beta), the world’s coolest spreadsheet can use Digipede Network grid computing to distribute and execute workbooks in parallel. The example on the Exchange is based on the excellent IronPython sample created by Robert W. Anderson of Digipede. The Digipede Network is a brilliant way to get distributed, parallel computation on Windows. It only took a few minor changes to convert Resolver One to run on the Digipede Network and to get the IronPython sample to execute Resolver One workbooks.
Giles gives some more background to the path that got us here on his recent post, Resolver One and Digipede.
The combination of our two products offers a pretty elegant solution. Like I said before,
Try doing that with a spreadsheet or grid that isn’t based on .NET . . .
. . . like Excel and Windows HPC Server. No, don’t. Trust me. It is really hard, complex, and brittle.
Tags: Digipede, Excel, grid, HPC, IronPython, ResolverOne
We had a call this morning with Giles Thomas and Glenn Jones of Resolver Systems. They demonstrated Resolver One running on the Digipede Network.
They used my IronPython Worker sample and customized the front-end Python code, leaving the C# adapter as-is. With very little coding they had an elegant grid-enabled spreadsheet. Try doing that with a spreadsheet or grid that isn’t based on .NET . . .
Giles said they will have support for this in Resolver One 1.5, coming out in the next couple of weeks.
Very cool.
I’ve just installed Resolver One to take a closer look. Already I’m impressed, but I’ll leave that for a future post.
Tags: Digipede, Excel, IronPython, Python, ResolverOne
. . . or IronPython-ipede (Part II).
I have been playing with IronPython a little. With the release of Digipede Network 2.2, I am now able to post the sample I wrote. It shows how to distribute IronPython objects on the Digipede Network. You can find it on the Digipede community site. See the posting there for details and download instructions.
The sample uses IronPython 2.0.1 and the included version of the Microsoft Dynamic Language Runtime (DLR). While I focused on IronPython in this sample, it would be pretty easy to expand it to support other DLR-based languages.
Comments welcome. I am specifically interested in feedback on DLR integration and initializing ScriptScope objects for each worker thread. It seems that I should be able to do some of this only once at global scope.
By the way, one thing I like about this sample is that it shows how to keep user code completely de-coupled from the Digipede Network while still taking advantage of our deployment and payload distribution model. This has always been supported by the Digipede Network, and this makes a good example.
Tags: .NET, Digipede, DLR, IronPython, Python
I’ll be at the University of California, Berkeley EECS Annual Research Symposium (BEARS 2009) tomorrow, February 12th.
Looks like it will be an interesting program.
If you are going and want to meet up, email me at robert at digipede dot net.
I have been taking a closer look at IronPython for a prospective customer. Never being happy with “shoulds”, I am going to show how to distribute IronPython objects on the Digipede Network.
The first thing I did get our old Python sample running in IronPython. This was the first user-contributed sample (thanks to Sean True). That sample (see it here) uses Python COM libraries to invoke a job with the Digipede Network COM APIs. This didn’t submit objects, just executed a command-line application.
I’m happy to say that the code required very little modification to run under IronPython. The only difference is in the syntax of the “import” commands. Kudos to the IronPython team.
I’ll post the working code once I get a little farther.
Next step: distribute IronPython objects. Fairly straightforward, but I’ll write a reusable C# Executive to load the IronPython class definition.
Tags: .NET, Digipede, IronPython
FriendFeed Status
About me
Main feed
Email subscriptions