df0ddea8f72abd57eb4c…

Geva Perry
GigaSpaces

The notion of an auction-driven model for pricing CPU power within a bank is interesting. The pendulum has definitely swung back towards centralisation of compute resources. I wonder if we would end up seeing an internal options market for CPU time in an investment bank that developed this type of grid…

What I’d like to see is for larger banks to copy these sorts of technologies internally. 1) I like the model of Slicehost, being able to get a VM, IP address and such in under a minute, complete with backups if you want. Having a system like this could save months off ordering hardware, waiting for it to arrive, and get build, etc.. 2) EC2 charges a fixed price per VM per hour. I could see a different auction based model, that would allow for various business within a bank to share the compute grid for calculations. Businesses need different amounts of CPU power, and at different times. In most somewhat mature computing grids, you end up with different priorities of calculations. If a user presses ‘reprice’, you may want the result calculated as soon as possible. However, for a security which you don’t have a position in, having the system calculate a price once a day is acceptable. Other businesses need lots of CPU during trading hours, and none outside. The peak demand periods would basically pay for the cost of new hardware, and the relatively idle periods would pay to keep the machines on and powered.

Amazon recently allowed you to select a data center location. Right now they only have US east and west coasts, but hopefully they add other location soon as well.

I’d be real interested in Google’s BigTable being made available. The Google Code site has about 6-8 developers on it, and it manages 90,000 projects right now. They haven’t needed a whole lot of staff, because they’ve been able to use other Google technologies, like BigTable.

Great presentation! Thanks for putting it up, it’s definitely been enlightening.

I’m looking forward to having some bandwidth to play around with this and come up with some demos for folks at work!

Thanks for taking a look at Resolver One! A couple of thoughts:

To confirm what you may have suspected - we’re not looking to replace Excel in general, just to provide an “upgrade path” for the people who are building spreadsheets that are large enough that the issues with grid/code interaction start arising, but don’t want to start full-on programming. However…
We’re certainly interested in working out a way to get Resolver One to act as something like a replacement for the recalc engine inside Excel - that is, using Excel as a front-end but replacing the back-end. When we’ve looked at this in the past, it didn’t look doable - perhaps things will have changed with VSTO, though.
Converting VBA to Python is certainly something we’ve considered; my own gut feeling is that we’re unlikely to be able to get a conversion that produces decent, maintainable code, but you never know. I suspect this will be client-driven - if people tell us “we *will* buy Resolver One if it does that” then we’ll do it, but otherwise we won’t Of course, for this to work well in many cases we’d also have to support Excel’s addins. This scares me…
For grid computing - this is certainly something we’re keen on looking at in the medium to long term. Interestingly, one of the guys at Digipede (who I believe are a DataSynpase competitor) tried using their product with Resolver One in quite the opposite direction - instead of building a model in Resolver One and then distributing it across a grid, he used Resolver One as a front end and data manipulation tool to access a pre-existing .NET/distributed infrastructure. Here’s his blog post about it: http://westcoastgrid.blogspot.com/2008/01/hey-excel-resolverone-understands-net.html
Re: Visual Studio Shell - I’m sure we could go in this direction, and it would save us a lot of time. We do worry, though, that it would pretty much block off later creation of a Linux version: VS is a windows-native application, so it would stop anyone from running Resolver One under Mono. That said, the grid component we’re using at the moment isn’t Mono-compatible, so it’s a moot point. We’ll have to see what happens there.

Anyway, thanks again for looking at the product - I hope the above is of interest!

Regards,

Giles