Fubaredness Is Contagious

Designing a fully-automated or nearly-fully-automated computer system with many moving parts and dependencies is tricky, whether a system is distributed, hyper distributed or otherwise. Failures happen and must be dealt with. After a while, most folks grow up from “failures are rare and can be ignored” to “failures are not that rare and can not [...]

[Read more →]

Most folks in the industry are familiar with “distributed applications.” If app components are running on multiple hosts and need to communicate with each other using network, the app is said to be distributed.
Distributed applications are known for complexity of assuring all components are on the same page as to what’s going on around them. [...]

[Read more →]

I recently reached an interesting conclusion. When you are trying to eliminate a single point of failure from your architecture, it’s almost always beneficial to first go with a 2-way redundant solution (active-passive or active-active pair, whichever is easiest to implement) and only then go to N-way, N > 2, only if necessary.
One huge difference [...]

[Read more →]

I left the following comment at CloudAve yesterday, on a post titled Open Federated Clouds And Sun’s Cloud Announcement.
Interesting. Looks to me it all depends on how you look at different clouds – as infrastructure providers or as software platforms.
The former case is roughly similar to buying Internet connectivity for your office from 2 different [...]

[Read more →]

I was recently building a distributed system which will run in Amazon EC2 cloud. It consisted of several instances of the same AMI that were going to communicate with each other using private IP addresses assigned by EC2.
One interesting scenario popped up in my head. What if, after initial discovery of each peer’s internal IP [...]

[Read more →]