Per usual, James Urquhart published a thought provoking post on cloud computing and geopolitics. Recently, as part of my 100-day cloud watch, I’ve pointed out the importance of cloud computing environment location in respect to data residence. In his post, James goes further, or perhaps better stated, starts earlier. Raising awareness on the paths that data travels, to reach its destination:
“How would an application operator deploy applications at a minimum "distance" from users in a network sense, without finding themselves passing data through a country that would jeopardize the safety of that data? Again, the path your data takes between two physical locations may not be the path you expected.
You are already seeing some examples of how the governments and corporations are trying to mold the Internet and "the cloud" to fit into human geopolitical realities. Countries like China, Iran, Pakistan, and others have demonstrated their willingness to control the Internet transoms over their nation’s borders, and to apply technology to controlling the "border traffic" at those crossing points.”
In his post, James makes some great observations on computing versus world boundaries, and poses a challenge for cloud computing, networking, business and political leaders:
“What’s missing, however, is any form of formal infrastructure within the Internet/Intercloud itself to "automate" mapping the human world to the computer world. Is this even possible, I often wonder. Can we (or, more to the point, should we) try to "codify" the laws and regulations of the world into digital form, allowing computer networks and applications to self-regulate?
What would the political fallout of such a system be?
In cloud computing, "virtual" geography and "physical" geography are both extremely important, and it’s up to humans to keep the two aligned. Because this is complex and prone to error, it may be one of the great business opportunities to come out of the disruption that cloud computing is wreaking on IT practices.”
Read his post. Remember it’s not just the destination, but also the journey that counts.
Tagged as:
geopolitics,
intercloud,
James Urquhart,
location
Posted by brenda michelson at 11:38 am in 100-days, Cloud Watch, adoption, data, networks | Permalink
| Comments(0)
| Trackback URL
Although Software Design is further down my enterprise considerations list, when Gojko Adzoc’s post on lessons he has learned developing in Amazon’s AWS environment, I knew I had to pass it along. The post describes new challenges for developers who have previously worked in a purpose-built, directly controlled, infrastructure environment. These challenges range from server reliability to storage speed. After articulating the challenges, Adzic offers advice on “How to keep your sanity”:
“It took me a while to understand that just deploying the same old applications in the way I was used to isn’t going to work that well on the cloud. To get the most out of cloud deployments, applications have to be designed up-front for massive networks and running on cheap unstable web boxes. But I think that is actually a good thing. Designing to work around those constraints makes applications much better – faster, easier to scale, cheaper to operate. Asynchronous persistence can significantly improve performance but I never thought about that before deploying to the cloud and running into IO issues. Data partitioning and replication make applications scale better and work faster. Sections of the system that can work even if they can’t see other sections help provide a better service to customers. This also makes the systems easier to deploy, because you can do one section at a time.
To conclude, there are three key ideas to keep in mind:
- Partition, partition, partition: avoid funnels or single points of failure. Remember that all you have is a bunch of cheap web servers with poor IO. This will prevent bottlenecks and scoring an own-goal by designing a denial of service attack in the system yourself.
- Plan on resources not being there for short periods of time. Break the system apart into pieces that work together, but can keep working in isolation at least for several minutes. This will help make the system resilient to networking issues and help with deployment.
- Plan on any machine going down at any time. Build in mechanisms for automated recovery and reconfiguration of the cluster. We accept failure in hardware as a fact of life – that’s why people buy database servers with redundant disks and power supplies, and buy them in pairs. Designing applications for cloud deployment simply makes us accept this as a fact with software as well.”
In the post, Adzic maintains that he is a cloud computing advocate, his goal of the post, and the presentation it came from, was to “expose some of the things that you won’t necessarily find in marketing materials.”
Read Adzic’s post. Remember the 4th Enduring Aspect of Cloud Computing.
Tagged as:
Amazon,
EC2,
enterprise considerations,
Gojko Adzoc
Posted by brenda michelson at 5:28 pm in 100-days, Cloud Watch, networks, performance & reliability, readiness, software architecture, storage | Permalink
| Comments(0)
| Trackback URL
