Friday, December 14, 2007

Microsoft forecast: partly cloudy

In a previous post I asked Where is the Microsoft cloud? That is, where is the Microsoft competitive offering to Amazon's AWS, for example.


So far, I've found mostly hot air. BizTalk Services is interesting, but still very much in the early stages. Certainly worth keeping an eye on. But branding it under the BizTalk name seems very odd - these are fundamental services like authentication, access control, & connectivity - and not tied specifically to BizTalk.


I have to say that I'm not getting the great sense of urgency from Microsoft about cloud computing that Nick Malik's "Microsoft is coming" bravado suggests.

Now, Microsoft is certainly talking a lot about cloud computing - has been for the last 6 months. From a NetworkWorld article:
Microsoft also plans later this year to launch Version 1 of a 12- to 24-month project to create Windows Live Cloud Infrastructure Services, Web-based services such as directory, identity and storage. The operating system services target companies and developers, who will wrap them around their applications, such as tapping an online directory service to generate a Kerberos ticket that a user would present to gain access to an on-premises or service-based application.

Which all sounds like goodness. But that article was written in July. End of the year is only a couple of weeks away. Did I miss that Version 1 release announcement? Maybe they were talking in Friedman Units.

Can a project of this magnitude be even only 24 months away when Cloud Infrastructure Services is still just a Microsoft research project with a rather nebulous vision?

And if putting announcements with titles like "Microsoft Does Have a SOA Strategy" on your main SOA page is meant to inspire confidence, well...

Thursday, December 13, 2007

When a service isn't the answer

I was discussing a rather involved design issue with a colleague recently, and as I pulled away from the diagram I had drawn out as we were talking it over, I said, "Surely someone else has already dealt with these issues. There must be a 3rd party service we could use that would handle all of this for us."

"There is," my colleague said, "but they'll charge for every transaction, which can't be written off. If we build it ourselves then the costs are a capital expense and the cost can be depreciated."

And so it goes.

Monday, December 10, 2007

Distributed state management for ASP.NET

The more I delve into distributed architectures, the more I'm feeling like Microsoft just isn't providing much of a path forward to scalable distributed systems. Case in point: state management.

By default, session state in ASP.NET is stored in the web server's memory. To share state across servers - which you would want to do in a server farm - you need to store it in SQL Server or in the .NET state service. This is fine for small solutions, but once you bump up against the need to partition state across many servers or multiple hosting locations, things start to get complex and expensive.

Now, it seems the Java folks have worked through these issues already. Here I'm thinking of Space-Based Architecture and more concretely JavaSpaces.

Perhaps I'm oversimplifying, but wouldn't JavaSpaces be a perfect place to store session state in a distributed system? Data in a JavaSpace is persistent, atomic, distributed, & fault tolerant.

There isn't a .NET equivalent of JavaSpaces. But, MS does provide SessionStateStoreProviderBase and the ability to choose a custom provider for session state.

So, here's the recipe as I see it:
  1. Set up a JavaSpaces instance on a Linux cluster (probably using Blitz to start out with)
  2. Write a custom state provider that inherits from SessionStateStoreProviderBase and implements the necessary JavaSpaces methods. (Working out the bridging between .NET & JavaSpaces, of course. There is a tantalizing page called Using JavaSpaces from .NET - but it relies on a commercial product to accomplish this.)
  3. Change your ASP.NET web.config to point at your new custom state provider.
These don't appear to be big hurdles to overcome, and it seems like a nice little open source project.

(In the interest of due diligence, I did run across 2 commercial software products that seem to be solving this kind of problem: ScaleOut and NCache. But for a server farm of 20 servers, you're looking at something in the neighborhood of $30K, not including the cost of the Windows Server licenses + ongoing annual maintenance fees. There is also GigaSpaces, which provides hosted JavaSpaces and has a .NET API, but is also expensive.)


Here are some links I found useful in my research:

Tuesday, December 4, 2007

Where is the Microsoft cloud?

I've been doing heavy research lately into scalable distributed systems, and Amazon's S3 and EC2 are front and center in my brain as I'm working my way through the literature.

Amazon's AWS and now IBM's BlueCloud are out in front with cloud computing offerings. Google may or may not be planning something akin to S3 with Google shared storage combined with APIs.


In the midst of my research, I saw that Microsoft has a codename - Oslo - for their next iteration of SOA tools. And so the obvious question (to me, at least) is: where is Microsoft's cloud computing offering?

Well, looks like BizTalk Services may be Microsoft's response. Charles Young has an overview of his early experiences with it.

Looks like I have more research to do...

Thursday, November 29, 2007

You get what you give

Brian Sommer asks Why are we paying bonuses? He's reporting on the frustration among executives over bonuses as entitlements, mercenary employees, how to motivate employees, and diminishing consulting skills in the workforce. Which is a lot of ground to cover in a single post.

What stuck with me most was Brian's description of local Chicago execs complaining about their employees increasingly having a "what's in it for me" attitude.

Ok. Forgive me for not feeling the executives' pain here, but what exactly do these execs expect to happen when their businesses reward loyalty and job tenure with... what?

Let's list the disincentives mainstream contemporary US businesses have come up with:
If a company's hiring policies lead it to mostly hire rational people, then the rational and expected response to these disincentives is a mercenary attitude. To paraphrase John Maynard Keynes, when the incentives change, I change my behavior. What do you do?

This is what the "ownership society" looks like - and it looks an awful lot like every man for himself. I've got mine... and good luck to you.

Today's NY Times has an article that touches on this topic and, frankly, made me sad when I read it. What Do I Do? Depends on What Week It Is describes Sean Aiken's quest to work a different job every week for a year and is chronicled on oneweekjob.com.

But here's the part that broke my heart (emphasis mine):

The 20-somethings who turn to One Week Job find in Mr. Aiken “an ideal of the unstable life,” says Penelope Trunk, the author of “The Brazen Careerist” (Business Plus, 2007), who blogs and lectures on the transformation of the workplace. “He sends the message ‘job-hopping is O.K.,’ ‘moving around is O.K.’”

That is a comforting message, she says, because while Gen Y talks of seeking passion and embracing what is new, that is just brave cover for a less comfortable truth. “The reality is they might prefer one job that would last forever and end with retirement, but that kind of job doesn’t exist anymore,” Ms. Trunk says. “The alternative, the instability, terrifies them. Sean Aiken is an example of how uncertainty and constant change can be O.K..”

No, the job-for-life doesn't exist anymore. That's the reality right now, and maybe forever. But it's a reality based on choices. And those choices have consequences. So execs, if your employees have a mercenary attitude, then you should be asking yourselves what is driving that response. It's not character defects. It's not a few bad apples. And it's not because people were just better back in the good old days.

You get what you give.

Photo: Good and Bad by vees

Wednesday, November 28, 2007

SOA for SAP

SAP has an interesting message on SOA, if I'm reading Joe McKendrick right on this - you can use SAP's SOA methods while starting out small as a subscriber to their SaaS offering, and then scale up to their enterprise offering later, in what would certainly be advertised as a "seamless transition."

This is precisely the sort of thing that a consistent architecture should allow. Of course, it cuts both ways - you could also (theoretically) move from SAP's enterprise offering to their SaaS offering. Or more interestingly, move to a competitor who offers the same set of SAP-compatible methods.

What, exactly, would prevent Oracle from offering a set of SAP-compatible methods? And who will be the first to try to claim intellectual property rights on a URL? Is http://mycompany.com/services/sap/adduser© right around the corner?

Once there is a significant set of companies who have committed to a particular vendor's SOA methods, they're also primed for another vendor to come sniffing around with a translation layer and lower pricing.

Tuesday, November 27, 2007

How eBay Scales Up


Here are a couple of presentations giving an overview of eBay's architectural approach and reviewing how the architecture has evolved.


Of note:
  • No session state in application tier (use URL/cookie/scratch DB)

  • No business logic in DB & no stored procedures

  • Partition everything - if you can't split it, you can't scale it

  • Async everywhere via message bus & periodic batch processes

  • Everything fails sometime, so all operations must be fault-tolerant

I manage an ecommerce site that has a single centralized DB (I inherited this architecture when I took it over). That single unpartionable DB is a HUGE headache, and eBay's architecture has me thinking... can I get rid of the DB altogether except as a reporting mechanism?

We know we need to be able to split the DB across multiple geographic sites soon. But this DB stores user account information and orders - so, why use a DB at all? Why not store user account info and order info in XML files in the file system, index them with Lucene for searching, and use async messaging to report order info to other systems that need to know (fulfillment, reporting)? I'm simplifying, of course, but in broad strokes this should work and scale very nicely.