Links
Want to work with me at the $DAYJOB?
I am the CEO of OmniTI where I do all sorts of stuff I find absolutely fascinating.
Writing
I spent a few years writing down my thoughts about how one should approach problems. If you're looking for a how-to guide, a cookbook, or a reference this book is not for you. If you want to learn by challenging the way you think, pick up a copy.
Hacking
It is rumored that I write code sometimes. I often don't believe this myself, so I use this to follow what it is that I'm working on:
Categories
Recent Entries
- Surge 2011 CFP Extension
- Tuesday, April 5 2011
- Top 5 "software to saas" culture shocks.
- Tuesday, March 1 2011
- Using Esper to manage real-time data.
- Friday, February 4 2011
- #ywahusty
- Friday, February 4 2011
- Devilishly Hot Deviled Eggs w/ Company
- Sunday, January 23 2011
- Why haven't all my graphs been useful like this?
- Thursday, January 20 2011
- Capacity Planning
- Wednesday, January 5 2011
- Theo seeks aspiring database administrator
- Tuesday, December 28 2010
- Web Performance Boot Camp
- Tuesday, November 2 2010
- Perform or Die
- Friday, October 29 2010
Quicksearch
Archives
Syndicate This Blog
Designing for vendor malfunctions
Many people have asked me how Oracle's recent actions will affect OmniTI and our clients. As you may or may not know, a considerable amount of OmniTI's internal infrastructure is built around the OpenSolaris platform. Given Oracle's recent announcement about their path forward toward Solaris 11, what does that mean for OmniTI and OmniTI's customers?
In short: what's old is new and what's new is old and business as usual.
The long of it has very little to do with Oracle and a lot to do with how we operate here at OmniTI. For a little over ten years, I've been on the international conference circuit speaking on the subject of scalable architecture design and implementation. While these talks discuss design patterns for scalable systems, they also strongly emphasize both strategic and tactical technology selection. One of the things I hope that attendees left with is a mission to maintain a strategy for avoiding technical lock in. A quick recapitulation:
If a vendor tells you (or you believe) that their solution is the only way to solve a particular problem, find another way. If there are multiple solutions to your problem and theirs is the "best," that is where the conversations start, business is won and relationships are made. Additionally, understand that the solution a vendor sells you is not for your problem; rather, it is for the portion of your problem that is shared by other companies in the target audience for that particular product. Armed with this information, apply some critical thinking when selecting technology. At OmniTI, we think critically… always.
Oracle recently made a decision to close the development processes around the future of Solaris. I am personally disappointed by their decision and it will necessarily mean that my participation in the OpenSolaris community will stop (as the community will no longer exist). While I am personally disappointed, I believe that their proposed business plan for Solaris 11 is sensible and will add more shareholder value over the short and medium term. As for the long term, the classic tech "long term" strategy applies: adapt to the market as it changes. Ellison has, in my opinion, been true and good to his shareholders. Back to how this affects OmniTI and our customers, we purchased Solaris 10 with support and we planned to purchase Solaris 11 with support. While the lack of nightly code drops and open development makes Solaris 11 less valuable, it is still valuable.
As with every technology selection we make, we reevaluate regularly to confirm that our decision remains correct. Additionally, we always implement systems in such a way that technology components can be gutted and replaced with relative ease. Could we transition our infrastructure from OpenSolaris to FreeBSD and/or Linux? Yes. Would the transition be relatively quick and painless? Yes. Why? Our job is to design, implement and operate systems that survive software malfunctions, hardware malfunctions, and vendor malfunctions. We've done our job by strategically designing our systems and maintaining the discipline in our tactical maneuvers that ensure our customers vitality even under changing circumstances.
Will we be moving our Solaris-based platforms away from Oracle? Based on what I know today, no. Will we be moving our OpenSolaris-based platforms away from Oracle? Maybe. We'll wait and see and cross that bridge if needed. Why such a casual attitude? At OmniTI we spend time throughout every project engineering and maintaining those bridges. When the time comes to cross one, it is a simple and casual stroll.
Thursday, August 19. 2010 at 10:10 (Link) (Reply)
I wonder: whether the converse is true of OmniTI's customers' data? It is common, to the point of banality, to see 30-something developers treat the RDBMS as a simpleminded file store, embedding the ACID in the application code, and thus locking in the customer base to them.
Switching out RDBMS is fairly simple in this situation for the vendor, since little if any of the RDBMS services are actually used. For the customer, the data is utterly opaque and fragile, without the vendor's code. Converting to some other front end to their data becomes a real issue. I've been there, done that. It ain't fun.
Thursday, August 19. 2010 at 11:06 (Link) (Reply)
It's not the converse at all. If you can only accomplish your RDBMS goals with your vendor's proprietary extensions, you need to rethink your approach. We're pretty careful of how we go about using things like Oracle and PostgreSQL to make sure we can switch horses if one goes lame. I highly recommend others do the same.
Thursday, August 19. 2010 at 12:08 (Link) (Reply)
I wasn't talking about proprietary extensions, although those can be worked around with translators such as SwisSQL (so they say, I've not attempted to do so).
My point was the extent to which software vendors, titularly building RDBMS applications, ignore normal forms, DRI, and the like. Preferring to put the ACID enforcement in their application code (COBOL, java, VB, or whatever), and thus locking in the clients' data to the *application code*. One approach, not often taken I'll admit, is to use the referential support of the database to the max, and using the application code to merely paint screens and post data. Coders tend not to like that, again, in no small part because doing so frees the client's data from the *application code*. To the extent that extensions are avoided, the client's data is also agnostic to the database used to store the data.
Or, to put it in the terms of the original post, clients of application software vendors should look to protect themselves from vendor malfunction by choosing only vendors that 1) use industrial strength RDBMS (not simple minded files), 2) put the ACID of record in the schema/catalog/design, and 3) minimize use of RDBMS extensions. I just wondered whether that is the approach of OmniTI.