MySQL and BEA: Oracle and Sun Will Be At Each Other’s Throats!

Big news today is that Sun is buying MySQL and Oracle is buying BEA. This creates a couple of strange bedfellows to say the least. BEA is inextricably wrapped up in Sun’s Java business (is it really a business or just a hobby given the revenues it doesn’t produce?) which gives a reason for the two to get closer together. On the other hand, there is hardly a bigger threat to Oracles core database server business imaginable than MySQL, which has got to push the two companies further apart. What a tangled web!  Is Sun leaving Oracle to its own devices in order to pursue cloud computing?  Sure looks like it!

Let’s analyze these moves a bit. I want to start with BEA and Oracle.

As we all know, Oracle started that courtship dance not long ago and was rebuffed for not offering enough.  Amusingly, they closed almost exactly at the midpoint of the prices the two argued were “fair” at the outset.  Meanwhile, the recession is really setting in, stock prices are falling, and Oracle’s offer went up.  Since Cisco’s John Chambers mused about IT spending will slowing, it has become a widely accepted article that this will happen. So shall it be said, so shall it be written, Mr. Chambers. That’s a very bad thing for BEA, which is primarily selling to that market. The corporate IT market is their bread and butter for a number of reasons. Many ISV’s and web companies will look to Open Source solutions like Tomcat or JBoss with which to reduce costs. Corporate IT wants to superior support of a big player like BEA. The darker truth is that big Java seems to be falling out of favor among the bleeding edge crowd. Java itself gets a lot of criticism, but is strong enough to take it. J2EE is another matter, though there is still a huge amount of it going on. There is also the matter of the steady ascendency of RESTful acrchitecture while BEA is one of the lynchpins of Big SOA.  There is already posturing about the importance of BEA to Oracle Fusion.  If it is so important, Fusion may be born with an obsolete architecture from day one. 

The long and the short is that any competent tea leaf reader (is there any such thing?) would conclude that this was a good move for BEA to let themselves be bought before their curve has crested too much more. For Oracle’s part, its a further opportunity to consolidate their Big Corporate IT Hedgemony and to feed their acquisition-based growth machine. I am not qualified to say whether they paid too much or not, but if I do think the value curve for BEA is falling and will continue to fall post-acquisition. They are way late on the innovation curve, which looks to me like it has already fallen.  In short, BEA is a pure bean counting exercise: milk the revenue tail as efficiently as possible and then move on.  For this Oracle paid $8.5B.  Not surprisingly, even though it is a much bigger transaction, there is much less about it on the blogosphere as I write this than about the other transaction.

Speaking of which, let’s turn to the Sun+MySQL combination.  Jonathan Schwartz gets a bit artsy with his blog post introducing the introduction, which he calls “Teach dolphins to fly.”  The metaphor is apropos.  Schwartz says that MySQL is the biggest database up and comer news in the world of network computing (that’s how we say cloud computing without offending the dolphins that haven’t figured out how to fly yet).  What Sun will bring to the table is credibility, solidity, and support.  He talks about Fortune 500 needing all that in the guise of:

Global Enterprise Support for MySQL – so that traditional enterprises looking for the same mission critical support they’ve come to expect with proprietary databases can have that peace of mind with MySQL, as well.

That business of “proprietary databases” means Oracle.  Jonathan just fired a good sized projectile across your bow Mr. Ellison.  What do you think of that? 

I know what I think.  Getting my tea leaf reading union card back out, I compare these two big acquisitions and walk away with a view that Oracle paid $8.5B to carve up an older steer and have a BBQ while Sun paid $1B to buy the most promising race horse to win the Kentucky Derby.  What a brilliant move for Sun!  Now they’ve united a couple of the big elements out there, Java being one and MySQL the other.  They could stand to add a decent scripting language, but unlike Microsoft’s typical tactics, they’ve learned not to ply a scorched earth policy towards other platforms, so they are peacefully coexisting until a better cohabitation arrangement comes along. 

We talked a little about the Oracle transaction being a good deal for BEA:  it’s a lucrative exit from declining fortunes.  What about mySQL?  Zack Urlocker comments about the rumor everyone knew, that MySQL had been poised to go public.  Let me tell you: this is a far better move.  Savvy private companies get right to the IPO alter, and then they find someone to buy them for a premium over what they would go out at.  What they gain in return is potentially huge.  The best possible example of this was VMWare.  Now look where they are.  I will argue that would not have been possible without the springboard of EMC.  At least not this quickly.   Sun offers the same potential for MySQL.  It is truly the biggest open source deal in history.  It’s also a watershed liquidity event for a highly technical platform based offering from a sea of consumer web offerings.  The VC’s have been pretty tepid about new deals like MySQL.  Perhaps this will help more innovations to get funded.

What do others have to say about the deal?

 - Tim O’Reilly echoes the big open source and importance of database to platform themes.

 - Larry Dignan picks up on my rather combative title theme by pointing out that it puts Sun at war with the major DB vendors:  Microsoft, IBM and Oracle.  Personally, I think any overt combat will hurt those three.  The Open Source movement holds the higher moral ground and it just won’t be good PR to buck that too publicly.  Dignan sounds like he is making a little light of Schwartz’s conference call remark that it is the most important acquisition in Sun’s history, but I think that is no exaggeration on Jonathan’s part.  This is a hugely strategic move that affects every aspect of how Sun interfaces with the world computing ecosystem including its customers, many partners, and its future.  When Dignan asks what else Sun needs, I would argue a decent scripting language.  Since Google already has Python in hand, what about buying a company like Zend to get a leg up on PHP?  Last point from Larry is he asks, “If Sun makes MySQL more enterprise acceptable does that diminish its mojo with startups? Does it matter?”  Bottom line: improvements for the Enterprise in no way diminish what makes MySQL attractive to startups, providing Sun minds its manners.  So far it has been a good citizen.  With regards to, “Does it matter?”  Yes, it matters hugely.  MySQL is tapped into all the megatrends that lead to the future.  Startups are a part of that.  Of course that matters.

One other thought I’ve had:  what if Sun decides to build the ultimate database appliance?  I’m talking about order it, plug your CAT5 cable in, and forget about it.  Do for dabases what disk arrays did for storage.  That seems to me a powerful combination.  Database servers require a painful amount of care and feeding to install and administer properly.  If Sun can convert them to appliances, it kills two birds with one stone.  First, it becomes a powerful incentive to buy more Sun hardware.  This will even help more fully monetize MySQL, which apparently only gets revenue from 1 in 10,000 users.  Second, it could radically simplify and commoditze a piece of the software and cloud computing fabric that is currently expensive and painful.  Such a move would be a radical revolution that would perforce drive a huge revenue opportunity for Sun.  They have enough smart people between Sun and MySQL to pull it off if they have the will. 

Conclusion

Sun has made an uncannily good move in acquiring MySQL.  As Wired points out:

One company that won’t be thrilled by the news is Oracle, makers of the Oracle database which has managed to seduce a large segment of the enterprise market into the proprietary Oracle on the basis that the open source options lacked support.

With Sun backing the free MySQL option (and offering paid support) Oracle suddenly looks a bit expensive.

How else can you simultaneously lay a bet on owning a substantial piece of the computing fabric that all future roads are pointing to and send a big chill down Larry Ellison’s spine for the low low price of just $1B?  Awesome move, Jonathan!

Related Articles

VARGuy says the acquisition means Sun finally matters again.  $1B is cheap to “finally matter again!”

Pile O’ LAMPs: What Would Fielding Say?

I’ve been pondering the Pile O’ Lamps concept that I first read about in Aloof Architecture and Process Perfection.  Read the posts yourself for the horse’s mouth, but to me, the Pile O’ Lamps concept is basically asking whether a computing grid of LAMP stacks is a worthwhile architectural construct that could be highly reusable for a variety of applications.  I say grid, because in my mind, it achieves maximal potential if deployed flexibly on a utility computing fabric such as Amazon EC2 where it can automatically flex to a larger cluster based on load requirements.  If it is fixed in size by configuration (which still means changeable, just not as quickly and automatically), I guess it would be more proper to call it a LAMP cluster.

LAMP refers to Linux as the OS, Apache as the web server, mySQL as the database, and a “P” language (usually PHP or Python) as the langauge used to implement the application.  It has become almost ubiquitious as a superfast way to bring up a new web application.  There are some shortcomings, but by and large, it remains one of the simplest ways to get the job done and still have the thing continue to work if you move into the big time.  A Pile of Lamps architecture would presumably simplify scaling by building it in at the outset rather than trying to tack it on later.

In general, I love the idea.  People are effectively doing what it calls for all the time anyway, they just do so in an ad hoc manner.  I got ambitious this Sunday morning and thought I’d drag out Fielding’s Dissertation and see how the idea stacks up.  If you’ve never had a look at Roy Fielding’s Architectural Styles and the Design of Network-Based Software Architectures, you missed out on a beautiful piece of work from the man that co-designed the Internet protocols.  This particular document sets forth the REST (Representational State Transfer) architecture.  What’s cool about it is that Fielding has a framework that he uses to evaluate the various components of REST that is applicable to a lot of other network architecture problems.  See Chapter 3 of the Dissertation for details, but that is my favorite part of the document. 

His concept is to create a scorecard for various network architectural components, and then use that scorecard together with the domain requirements of the design problem to arrive at an optimal architecture.  He says that’s how he got to REST, and it certainly seems to make sense as you read the Dissertation.  Here is a rendition of his ranking criteria for the models he considers:

A “0″ means the architectural style is beneficial to some domains and not others.  Positive means the style has benefit and negative means it is a poorer choice.

The components that make up REST look like this:

There are 3 components that go into it:

• Layered Cached Stateless Client Server:  The row marked LCS+C$SS
• Uniform Interface, which isn’t in the original Fielding taxonomy, but which he says adds the qualities listed.
• Code on Demand:  This is the ability of the web to send code to the client for execution based on what it requests.  So, for example, Flash or AJAX.

The “RESTful Result” is simply the total of the other attributes.  You can see it hits pretty darned well on most of the categories with the exception of Network efficiency.  As noted, this primarily means it isn’t suited to extremely fine grained communication, but is fine for a web page.  Pretty cool framework, eh?

Incidentally, Fielding’s framework really dumps on CORBA for all the right reasons.  Give it a read to see why.

Now let’s look at the Pile of Lamps.  Note that we aren’t trying to compare it to REST–they solve different problems.  Fielding tells us to do the analysis based on our domain, so put aside the RESTful scores, they aren’t meaningful to compare to anything but REST competitors.  Here is the result for Pile of Lamps:

I view the LAMP stack as Layered Client Server, which is already a decent protocol.  A Pile of Lamps seems to me is basically adding a cached and replicated capability to the LAMP stack, so I add the cached/replicated repository to the equation.  You can see that it amplifies the LAMP stack while taking nothing away.  Basically, it makes it more efficient, more scalable, and it delivers those benefits in a simple way.  This makes total sense to me, given the concept. 

One can use the framework to fiddle with other potential additions to the Pile of Lamps idea.  For example, what if statelessness were pervasive in this paradigm?  I leave further refinement of the idea to readers, commenters, and the original authors, but it looks promising to me.  I’d also encourage others to delve into Fielding’s work.  It has application well beyond just describing REST.

Related Articles

A Pile of Lamps Needs a Brain

Making a Business of Open Source

I have little to add here other than to say that Joe Cooper has a great essay on how you go about making a business that makes money out of what looks at first glance like free software.  It’s worth a read if you’ve ever been curious about the business of open source.  His comments about hosted open source, which is a lot like combined SaaS and Open Source, are particularly useful.

Platform Vendors Have to Be Switzerland

Platforms are big news these days.  Everyone wants to be a platform:  becoming a platform is even part of Yahoo’s plans to turn the company around. 

What do you look for in a platform vendor?  Yes, the features and functionality provided by the platform are important.  And yes, the community that is already there is also important.  But what about how a platform conducts itself?  Think of a platform like the popular notion of a Swiss Bank:  an extremely safe place to put your faith and assets.  A place that has no interest whatsoever in anything but safeguarding those assets.  Most platforms are not like Swiss Banks.  They are bent on World Domination.  They get confused about their loyalties when greed sets in.  They start to compete with those who placed their trust in them.  Those are the platforms you want to think twice about betting on.  Consider what it will be like to try to make a living on that platform, or to commit your data and energy to using the platform. 

Platforms often come about because a great application started a frenzy that others wanted to be part of.  Facebook is in that category.  We’ve yet to see whether Facebook will be a friendly platform owner, or predatory, but it’s something folks wonder about for obvious reasons.  Zuckerberg is saying some of the right things, at least, when he suggests that widgets should have a life both on and off Facebook.  That implies he doesn’t insist on total domination.  On the other hand, some are afraid that at least other Social Networks like LinkedIn have reason to fear.  Yet, the other Social Networks are direct competitors, not consumers of Facebook’s platform, so isn’t it kosher to fire a shot or two in their direction.  It’s still too early to tell if Herr Zuckerberg will be a taciturn Swiss Banker, or whether he’s bent on World Domination.  I am cautiously optimistic about the early signs.

The Apple iPhone is another great-application-begets-platform story, and one that seems to have gone bad.  Clearly, Apple is not acting as Switzerland here.  They are bent on world domination.  In fact, their weapon of choice, “bricking” of iPhones, has sparked a startling backlash where once there was nothing but raves.  Steve Jobs does not want to nurture you on his platform, he wants to control your every thought and action.  I’m sure he feels it’s for your own good, but is this what we want from our platform vendor?  I should say not, and its been a long time since a killer app came to roost on Apple’s platform as its first and only hunting grounds.

Still other companies are in the odd role that their admirers beg them to be platforms, but they have no intention of sharing any part of their pie.  eBay has always had the view that they owned every penny of opportunity surrounding their platform.  Many have tried to join on, but eBay itself makes that all but impossible.  It isn’t surprising, their Disney executives grew up on the idea that Mickey was a franchise, not a platform, and nobody was entitled to a piece of Mickey’s pie.  Apple is very similar, particularly in view of the latest iPhone shenanigans.  In Apple’s case, they’re control freaks for the sake of their conceptual integrity, whereas with eBay, it’s just business.

Microsoft gives us an abject lesson on platform owners who are not Switzerland.  It started innocently enough with things like BASIC and DOS, but soon, Microsoft wanted to compete with everyone, taking full advantage of their platform in every way they could to do so.  For a while in Silicon Valley every VC pitch had to include a discussion of why Microsoft wouldn’t just take your business away when they wanted it.  Arguably the strategy worked well for a time, but they seem to have reached the limits of it.  I see the last gasp as their abandonment of all things Java in a tiff with Sun over who could own the platform.  Microsoft will say they had little choice, but they’ve pursued it as a bit of a scorched earth policy by working overtime to ensure that the Java web and the .NET web are as incompatible as can be and still call it the web.  Consequently, they lost the hearts and minds of many who would embrace platforms.  Arguably, very little of the current cloud computing renaissance involves Microsoft as a result.

In the land of Marc Andreesen’s 3 kinds of platforms post, he mentions several of the third kind including Ning, Salesforce, and Second Life.  FWIW, I find Andreesen and Ning fit the Swiss Banker profile pretty well.  As we look back over Andreesen’s history, he seems to have done a good job nurturing platforms along the way.  Ning has no particular Social Network of their own, except to help other Social Networkers to use Ning more effectively. 

Salesforce is an interesting case.  Clearly, the other Marc (Benioff), is bent on world domination.  The question is to what degree he would compromise his platform aspirations to do so.  Perhaps he can turn into the Swiss Banker over time, but it seems an unlikely role at the moment.  He came up through the ranks of Oracle, which is not typically a breeding ground for the Swiss Banker mentality.  Still, we should watch closely and reserve judgement for a bit.  There are signs of life around Force, but it remains to be seen whether they’re higher forms of life, or just people looking to siphon off the halo effect of Salesforce’s community and greatness. 

Adobe has been a platform owner for some time with pdf and Flash.  But they’re also an application company as we were reminded by the announcements surrounding their acquisition of Web 2.0 word processor BuzzWord.  As Scoble says, they’re going for Microsoft’s throat.  But does this mean they might one day go for their platform user’s throats too?  I suspect not.  Adobe has always been very deliberate in their actions and they’ve done a good job nurturing their platforms.  BuzzWord is happening at a time when Microsoft essentially owns the document world.  Choosing to go after one of the giant platform monopolists doesn’t seem to me like bad behaviour for a platform vendor.

The ultimate Swiss Banker is of course Open Source.  How can you go wrong here?  The platform you’re depending on has been placed in the Open Source community and so how bad can things get in terms of the owner/creator being the Anti-Swiss?  Hence we see why so many prefer Open Source.  Perhaps Open Source is a way for Marc Benioff to gain full trust, though I have a terrible time seeing Force ever being an Open Source platform.  It just doesn’t seem like their style.

The next time you’re shopping for a platform, remember that platforms involve a big investment.  Try thinking of it in terms of Swiss Bankers.  Which one fits the profile?

To Escape the Multicore Crisis, Go Out Not Up

Of course, you should never go up in a burning building, go out instead.  Amazon’s Werner Voegels sees the Multicore Crisis in much the same way:

Only focusing on 50X just gives you faster Elephants, not the revolutionary new breeds of animals that can serve us better.

Voegels is writing there about Michael Stonebreaker’s claims that he can demonstrate a database architecture that outperforms conventional databases by a factor of 50X.  Stonebreaker is no one to take lightly: he’s accomplished a lot of innovation in his career so far and he isn’t nearly done.  He advocates replacing the Oracle (and mySQL) style databases (which he calls legacy databases) with a collection of special purpose databases that are optimized for particular tasks such as OLTP or data warehousing.  It’s not unlike the concept myself and others have talked about that suggests that the one-language-fits-all paradigm is all wrong and you’d do better to adopt polyglot programming.

I like Stonebreaker’s work.  While I want the ability to scale out to any level that Voegels suggests, I will take the 50X improvement as a basic building block and then scale that out if I can.  That’s a significant scaling factor even looked at in the terms of the Multicore Language Timetable.  It’s nearly 8 years of Moore’s Cycles.  I’m also mindful that databases are the doorway to the I/O side of the equation which is often a lot harder to scale out.  Backing an engine that’s 50X faster sucking the bits off the disk with memcached ought to lead to some pretty amazing performance.

But Voegels is right, in the long term we need to see different beasts than the elephants.  It was with that thought in mind that I’ve been reading with interest articles about Sequoia, an open source database clustering technology that makes a collection of database servers look like one more powerful server.  It can be used to increase performance and reliablity.  It’s worth noting that Sequoia can be installed for any Java app using JDBC without modifying the app.  Their clever monicker for their technology is RAIDb:  Redundant Array of Inexpensive Databases.  There are different levels of RAIDb just as there are RAID levels that allow for partitioning, mirroring, and replication.  The choice of level or combinations of levels governs whether your applications gets more performance, more reliability, or both.

Sequoia is not a panacea, but for some types of benchmarks such as TPC-W, it shows a nearly linear speedup as more cpus are added.  It seems likely a combination of approaches such as Stonebreaker’s specialized databases for particular niches and clustering approaches like Sequoia all running on a utility computing fabric such as Amazon’s EC2 will finally break the multicore logjam for databases.

70% of the Software You Build is Wasted (Part 1 of Series of Tool/Platform Rants)

The headline gives a gruesome statistic, but it is probably understated.  At least 70% of the software you build is wasted because you are constantly reinventing the wheel by building components that do not deliver any competitive differentiation to your offering.  You have to build them for the offering to work, but they’re things that everyone in your space also provides.  Often, they are things that everyone in every space provides. 

I was having lunch with a CTO friend recently and broached this subject to him in a deliberately provocative way.  After he got past my delivery, he sighed and commented that he agreed.  Every new job he takes requires reinventing the same wheels all over again.  Another friend who is a marketing guy had exactly the same reaction even though he isn’t a techie.  He knew exactly how much was being invested in Engineering to build stuff that he couldn’t put in a press release or otherwise tout.  His referred to this work as a tax on innovation.  The non-differentiated stuff would just barely be average if you did it extremely well.  It would be average because it didn’t matter that it be any better than average: it wasn’t a competitive differentiator.  Therefore you couldn’t afford to make it better than average if you were focusing your business properly.

I find it incredibly bleak to consider that 70% of the lines of code being written will be average at best and will likely make no difference to the business.

Consider the example of Security to give a flavor for what I’m talking about.  In the Enterprise World where I’ve spent a lot of my career, Security is a key area of functionality that CIO’s and IT guys want to know about before they’ll even think about buying your product.  There is a long list of features and questions they have to be briefed on.  How will you interface with our LDAP server?  How will you deliver single sign on under our portal standard?  Do you support our (1 of 257 distinct formulas we’ve seen so far) exact recipe for how we want passwords and cookies to be handled by thin clients?  All of the real offerings need to have good answers for all of these questions, so it’s not giving you any proprietary advantage to solve these problems, it’s just part of the cost of doing business.

For SaaS companies, the tax is even higher.  At a perpetual software company, you install inside the firewall.  Many security issues for SaaS are taken for granted once you’re inside the firewall.  There is a lot of IT glue already in place to enforce things like password policies (it has to change every 90 days except when there is a Harvest Moon, there must be at least 13.5 characters, 1 of which is a symbol from the Greek alphabet, 3 of which are the square root of your Mother’s first pet’s name, yada, yada, yada) and to let other vendors shoulder some of the burden for things like monitoring whether the software is functioning properly.  As a SaaS vendor, you have to build all this glue that your perpetual peers take for granted.  Is it any wonder that the common wisdom has become that SaaS takes more investment capital?

There are many more examples:

• Forms and UI:  Most UI is really pretty similar, with a slightly different application of surface level cosmetics for branding.  This is a good thing, because it means you understand the vocabulary if not the language when you see the UI of most web software.  Yet, a staggering amount of work goes into recreating this wheel over and over again.
• Database Connections and Persistence:  The data goes in a database in most cases, whether we’re talking mySQL or Oracle.  Isn’t it amazing how much effort still has to go into this connection lo these many years since E.F. Codd postulated relational databases?  And how long have we known that object oriented languages need a way to put objects into the database and then get them back out, something we call a “persistence layer”?  Yet, we frequently have to build or at least extensively modify some component to make this happen. 
• Reporting, Messaging, Data Feeds, yada, yada, yada.  The list of things companies build that already exist in some form or fashion is huge.  NIH is alive and well in today’s Software 2.0 world. 
• Scalability:  Caches and similar contrivances get recreated over and over again as traffic builds up on your web site.

There are many more examples that I’ll leave to the readers.  How does this happen?  I blame three candidates, one of which is cultural, and the other two are technological, yet enabled by the cultural quirk:

Software Developers are Producers Not Consumers of Code

Code reusability is hard, as anyone who has tried to herd the cats (developers) all together towards some form of reusability or core technology will tell you.  Every developer will loudly proclaim that code must be reused.  They will immediately follow this up by demanding to work in a core technology group that will produce the greatest code for sharing since sliced bread.  What they’re really saying is, “Everyone should reuse code, but it has to be my code they reuse.”  Take any software developer who is well regarded by his peers, collect some of his code, destroy all comments and other information that would connect the code to the star, and give the code to another engineer telling him he has to use it or maintain it.  The recipient can be a star or just one of the troops in the trenches, it doesn’t matter.  In 99 out of 100 cases, the recipient will loudly proclaim that the code is completely unusable and will have to be rewritten. 

Programmers hate to reuse code becaues they hate to read and understand code.  In the old days it was called “NIH” syndrome.

By now you may be thinking that “Software Developers are Doers, Not Learners”.  In practice, I have not found this to be true, but I have found that the organizations the developers work for rarely invest in letting their developers learn, hence the end result is they’re stuck doing the same old think in the same old Curly Braced Language:

The Tyranny of One-Size-Fits-All Curly Brace Languages

If everyone else’s code is crap, which we have established by now, I’d better have a language that lets me write anything, because you never know what I might have to write.  I’d better have a curly brace language: a real Alpha Geek’s Power Tool for Programming.  The Curly Brace Languages are C++, Java, and C#.  They are all descendants of the mighty C language, which was created in 1972 in order to build Unix, an operating system.  Because of this, C is considered a Systems Programming Language, although many used it to create Application Software.  Because Systems Programming is about creating absolutely the gnarliest, most difficult types of software, such as operating systems and even new language compilers, it has to be able to get down to the finest levels of detail without making any assumptions.  It can’t get in your way, in other words.  Wikipedia puts it amusingly by saying that System’s Software talks to hardware while Application Software talks to people.

Unfortunately, for that 70% of wheel reinvention I mention above not getting in you way means the Curly Braced Language also doesn’t help you much.  You do all the heavy lifting!  OTOH, should you need to write code that talks to hardware (does your business really need that?), the Curly Braced Language is indispensible.  Blogger Russell Beatie puts it extremely well in Java Needs An Overhaul:

There’s something about the Java culture which just seems to encourage obtuse solutions over simplicity. 

It isn’t the culture though; it’s the language that encourages obtuse solutions.  It’s deep object oriented programming.  It’s the fact that the Curly Brace Languages have become the assembly languages of our day, and there is nothing more obtuse than a big assembly language program.  Don’t believe Curly Braces = Assembly Language? Consider the following strengths of Curly Braces, which are essentially the same as assembly language:

- You can talk directly to the hardware (yes, you can do Systems programming, but does your project really need to?)

- Because I get better performance (yes, but not in a multicore world where massive scalability not tight loops will rule)

- Because I might have to do some gnarly cool down-in-the-weeds Geek thing that can only be done by a Curly Brace Language (yes, but how often must you do this?)

Enough said.  You can get the job done with Curly Braces, but 70% of your work is wasted because you have an electron microscope when you really needed a pair of reading glasses.  Smart companies are now using more than one language, a practice called Polyglot Programming.  They know the dangers of overly focusing on a single Curly Braced Language for all programming.  I’ll have more to say about Polyglot Programming in a future post.

The Application Framework Tower of Babble

So what happens with my Curly Brace Language when I want to do Application Programming instead of Systems Programming?  Well, unless I am crazy enough to ship an OS with my application (don’t laugh, it has been done in the past!), I need help talking to the OS that’s already in place.  That’s because the Curly Braced Language is so busy not getting in your way that it doesn’t help you much either.  It can talk to your hardware, but scarcely knows your operating system.  So, the stuff that isn’t built in comes to you via the Application Framework (what used to be called libraries).  Without an Application Framework, Curly Braced Languages can’t do much except write, “Hello, World.”  Unfortunately, that’s been done and is no longer monetizable.  Time to move on.

App Frameworks are supposed to be standardized so everyone can reuse that code, but fortunately, the best thing about standards is there are so many to choose from.  I recently read a 4 part article about Web Application Frameworks for the Python language and lost count of how many different frameworks were mentioned.  It was quite a good article, but you get a sense from it that App Frameworks can become another excuse to write more code especially if your language allows it.  The other problem with them is they are wicked hard to learn and understand.  Learning to write code in C is not bad at all.  The original book on C was 272 pages of clear easy to read text.  The original tome for learning to write in Microsoft Windows was Charles Petzold’s classic Programming Windows was a dense 1478 pages!  Did I mention learning Application Frameworks is hard?  That’s 5 times as much reading for the framework as for the language!

Quoting Beattie’s “Java Needs An Overhaul” on Frameworks gives a flavor of what it’s like and why it’s broken:

As a Java developer, I was always so amazed at how difficult it was to use the standard Java Class Libraries for day-to-day tasks. Every app out there ends up having to include 20MB of .jars in order to get even the simplest functionality working because Java libraries are so low-level and incomplete.

What’s worse, is that most of the frameworks are not that well implemented.  In fact, there are no great frameworks that solve all the 70% of problems that are the tax we’re talking about here.  This forces many large organizations to wind up writing their own framework, thereby empowering the internal crowd who wants code reuse so long as it is their code that is being reused.  The proliferation of these frameworks inside large companies is so extreme that the benefits are usually lost.  Hence more 70% tax burden.

Hey Wait, What Happened to Object Oriented Programming?

Yessir, making it easier to reuse code was one of the big promises of OOP.  I love OOP and have loved it since encountering Smalltalk.  I confess I’m an odd soul  because LISP was the first programming language I learned, which raises a lot of eyebrows.  I was a General in the OOP Wars where Borland C++ battled it out against Microsoft C++.  I even ran a startup that sold a Modula-2 compiler of all things, for a little while in the 80’s.  OOP is a powerful tool, but I have two criticisms of it.  First, as it is traditionally deployed by the Curly Brace Languages, it is incredibly baroque to the point of being extremely powerful yet almost impossible to master.  Experienced devotees of the Curly Braced OOP Priesthood will tell you that these constructs are exquisitely precise in letting them refactor their code along whatever architectural designs they desire, but that out of the universe of people who can write code, a much smaller universe can do object oriented programming.  This is a shame, because the original concepts for object oriented programming came out of languages like Smalltalk (and Simula) that were designed to make programming approachable by anyone.  There is a growing suspicion that OOP really doesn’t help productivity much at all, but I’m not yet ready to enter that camp myself.  However, more than one person has said that the reusability of C++ is not significantly better than C, and I am in agreement with that.

The second issue I have is that OOP doesn’t really facilitate code reuse very well.  It isn’t service oriented, it’s about controlling the fine grained behavior of objects in intricate ways.  In fact, one could argue that it makes a lot of code much harder for someone to read and understand because of all the things that happen implicitly and in many and varied locations.  Certainly anyone who has ever walked through a complex inheritance scenario using all the OOP bells and whistles in a Curly Braced langauge on code someone else wrote will tell you it was a harrowing adventure at best.  The old computed GOTO in FORTRAN has nothing on OOP when it comes to the power to obscure meaning.

What About Open Source?

Open Source has spawned a lot of code reuse in certain areas, moreso than any other trend I’ve seen in my career.  Definitely more than Object Oriented Programming.  I think its great, and I am a believer, but it has its limitations too.  A lot of Open Source code is intended to be reused as-is or extensively modified.  That is, its more like software that’s so cheap you may as well reuse it than software that is designed to be more reusable than other software.  Truly resuable code would not need much modification to repurpose it, or the modification involved would be extremely trivial.

That leaves Open Source reusability down to build versus buy.  If the code to be reused is suffciently simple to just write, most developers will not select Open Source.  If the code is extremely complex, and the economics or schedule do not allow for a rewrite, Open Source comes to the rescue.  This tends to push Open Source code sharing more towards the grandiose and away from the prosaic.  mySQL would be a heck of a thing for an app company to have to write before it could get on with developing expense reimbursement software.

Given this trade-off, I see most Open Source code reuse as being more a matter of module reuse.  Some fairly large and complex Open Sourced subsystem gets packaged up with some glue code and becomes the centerpiece of an important part of an application.  That’s great, but it doesn’t seem to whittle much off the 70%.

What’s the Answer?

If you want to quit wasting 70% of your efforts on software, you’re going to have to discover a way to reuse code–preferably reusing code that (Gasp!) other people wrote anyway.  Getting back to the service oriented perspective, true code reuse benefits from the service oriented perspective.  Forget the Curly Braced Power Tool perspective for a minute.  Use the power tools to create the proprietary advantage that you currently only get to spend 30% of your time and resources on.  Look for a simpler, service-oriented approach to the 70% of functionality that is undifferentiated.  Favor simpler service-oriented approaches without making them too simple as to be unworkable.  This will minimize the amount of learning your developers have to do to reuse the code components.  This is why REST is rapidly becoming more popular than SOAP as a protocol for Service Oriented Architectures.  It’s simpler. 

A lot of things succeed because they are simpler.  C, in its day, was far simpler than Algol or PL/I or even COBOL.  C++ was simpler than the overblown Ada.  And Java simplified a lot of the issues that were on the C++ programmer’s mind.  Now lately we see that scripting languages like PHP, Python, and Ruby have succeeded well because they’re simpler than the Curly Braced Languages.

There is no one-size fits all, so why not choose a couple of sizes for different occasions?  Martin Fowler (author of one of my favorite books on Enterprise Patterns) puts it well when he says, “we will see multiple languages used in projects with people choosing a language for what it can do in the same way that people choose frameworks now.”  Or, as the Meme Agora blog puts it, we are entering an era of Polyglot Programming.

PS:  While you’re thinking about Polyglot Programming, consider that the Multicore Crisis is going to start kicking sand into a lot of the old machinery sometime soon anyway.  The Curly Braced Languages will be the ones hardest hit by it because they’re closest to the cores.

Related Articles:

Who doesn’t love Java?  (Part 2 of the Tool/Platform rants)

ESB vs REST (Another Case for Multi-Language Programming)

Java Device Drivers from Sun:  For those who don’t think you can talk to hardware in Java, here’s a detailed paper on how it works, and info on the Java Device Driver Kit (JDDK).  If you’re uncomfortable reconciling the notion of device drivers running on virtual machines, Sun makes a good case for it.  Their argument is that by letting the VM run as part of the kernel, you can create device drivers that are independent of the underlying CPU’s instruction set.  This is particularly important to Sun who have both SPARC and x86 to worry about.

Submit to Digg | Submit to Del.icio.us | Submit to StumbleUpon

Is Support a Cost Center or a Product? (If you do SaaS or Open Source, It’s a Product!)

I always find the RedMonk blog interesting, and this time it has to do with his post on Making Money in Open Source on Support.  Coté says some things that got me frothing at the keyboard again. 

Developers Need Support, But It Is Seldom Offered With Enough Bandwidth

First, on the likelihood you can make money selling support to ISV’s:

“In general, I’ve found that ISV programmers (people who write applications [packaged or SaaS delivered] to sell to other companies, not “corporate developers” who write in-house applications) are less prone to use support for software, closed or open source.”

and:

“This is the kind of mentality I encounter among programmers quite a lot: it’s insulting to them to suggest that they need help.”

Let me explain about the ISV perspective, because that’s the world I’ve lived in all my career.  This has amazingly little to do with machisimo, being too cheap, or being insulted.  Rather it has everything to do with bandwidth.  We’ve all used Tech Support.  Who do you know that loves it?  Sitting for hours on an 800 line being tortured by music and that painful interruption that’s worse telling you how important the call is to them.  So why don’t they answer then?  How would you like to be waiting on some Tech Support guy to tell you all the standard stuff (take 2 reinstalls and call me in the morning) while some high dollar Enterprise customer is chewing your CEO’s ear off about why your mission critical software doesn’t work?  You know its going to take 3 escalations to more senior folk before they even understand what you’re trying to tell them and meanwhile your CEO is ready to fly your entire team to Nowhere, Iowa to work at the customer’s site just to placate them.  Been there, done that.

The insult is not that I need the help, it’s that you think you’re helping by doing that to me! 

If you want to make money selling support, treat it as a product, not a cost center.  Don’t send me to Bangalore.  Don’t put a guy on the phone with my architect that can’t carry my Alpha Geek’s jock strap.  Get somebody real that can go toe to toe.  But is that really a viable model?  Can you afford to hire Alpha Geeks to deliver support?  Probably not, because they will only do it if they have that rare combination of Alpha Geekdom and craving human contact so much they’ll take it under the duress of Tech Support.

SaaS companies come off better in this respect because its easier for them to put their Alpha Geeks onto the problem.  The Alpha Geeks watch the problem as it unfolds and directly access the data center to fix it.  They don’t have to struggle to remote control the customer through an On-premise fix.  Service for SaaS vendors is a product, not a cost center, but it’s also a product that is cheaper for SaaS companies to deliver because the service can be delivered in many cases without them leaving their desk and sometimes without the customer even knowing.  The latter is a problem too if you want the customer to value the service, but we’ll save it for later.

Despite all that, Enterprise ISV’s still spend time on the phone to companies like Oracle and Microsoft trying to get help, and they keep their maintenance paid up because you never know. 

Support Types

Coté offers a good list of types of support provided:  bugs, scaling, configuring, upgrades, finger pointing (or proving who’s “right”: the software or the user), re-setting expectations (the software actually won’t scramble an egg inside it’s shell like the sales guy said), and your million dollar nightmare (customizing and supporting out-of-date deployments).

He goes on to suggest some other types peculiar to open source:  Updates, Platform Certification (“Stacks”), Product Improvements and New Features.  Yup, been there and delivered those.  There are two that deserve more discussion: being an advocate to the community, and professional services customization gigs.

On being an advocate, this seems so far removed from the realm of what Tech Support does, that I wouldn’t even include it here.  I’ve seen this work best when Marketing or Sales handled it as part of customer relationship management.  Yes, Tech should be able to do that, but I’ve rarely seen the skillset and mentalities located there to be succesful.

On professional services to customize, yes, this is a very real opportunity to sell more product.  It isn’t really a support issue though.  Yes, many open source consumers will just modify the code themselves, but I would hesitate to speculate that this happens the majority of times.  See my thoughts on Professional Services end runs though, as it is something you must guard against.

I want to cover a few types I’ve run across that are also biggies for support but aren’t mentioned:

Education.  A tremendous amount of Technical Support calls boil down to the customer needing to ask a question.  The question may be so complex or confusing that it gets escalated all the way to the Chief Architect, but its still a valid role.  Answering questions is important, and I would think even more so for Open Source where the questions may have to do with how the code operates.

Professional Services End Runs:  This has been the source of more bad feelings all around than any other phenomenon I’ve seen.  Here is the scenario.  The customer buys the product, but for a variety of reasons they do not have the money to get it properly installed:

-  They picked a bad VAR (low cost bidder, anyone?) who spent the budget without delivering.

-  They never could get enough budget internally for a proper engagement, and choose to finesse it this way because they’re cheap.  Don’t laugh, I’ve had customers ‘fess up that this is exactly what’s happening and persuade CEO’s to deal with it in the interest of future business.

-   The absolute worst:  Your own professional services people failed.  It may not even be their fault, but now the Customer has Righteous Indignation on their side and you will get that software installed or else!

-  Almost as Bad:  Your organization measures performance and pays on those measurements in such a way that one organization throws another under the bus to make their bonus.  Professional Services throws Tech under the bus.  Or its implicit, and Tech hires cheap people who can’t deliver and everything is escalated to Engineering.  Yuck!

Companies that make Services a Product instead of a Cost Center are much better set up to think about these problems and deliver a better experience to their customers.

All your tech support are belong to us!

I didn’t see much rumination about Oracle’s attempt to steal Red Hat’s business.  One of the problems of basing your model around selling support for an open source product is differentiation.  Perhaps you can achieve better focus, but someone else can take a credible shot at stealing your business.  At the very least this will exert downward pressure on your pricing.

Submit to Digg | Submit to Del.icio.us | Submit to StumbleUpon

Bumps in My Internet Journey (Links): August 27, 2007

This post introduces a new weekly feature for the SmoothSpan blog where I’ll list noteworthy links I came across during the prior week.  Call them “Bumps in My Internet Journey” because they made me stop and think!  If they made me think enough, eventually you’ll see a blog post about it.

Why Mahalo, TechMeme, and Facebook are going to kick Google’s butt in four years:  Scoble’s got an interesting take.  Everyone hates search engine Spam!

Attention Economy:  All You Need to Know:  Nice overview of Read/Write Web’s Attention Economy concept.  Eventually I’ll blog about this…

Denormalizing Your Way to Speed and Profit:  Because databases are an agent of the Devil when it comes to massive scalability.

Yahoo Pig and Google Sawzall:  Wherein MapReduce and Hadoop become Languages.  Don’t worry, to become a Languages is the most exalted thing in computing.  Adobe even made printers languages!

Profiting from the Content Delivery Network Wars:  They haven’t seen anything yet.  Amazon and the other big guys will roll Akamai et al up as part of the hosting package  you get when you buy their utility computing service.

What Makes an Idea Viral:  Seth Godin is always worth listening to.

Werner Vogels Tells Us About the Amazon Technology Platform:  As well as interesting glimpses into their culture.

By 2014, We’ll Have 1000-core Chips:  The amazing Tile64 has shipped with 64 cores.  Available today lest you thought the Multicore Crisis was far in the future!

Scoble and I Are On a Similar Wavelength About Social Graph Based Searching

I couldn’t believe the serendipity.  Not long after writing my post about Searching Blogs Instead of Google to avoid Spam, I read Robert Scoble’s excellent piece about Social Graph Based Search (or here for the meat).  We’re very much on the same wavelength here!  Scoble’s videos do a great job of explaining why the blog search method works.  In essence, Page Rank (Google’s search algorithm) is just too easy for SEO’s (Search Engine Optimizers) to cheat on.  In essence, create a ton of links to your page, populate it with the right keywords, and you can trick Google into sending you a zillion people no matter what trash you may have put there.

Scoble uses the term “SEO Resistant Search”.  Ironically, SEO Resistance, or rather, better relevance, is the reason most people use Google.  But this whole approach is ideal for the Open Search Engine Initiative I’ve proposed already.

Good reading here, thanks Scoble: it is indeed the basis for a whole new kind of search engine!

Why Don’t Search Startups Share Data, Part 2

I mentioned in an earlier post that search startups ought to look into a divide and conquer approach when crawling the web.  After all, one of the biggest complaints about a lot of interesting search services is they don’t find as much as Google does.  TechCrunch, for example, complains that Microsoft’s new Tafiti produces search results that are “not as relevant as Google or Yahoo“.  And yet, they also admit Tafiti is beautiful (as an aside, it is very cool and worth a look to see what Microsoft’s Flex killer, Silverlight, can do for a web site).  If the Alt search sites band together to do the basic crawling and crunching using Google’s MapReduce-style algorithms (possible based on the Open Sourced Hadoop Yahoo is pushing), they could share one of the bigger costs of being in business and ameliorate the huge advantage in reach that the biggest players have over them.

ZDNet bloggers Dan Farber and Larry Dignan ask whether Open Sourced Hadoop can give Yahoo the leverage it needs to close the gap with Google.  Their first words are that “Open source is always friend to the No. 2 player in a market and always the enemy of the top dog.”  I don’t think Hadoop by itself is enough, but if Yahoo were to create a collaborative search service, maybe it would be.  In fact, what if search was much more like Facebook only more open (Hey, if Scoble can do it with a hotel, I can do it with a search engine!)?  In a manner similar to my “Web Hosting Plan for World Domination“, Yahoo could undertake a plan for “Search Engine World Domination”.  Here’s how it would work:

-  Yahoo builds up the Hadoop Open Source infrastructure for Web Crawling.  Alt Search engines can tie back into that to get the raw data and avoid doing their own crawling.  Even GigaOm says “The biggest hindrance to any search start-up taking on Google (or Microsoft, Ask or Yahoo for that matter) is the high cost of infrastructure.“  Let’s share those costs and further defray them by having a big player like Yahoo help out.

-  Yahoo can also offer up the Hadoop scaffolding to do any massively parallel processing these Alt Search Engines need to compute their indices.  Think of it as being like Amazon’s EC2 and S3, but purpose-built to simplify search engines.  People are already asking Amazon for Search Engine AMI’s, so there is clearly interest.

-  Now here is there Facebook piece of the puzzle:  Yahoo needs to turn this whole infrastructure play into a Social Networking play.  That means they offer Search Widgits to any Social Network that wants them, and they let you personalize your own search experience by collecting the widgits you like.  Most importantly, Yahoo creates basic widgits that reflect their current search offering, but they allow the Alt Search Engines to make widgits that package their search functionality.  Take a look at Tafiti and see how it let’s you select different “views”.  Those views are widgits!

-  Yahoo gets a big new channel for its ads, and it gracioulsy shares the revenues with the Widgit builders because that’s what makes the world go round.  Perhaps they even have virtual dollars that can be used to pay for the infrastructure using ad revenue, although I personally think they should give away as much infrastructure as possible to attract the Alt Search crowd to their platform. 

Don Dodge, meanwhile, is wondering what the exit strategy is for the almost 1,000 startups out there trying to peddle alternative search engines.  It sure seems to me that creating this search widgit social network world solves a big problem for Yahoo and at the same time creates a lot of new opportunity for the exit strategy of these engines.  Suddenly, they have access to large volumes of data they couldn’t afford and a distribution channel in which to build an audience. 

Open Source Swarm Competition in the Search Engine Space is Born!

Submit to Digg | Submit to Del.icio.us | Submit to StumbleUpon