Tuesday, March 28, 2006

Busy Busy

I haven't had a chance to post much lately. I'm in the middle of a major webMethods upgrade. I have been playing around with the new Fedora 5 on the side. I'm really interested in the embedded Xen support. I'll put more out here about that and some distributed services concepts I'm toying with a little later as time becomes less of a constraint.

Wednesday, March 22, 2006

Monday, March 20, 2006

Slashdot | Fedora Core 5 Available

This is the distribution that is suppose to have Xen embedded into the OS as opposed to just available as a package. It holds some promise if you believe what Redhat is saying about it. 100ms switch times is pretty impressive if it is true. For those of you who are experienced in clustering, you know the complexity that can be involved. Bringing up the whole OS container somewhere in 100ms is fast and less prone to error than traditional active/passive clustering.

Monday, March 13, 2006

Application Availability

Software design and testing is directly related to the availability of an application. We all know that already. No amount of money spent on hardware can overcome a flaw in the application. We call these undocumented features sometimes. They can be very challenging to troubleshoot in a production system.

With Integration, these challenges become more intense. Multiple systems wired together and yes even loosely coupled systems can impact each other despite what all of the analyst and software vendors tell you. The question is how to overcome this complexity and turn out reliable systems that have little to no impact on each other. Well I would love to say I have the answer but the truth is there is no one answer.

Good sunny day and rainy day testing will take you far as well as good design and good documentation. Well trained operations and application support staffs will also contribute. But in the end the combination of variables in a large integrated environment both known and unknown are just to great to overcome. There are going to be issues.

So what to do? A few of pointers from hard learned experience:

1-Educate your management and your clients; setting expectations for realistic availability is key. ie deploying your app that you designed while coding it to a single server is not going to give you 5 nines.

2-Educate your staff. It's great that you know the app but you are not available 24x7 unless of course food, sleep, vacation are not something your require.

3-Practice recovering your app. Don't know how? When it is hosed in production is not the time to learn.

4-Know what else your app depends on. This is really key in integration work. Change management is a big deal.

5-Did I mention educate your management and your clients?

Just a few thoughts for the day as the fires have finally died out.:)

Tuesday, March 07, 2006

SOA Pipeline | Business Management << How Software Consolidation Will End Up Squeezing You >> February 26, 2006

More and more folks are coming to this conclusion. The hype is high but the reality is low for SOA. If you have seen the mixed adoption of OOP and the partial success of EAI and you were wondering if SOA somehow made all of those issues go away, in short the answer is no. SOA is a good thing but it is not mature, not yet.

Folks that found success with OOP and EAI will probably transition well into an SOA style of architecture. Everyone else will struggle. Why? Because integration is hard (esp. real time). Developing interfaces that are abstract and reusable is hard. Convincing clients and management that spending extra time on common information models is hard. Understanding the 8 million Web Services standards well let's not even go there.

Wednesday, March 01, 2006

98% of Java developers just don't need it

Well what do you think? I've often read that 90% of Java development is servlets. I have definitely seen folks buy expensive app servers to do very basic stuff. But I've been kind of trolling the Axis support list and I can say there is more going on with Java than just servlets and basic development.