In­crease Reli­a­bil­i­ty and De­crease Costs

With the cur­rent (2008-2009) re­ces­sion, cost cuts and com­modi­ti­za­tion of both soft­ware and hard­ware, the end re­sult seems to be con­verg­ing to­wards the state pre­dict­ed by the late Jim Gray dur­ing his Tur­ing Award speech in 1998:

"Cheap and bug­gy. Some­times it will work, some­times not, and no­body will re­al­ly know why".

Giv­en the per­spec­tive of such a world, it seems like some pre­cau­tions are jus­ti­fied. Since it can't be re­peat­ed of­ten enough, here is the Atomikos view on how to al­le­vi­ate all this:

• Use our trans­ac­tion tech­nol­o­gy to avoid data in­con­sis­ten­cy af­ter a fail­ure or crash. It acts like an in­sur­ance, re­al­ly: you don't need it when things are fine, but when things are turn­ing bad you're sure glad to have one!
• Use queu­ing to your ad­van­tage. Avoid de­pend­ing on the avail­abil­i­ty of a re­mote ser­vice by de­lay­ing re­quests un­til they can be per­formed (i.e., when the re­mote ser­vice is up).
• Add vir­tu­al­ly un­lim­it­ed scal­a­bil­i­ty while you're at it...

The com­bi­na­tion of tech­nolo­gies and tech­niques out­lined here will in­crease your re­li­a­bil­i­ty while de­creas­ing costs. You save on ex­pens­es by us­ing com­modi­tized hard­ware and soft­ware. You also save on man-hours of de­vel­op­ment be­cause our prod­ucts will al­low you to fo­cus on the hap­py path (fail­ure han­dling is au­to­mat­ed to a large part by our soft­ware). This sig­nif­i­cant­ly de­creas­es the com­plex­i­ty of the work­flow your de­vel­op­ers have to code, main­tain and de­bug. Less code in turn means less bugs, so this again in­creas­es re­li­a­bil­i­ty. Isn't that beau­ti­ful?