Two or three years ago I became a Mac user again. I bought a Mac Mini to complement my iPhone which I wanted to write software for. This plan went forward, up until I quit my job and I decided to focus on my core technical strengths which are in programming on the Windows platform with .NET Framework and Visual Studio. Since then, that Mac has just been sitting in my home office, running quietly as an always-available little machine that I can sit down in front of at any time and tinker with. I don’t, usually, not anymore, since I have no need. But there it is.
There are now some things that I miss about “living on” my Mac for those few months, and some things that I don’t. Overall, some of the longest-running strengths that the Mac has over Windows still ring true today, the most notable of which is this: The Mac strives to be simple and easy to use up front, and getting to advanced configuration settings requires as much as, or even more than, two levels of depth versus what Linux and Windows often impose on the outset, but once you learn the basics of where to go to get to the advanced configurations and properties it’s as simple as it was on Linux and Windows. But on the forefront, whatever it is, whatever application you are using, whatever service you are installing, the Mac workflow is so simple it’s practically silly.
With Microsoft software, prioritization for simplicity is strictly based on how stupid the user is supposed to be. If the user is supposed to be a stupid consumer end user with absolutely no brain or thought power or an IQ of 72, well, Windows Live applications attempt (more or less) to demonstrate how to make powerful desktop software highly usable. But the further you get towards the enterprise environment, and the closer you get to the back end, the more frustrating the experience is going to be. Microsoft Office compared to Windows Live applications is just one tiny little step towards chaos. You have all these gobs and gobs of features and Microsoft has to figure out how to prioritize the features for the end user and make the most obvious features available up front while the lesser-used features are tucked away. Enter the Office ribbon, which we all know about.
But now lets go further back towards the back-end or low-end of software. A lot further back. Let’s look at BizTalk. Yeah. No wait, scratch BizTalk, that thing is such a pile of gobblygook with its own horrible reputation that I was never able to even look at it much less give discovering it a try. Let’s look at AppFabric.
So a few weeks ago my boss and I sat down to see if we could replace the ASP.NET Session State service with AppFabric. It was a flop. We couldn’t get it running. We didn’t try very long—maybe thirty minutes. But that was long enough to call it quits and declare it a failed install. Everything about this process was so incredibly representative of Microsoft thinking in terms of, “We don’t need no stinkin’ Apple-thinkin’ when we’re runnin’ apps for engineerin’.” Unlike Apple, who understands that both simple apps and advanced services must be consumed by human beings, Microsoft simply cannot handle such concepts as obvious defaults and ugly-free self-configuration (where ugly-free means changing the self-configuration does not mean digging through gobs and gobs of nasty GUIDified keys in the Windows registry).
Failsauce #1: The Download.
(Good lord that’s one ugly URL. Here: http://tinyurl.com/downloadappfabric1-0 Seriously, Microsoft, quit exposing ugly URLs to us like that, at least try.)
Microsoft created separate installers for different environments. If you have Windows Server 2008, you need to download a completely different installer than if you have Windows Server 2008 R2. That’s right. Microsoft could not possibly bundle an all-in-one package because that would mean an almost 100MB download instead of an almost 50MB download. I’m not sure where the fail point is here, that separate binaries were created for these environments (really why not just use logic in code to self-configure for the environment?), that the marketing team gave “R2” its ridiculous name when it is an incompatible OS, or that there was no direct downloader installer app to download the correct binaries. To be fair, on the latter note, Microsoft does offer the “Web Platform Installer,” but co-workers at the office seem to get reaming mad when they have to download a generic multi-use installer since it exposes certain undesirable security and/or stability risks to the production server environment (i.e. rogue installations of “extra features”, etc).
Failsauce #2: Having prerequisite user actions in advance.
Seriously, don’t download and install AppFabric until you’ve read the Getting Started guide because there are things that you must do before you install that will hurt you if you don’t. And don’t plan on the Getting Started guide to be adequate for your preparations because you need to understand the product before you can make decisions about your preconfiguration. But don’t plan on reading up on it without having it working in front of you as you learn so you can experiment and discover how the features are used. But don’t plan on having it working in front of you so that you can learn because you have to have it installed first, and you can’t get it installed if it’s not preconfigured. Yeah. This is where we get the BSOD with the message “infinite user logic loop at preconfiguration 0x27591772”.
The prerequisite actions that must be made relate to setting up a Windows share, creating Active Directory accounts and giving rights to the share, and so on and so forth. Seriously, this is stuff that should be checkbox-enabled to be auto-configured by the installer, NOT pre-configured by the user!
We waded through the installation wizard and dealt with these preconfiguration details as we hit each roadblock in the wizard. This was our learning process, and it’s pretty conventional, folks. But unfortunately the wizard seemed to get somewhat unstable as it kept failing—the wizard didn’t crash, but the results seemed to be somehow corrupt.
Failsauce #3: Manual client configuration
After we spent at least five or ten minutes trying to set up a share to get past various steps in the installation wizard and dealt with some weirdness in functionality where errors occurred because we hadn’t set up the ACL for the directory, etc., we then looked at our app to try to figure out how to point to it for management of ASP.NET session state. We didn’t know what to do to make this happen—surely a web.config entry needed to be made in our app? We spent some time digging around at Microsoft’s web site to find where a web.config entry is described to enable AppFabric as the session state service. OK, here’s the fail point: If you’re running a wizard to set up a distributed session state service, then you automatically know that there will be consumers of this service, so put consuming app configuration in the wizard!! Providing a wizard for the service but not providing a wizard for the consumer is not only half-baked, it’s also back asswards, because if you’re going to have a ridiculous standard of having crappier user interfaces the further to the back-end you go then the back-end in this case is the service, not the client (the consuming web app), so if you’re going to “wizardize” this stuff then don’t stop with the service, have a wizard also update the web.config of the consuming ASP.NET app too as well as drop in any required binaries if required.
Failsauce #4: Broken GAC registrations and broken self-configured initialization
Even after we tracked down the documentation from Microsoft’s web site, it still didn’t work. Now it’s possible that the documentation has since changed (now it’s at ..
..) since we started on this just a short time (hours? days?) after v1.0’s release, but at the time our web app just plain couldn’t find the AppFabric assemblies described in the web.config. I believe the documentation lacked the proper strong-name description for configuring the app sections, or something similar, the assembly name was just the namespace and class name, and even that didn’t seem to match, perhaps the documentation was really, really stale at the time. So I proposed that we find the GAC-referenced binaries from Program Files and copy them into the bin directory, perhaps that might suffice.
Yeah, sure enough, the namespaces were wrong and stale, or somesuch. We waded through C:\Windows\assembly, scoured for DLLs in the Common Files directory in C:\Program Files, etc. That took us a long time since we weren’t sure what assembly name replaced the stale assembly name in the stale documentation, but long story short it ultimately did not work and after at least ten more minutes or so we just decided at this point to give up.
That evening my Twitter feed got updated a couple posts with #AppFabricSucks hashtag. That’s how this whole crappy experience made me feel.
What should have happened
Here’s what I think should have happened.
- Archaic configuration-oriented design. AppFabric should be an election-based distributed service. It should broadcast a request to find a controller over the subnet via UDP, with a callback URI readily available to handle “Im ur god pray to me” responses. Multiple deployments of the same service should be able to auto-negotiate an authority controller via automated election (yes, election .. as in, self-nominees, and votes). The controller should receive and redistribute data writes. If the controller dies suddenly, timeouts occur, which should result in re-performing the auto-negotiation/election process again. Likewise, if the controller is gracefully shut down, the auto-negotiation/election process occurs again.
- Installation should have offered auto-deployment of Windows shares, automatically set up the ACL, and even offer up a GUI for setting up a web app to use AppFabric for session state. The details of all of these should have been user-customizable but optionally so.
- Documentation, where required, should have been synchronized with the binaries’ deployment and not be stale at launch.
- Ultimately, the whole thing should be very plug-and-play.
- First impressions last a very, very, very long time especially for something new. Don’t toss something over the wall and say “here it is” when it’s 1.0. If you’re doing something new like this, be a Steve Jobs-esque jerk, make absolutely certain that every little detail is perfect and leave no new user experience left to feel like scrambled eggs and dirt.
This isn’t about AppFabric
This is about software. We have too much of it. We don’t have time to deal with troubleshooting another “advanced suite of services” for a web farm. We are already overwhelmed with understanding WCF, IIS 7, changes in ASP.NET Web Forms 4.0, and so on and so forth, on top of everyday concerns like our own business logic in C# and our T-SQL stored procedures. I love the modularity of IIS 7/7.5 but I’ve noticed that I’ve been getting annoyed now instead of excited when I see all the downloadable feature options at IIS.net. I just don’t have time to keep up with them all. So if I need to use one of these, it better be able to run itself because I don’t have time to deal with another project of learning a whole new module.
I don’t have the hours it would seem to take to set up what should be a minor component of a web farm, particularly considering the component we’re replacing (in this case ASP.NET Session State service) had only a couple minutes of setup (Automatic startup, and set AllowRemoteAccess=1 or whatever it’s called in the registry) because the older flavor was bundled and pre-deployed with ASP.NET / .NET Framework itself.
Not only that but if first impressions at installation, setup, and startup fail me, then I’ll automatically have difficulty trusting the quality of the software. It’s in our nature as software engineers to find it more difficult to trust software that breaks when we touch it; of course, the culprit is almost always a PEBKAC error, but that’s all the more reason why any significant software application or service should be as foolproof at its point of setup as it is stable and accurate at runtime.
Another case in point, last I checked (about five years ago), Microsoft SQL Server was dancing in circles around Oracle DB. Oracle had features that Microsoft SQL Server could only dream about, but Oracle’s setup hell and disgusting administrative tooling left such a rancid taste in one’s mouth that it’s no wonder that it’s only used in cold, dry environments where human beings have relinquished their humanity.
Why I’m ranting on this again
I’m writing this blog post because today I’ve been finding myself doing it yet again. I’ve been pondering and planning to write yet another alternative to Microsoft’s offering, in order to get that bad first impression taste out of my mouth and replace it with something I can trust. But now we’re talking about AppFabric. Fricken AppFabric. And after compiling my notes, I’ve come to realize that I’d be insane if I tried to recreate even a tiny subset of this in a few sit-down sessions. (Maybe I am insane, insane enough even to keep considering doing it, a number of people think I’m a lunatic anyway.) But I’m not happy with being in this boat. Frankly, I’m angry. I’m angry because this is not anywhere close to being the first time a highly marketed Microsoft back-end technology was such an unnecessarily difficult pain to get started. I’m angry because it’s not just Microsoft—when I worked at Sage Software for the Saleslogix product, the web technology was a crazy multi-installer, multiuser, multi-ACL, multi-reboot nightmare. None of these software companies have any excuse. Why can’t Microsoft just put back-end stuff out that works in a foolproof manner? Why is that so hard for them? Why am I forced to be stuck in that boat that the Linux people put me in, where I am the loser because I couldn’t install what should have been a simple service. It’s just so insulting. But I blame it all on Microsoft, and I hate tolerating this crap.