A number of years ago, Microsoft purchased an excellent body of tools called Sysinternals. They're now (officially) called Windows Sysinternals.
Every once in a while, I am reminded just how useful these tools are - today, it was Process Explorer. My system was running dog-slow, and I wasn't really sure why. I tried using Task Manager, but I didn't really understand what I was seeing. There as an instance of setup.exe that was taking up CPU time, but I hadn't launched any installs.
So I grabbed Process Explorer (I keep it on a USB stick) and fired it up, and I saw immediately (because of how the processes were linked on-screen) that Windows Update was upgrading SQL Server Express. I still had a slow system, but now I knew why.
If these tools aren't already on your go-to list, you owe it to yourself to check them out and keep them with you at all times. You'll be glad you did.
Normally, I gain some satisfaction from having been right way ahead of the pack. Not so much in this case, though.
In this case, I look back and I see an industry's incredible collective capacity to see a problem coming, look it in the eye, and keep pouring the coals to the boilers.
Since I wrote that post two years ago, the auto makers have hit the skids in a big way (though, paradoxically, Ford is fairing the best of the US automakers), and we've also seen our banking industry implode. It turns out that "too big to fail" is too big to steer, doesn't it?
One of the most impactful things I saw at CodeMash wasn't on the schedule. I'd dropped in to check out Jeff Blankenburg's presentation on Azure & Windows Live Mesh, but it was clear that the demo gods weren't about to smile on Jeff that day.
The CodeMashers had sucked up the hotel's WiFi bandwidth like it was free beer, and Jeff's demo was sucking wind. Now, truth be told, I'd seen a similar demo under more favorable conditions, and the demo rocks. I'm not trying to indict the demo, or even the technology.
What I do question, though, is whether we're collectively thinking about all the architectural implications of the cloud computing movement.
There's a giddy excitement about cloud computing, because scalability in the cloud is super-simple and all but free. You just twist a knob, and you've got more capacity. Really -- that's what all the marketing folks tell us, isn't it?
But most of us won't build enterprises entirely in the cloud. Most of us (or our clients) have systems running on internal networks, and we're going to move portions of our systems to the cloud, or we're going to expand into the cloud for new applications. That means integration -- not only are we going to drive more traffic through our Internet gateway because we're accessing applications running on the 'Net, we're also going to need to integrate our cloud apps to our enterprise and our enterprise apps to the cloud -- again, all passing through the Internet gateway, and all using relatively fat HTTP requests.
Is your network ready for this extra stress?
I've seen enterprises operating with chronically poor network performance. I've seen internal apps running slowly, and I've seen the same apps slow to a crawl when accessed from the Internet. I've seen the baffled looks on IT Managers' faces when they weren't sure how to attack the problem of network performance. Networking problems are scary, because it takes a completely different skill set to identify and fix these problems than the skills we've developed as application developers.
Do you have a network engineer that you trust as completely as you trust your DBA's?
Consider what you're going to do the next time your office experiences a "slow internet day". Now, you're no longer talking about slow Google searches and interruptions to webcasts. Now, you've enterprise applications that aren't working. Is your enterprise ready to handle that call?
The database in question is a gigantic repository of claims and payments, and Ingenix made a tidy living over the years by selling subsets of this data to insurers for really large sums of money. But for the insurers, the data is crucial, and they were the only game in town. The barriers to entry for another player were just too prohibitive for someone else to try to break into this business.
So what's the problem?
The problem is that insurers made many of the decisions about how they were going to reimburse for services based on this database, and they were the only ones who could check the numbers. They were able to mine and manipulate the data to their advantage, and providers and insureds had no choice but to trust that the insurance companies were treating them fairly.
Thus, a lawsuit was born.
But what does this have to do with software? The Ingenix database was one of the biggest remaining walled data gardens out there, and it's history. One by one, businesses that were in business only because of proprietary information are going the way of the dodo.
This is a really encouraging development for the health care industry - what's the next walled garden to fall?
I'm heading to CodeMash tomorrow, and I hope to come back with all sorts of great news, notes, and ideas. I'll be scribbling notes throughout the day on my Adesso tablet, and I'll sync them with Evernote to a CodeMash public folder. You can see all of my scribblings there as I sync - apologies in advance for my chicken scratchings. As I have time to organize my thoughts, I'll try to get some blog posts out of my trip, too.
As a favor to a friend, I recently did some tech support for a guy who was having trouble getting his dial-up Internet connection to work properly. Yes, that's right - dial-up.
Let me tell you - if you haven't done this recently, it's a real eye-opener. Not that I'd wish it on anyone else, mind you, but it helped remind me that there are still people out there (in the United States, actually) who still connect to the Internet by dial-up, and that there are times when the Internet really bites for these folks.
Here's a gigantic for-instance: it turns out that the reason this guy couldn't connect to the internet is that he'd just upgraded his computer (no, I don't know why -- maybe his old one died), so he had this brand-new Dell loaded with Vista, and he couldn't get it connected. He'd called his dial-up provider (PeoplePC) and the tech-support guy tried to talk him through getting connected, but just couldn't seem to finish the job. So when I got there and got the poor thing online, the first thing we wanted to do was to get email set up.
You know what the first thing the PC wanted to do was, though? Windows updates. Arrrgghhh. So this poor guy is downloading 10 hours worth of Windows updates while we're trying to get email configured, and predictably, network access is godawful slow because the updates are sucking up all our bandwidth. Nice.
I tried to drop a couple of hints to the effect that he could probably get broadband for a couple bucks more than he's paying right now for dial-up, but honestly, wouldn't it be nice if Vista would be a little more considerate about how it shoves updates at dial-up users? If you've got a guy who's dialing up every day to get his email, and then hanging up when he's done, he might literally never catch up with the updates, and I'd bet that all the really good stuff is queued up behind 30MB worth of Office clipart updates.
And in the mean time, I'm staring at bits dribbling down the PC thinking that I'd be getting more throughput on my cell phone.
The other big problem that occurred to me was that this guy didn't have a hardware firewall / router, which meant that we were relying only on Microsoft's firewall to protect us. A little shiver ran up my spine at this thought.
So the next time you see one of those studies that talks about how the USA lags behind "X" developing nations in broadband adoption, stop and think about it for a minute. These people live in your neighborhood, and there's a good chance that they're not buying your product or using your service because they can't use your site on dial-up. Is this really the best we can do? Really?