Scalability Requirements

Stefan Tilkov and Dare Obasanjo debate the number of big sites that would benefit from giving up on the relational database as a centerpiece of their systems. The parameter used in the discussion is scalability.

A number of the lessons learned from these big web sites could apply to smaller data center designs as well. The biggest problem I've seen in the typical data center, and from comparing notes, seems fairly common, is the ability evolve components relatively independently.

Relational databases can be in the mix and still evolve, just as more supposedly "loosely coupled" mechanisms can actually tie components tightly together. For example some systems may use asynchronous messaging to decouple with respect to time, but then pass to each other data that exposes implementation details. And so these systems are coupled to each other with respect to maintenance and enhancements: changing the implementation of component C demands corresponding changes to every other component that consumes component C's implementation-specific messages.

But the lessons are worth following for more reasons than just scalability.

Content Unbecoming

Sam Ruby comments in his own blog...

I will merely point out that I’ve dealt with formats and protocols which are “explicitly not intended for human readability” and I’ve learned to avoid them.

And Bill de hÓra comments further down...

Atompub/Atom shines light on the fact we have serious issues around sharing and “understanding” structured content. Complaining about the source of light isn’t sensible.

So, to me, this is like the web services debates rehashed half a decade later. The only interesting difference in this thread is the level the argument is happening - around the content/payload/mediatype instead of wire/transfer...

Maybe it’s not as obviously random at this time to argue that per silo data access formats are a good idea...

Fwiw, “technically”, I don’t see why facebook don’t serve class laden XHTML and document the attributes.

And along the way James Snell compares to Yaron's example...

<entry xmlns="http://www.w3.org/2005/Atom">
  <id>tag:example.org,2005/someuser/profile</id>
  <title>Some User's Profile</title>
  <updated>2000-01-01T00:00:00Z</updated>

  <author><name>Profile System</name><author>
  <content type="xhtml">
    <div xmlns="http://www.w3.org/1999/xhtml">
      <div class="profile">
        <div class="section" id="professional">

          ...
        </div>
        <div class="section" id="personal">
          ...
        </div>
        <div class="section" id="clothingPreferences">
          ...
        </div>

      </div>
    </div>
  </content>
</entry>

Looks good. Damn. Even *this* xml-hater (yours truly) has had trouble realizing all that one-off stuff is bogus.

Don't Fear the Programmer

Not to beat a dead horse, but Robert Cooper adds an important point to the enterprise development tool conversation...

And here is where it breaks down. All these unusable drag and drop tools, and “easy” XML programming languages aren’t targeted at programmers. They are targeted to suits who can buy into the idea that some non-techy is going to orchestrate these services and modify business rules. These products are unworkable because they are based on the idea that “You won’t need programmers anymore!” at least at a core level. Once you make that assumption you start building things that get in programmers way, and still include enough abstract programming concepts that no non-programmer is ever going to be able to work with it proficiently

I've not heard this lately, but in previous situations this point was widely held: BPM tools should be used to get the programmer out of the loop. I always enjoyed bringing testing into the conversation. The current crop of BPM tools I've seen up close are terrible at incremental development, testing, and release. And yet at least some IT shops have seen them as *the* way to get from under long software development cycles.

Those shops I know of also happen to be historically lacking good automated testing and release practices. Most of their causes for long development cycles have almost *nothing* to do with programmers, save for the fact that most programmers historically have not paid much attention to good testing either. Of course that's changed dramatically over the last five years or so.

Managers: if you have long development cycles, backlogs of feature requests and bugs, and "legacy code" that seems impenetrable, then please embrace your programmers' desires to be more productive and effective. There are many things you can do today to make big improvements. Buying tools that will reduce the need for programmers is a pipe dream for now.

Sad IP

So let me get this straight -- Novell and Redhat are being sued over a patent some mangy IP shop bought that originated at Xerox PARC (I suppose Rooms?). And the patent is about making the same window show up in multiple workspaces?

This is the best IP some mangy techno-lawyer can pin on *Linux*?

Em, wow. Crawl back under your rock until you can make it *really* interesting... Next.

And note to Steve Ballmer: stop being such a wuss. You're really just appearing pretty sad these days. Can't you get a ride in space or something?

RFC 5023

Nicely done. RFC 5023.