We do, and we're going into Azure native tech (Reliable Actors/Services). Azure tech is designed to overcome one of the major limitations of the cloud, which is:
bad stability problems
The cloud is inherently unstable. If you have this problem it means that your architecture isn't ready for the cloud. This is why software developers are interested in consensus/fault-tolerance in the first place. Azure might be more unstable but at the end of the day the degree of stability is completely moot. If your software isn't designed for the cloud bad things will eventually happen. It doesn't matter if it takes hours, minutes, or days.
That is the reason we chose Azure: Reliable Actors/Services are a huge boon when it comes to writing software that correctly deals with cloud conditions because they are architectural patterns that are built for it.
This is why Netflix uses chaos monkey[1]. Even the Azure SDK ships with a chaos monkey script. If fault tolerance is not a concern of yours then cloud should be your very last concern. We tried slapping on-premise architecture on the cloud (evaluating AWS, RackSpace and Azure) and we had some degree of stability problems across all of them.
The MS Azure documentation and training makes it pretty clear about application developers having to cope with "transient faults" - they even supply libraries to cope with it!
Exactly, appropriating the transient fault application block was the first step in getting our architecture to work on the cloud. However, connections to SQL are merely one part of the puzzle.
Instances of your worker nodes might also simply vanish.
* If you only have one node this is a "hard fault." Users cannot use your application until the node is restored.
* If you have more than one it's a "soft fault." Users can often immediately retry their request.
* If your own architecture is correctly designed (many nodes with fault tolerance) it is a "transient fault." Users are oblivious to the fact that one of your 100 nodes failed - even if that specific node was servicing their request.
Comments
We do, and we're going into Azure native tech (Reliable Actors/Services). Azure tech is designed to overcome one of the major limitations of the cloud, which is:
The cloud is inherently unstable. If you have this problem it means that your architecture isn't ready for the cloud. This is why software developers are interested in consensus/fault-tolerance in the first place. Azure might be more unstable but at the end of the day the degree of stability is completely moot. If your software isn't designed for the cloud bad things will eventually happen. It doesn't matter if it takes hours, minutes, or days.
That is the reason we chose Azure: Reliable Actors/Services are a huge boon when it comes to writing software that correctly deals with cloud conditions because they are architectural patterns that are built for it.
This is why Netflix uses chaos monkey[1]. Even the Azure SDK ships with a chaos monkey script. If fault tolerance is not a concern of yours then cloud should be your very last concern. We tried slapping on-premise architecture on the cloud (evaluating AWS, RackSpace and Azure) and we had some degree of stability problems across all of them.
[1]: http://whatis.techtarget.com/definition/Chaos-Monkey
The MS Azure documentation and training makes it pretty clear about application developers having to cope with "transient faults" - they even supply libraries to cope with it!
Exactly, appropriating the transient fault application block was the first step in getting our architecture to work on the cloud. However, connections to SQL are merely one part of the puzzle.
Instances of your worker nodes might also simply vanish.
* If you only have one node this is a "hard fault." Users cannot use your application until the node is restored.
* If you have more than one it's a "soft fault." Users can often immediately retry their request.
* If your own architecture is correctly designed (many nodes with fault tolerance) it is a "transient fault." Users are oblivious to the fact that one of your 100 nodes failed - even if that specific node was servicing their request.