On 3/25/2011 1:57 PM, John R Pierce wrote:
>
>> Not everything deals in transactions, though. The recently popular
>> distributed database versions that scale up are more about doing
>> something reasonable in scenarios where you can't guarantee a
>> transaction state (where 'reasonable' is defined by the application).
>>
>
>
> mmm, yes, 'data maybe'. good enough for web forums and blogs.
>
> I'm getting really annoyed when upper corporate management keeps saying
> we need to cloudify our highly transactionally intensive manufacturing
> execution system where we can't AFFORD to lose ANY data.
Transactions aren't about not losing data, they mean you fail completely
in any situation where you can't guarantee that all copies are
synchronized. Things do break and there are many situations where not
failing and eventually restoring consistency with data stored during the
time consistency was impossible is a better approach. Yours may not be
one of them. There is a lot of literature on CAP theory if you haven't
been swamped by it already. And riak looks really sensible to me,
although I haven't done more than fire up a test instance yet.
> Of course,
> when presented with a plan that has a 8-9 figure budget for a 4 year
> transition to a new 'cloud' architected system (have to do it in overlap
> or the factory stops til the new system is fully deployed and working,
> and every single application has to be reengineered from scratch) they
> cough and sputter.
So no one develops new applications there?
> So, instead, we cross out 'data center' and write 'cloud' on our
> architectural diagrams, and go ahead and virtualize as much of the
> middleware layers as we can, since new hardware is so much faster than
> the older hardware the middleware was designed to run on (hey, 8 vmware
> esxi boxes running 50 Linux VMs is a cloud, right?)
I can't criticize that since we are doing the same. Odds are that you
could redistribute the apps to run directly on 8 linux hosts with better
performance, but hardware is cheap and VMs are easy.
--
Les Mikesell
lesmikesell at gmail.com