Rocket Science & Open Standards

Here is a letter I sent to a Lead Architect I met at a particular "space agency", as a follow up to our discussion about one of their infrastructure redesign projects. I think many clients are wrestling with this topic, so I offer this as an open/anonymous letter for your consideration.

Hi <----->,

It was great meeting with you yesterday. Thanks for sharing some insights into your strategy and challenge. I applaud you for starting to think about your future infrastructure needs and the potential risk of status quo at this point. Too many clients wait until the last minute and then they find themselves in an urgent/reactive mode making poor and costly choices.

I was thinking more about your philosophy regarding the use of non-proprietary open standards. This is very important, and I'm a huge advocate of this approach. I agree that it is critical to architect a solution that promotes choice and permits you to migrate to different products and technologies and vendors without cost, delay, or pain. To me, and I would guess to you as well, this is the reason to select interoperable standards and "open" platforms.

As you know (although many people confuse the two) the "open source" movement is different than the value proposition of "open standards". The measure of whether something is open or not is determined by the cost/pain of extracting that component out of your solution and replacing it with another choice. Examples could include the server vendor (eg: HP to Sun Opteron), the OS (eg: Linux to Solaris), the SAN fabric switches, the J2EE App Server, the SQL Database, the Compilers, etc, etc....  Note that open source does not factor into the measure of being "open".

I do also recognize the value of open source. It can increase the rate of innovation through a global community. It can provide for independent security assessment and validation. It can offer a client the ability to tweak the product for their own needs (although I generally discourage this due to support and quality and complexity reasons). As you know, Sun has open sourced the code to Solaris10! I never thought I'd see that happen, but it has.

There is another aspect that I believe is part of your strategy. If you build the upper layers using interoperable standards, then the layers below are often interchangeable even if they aren't fully open. For example, if you build your business logic using J2EE running in an App Server, then the OS and the H/W choice is much less "sticky". You can switch between SPARC and Opteron or between Solaris and Linux without cost or delay or pain. Also, if you code and compile your own apps, you can choose to use standard library calls that make the underlying platform easy to change.

There are, however, drawbacks associated with choosing products that do not have a well established and directed engineering and support mechanism. The key, in my opinion, is to select partners and products that embrace open standards (and open source) and yet have an auditable and proven support and engineering model. This gives you high confidence in your solution as well as the ability to change at will.

I believe Linux is fine as a personal desktop operating environment. I also think Linux can be a viable choice on which to run stateless replicated (load balanced) presentation tier services. However relying on Linux to host mission critical applications and tier 2+ services, in my professional opinion, will significantly increase the risk associated with your mission support. It just isn't mature enough yet. There are reliability concerns, security concerns,  scalability concerns, functionality concerns, support concerns, bug fix responsiveness concerns, legal indemnification concerns, etc.

I offer the same counsel about the choice of your supplier of Opteron servers and other components in your solution stack. Many have found that the potential initial cost savings associated with building a whitebox generic server, and using freeware software, is often lost many times over in the frustration and hassle of dealing with bugs and quality issues and the lack of features. These issues are highly mitigated when using "open standard" products offered by a partner like Sun that pours billions per year into R&D and QA.

I'll close by reiterating my suggestion that these should probably play a role in your infrastructure redesign:
  - Sun's industry leading Opteron servers (btw, our future roadmap is extremely interesting)
  - Sun's open source Solaris 10 operating environment
  - Sun's open standards "platform software stack"
          (app server, directory server with ActiveX interoperability, portal server, identity server, etc, etc)

We also have an interesting suite of virtualization and automation solutions, including our N1 Service Provisioning Server.

I'd love to support you in learning more about and even evaluating these products and technologies and strategies. I'd also be glad to act as a general sounding board and/or provide architectural review and guidance as desired.

Please feel free to contact me any time. I look forward to hearing from you.

Best Regards,

-- Dave

Dave Brillhart
Lead Architect - Strategic Government
Client Solutions Organization
Sun Microsystems, Inc.

Comments:

Post a Comment:
Comments are closed for this entry.
About

dcb

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News
Blogroll

No bookmarks in folder