|
|
article page
| 1
| 2
| 3
| 4
| 5
| 6
|
From the network point-of-view, it does not matter if it we connect big computers or big clusters; all the important activity happens in the islands, and the network between them has value only in providing connectivity. (As some telco executives see it, this is "marginalization" of the network, although how something can be marginalized yet remain indisputably essential is an interesting topic for discussion, but not here today.) However the cost of telecom networking can easily be more expensive than computing costs in a cloud architecture, so networking costs become a strong argument against the cloud. Paul Wallis points out: "This has implications for how one structures Internet-scale distributed computing: one puts computing as close to the data as possible in order to avoid expensive network traffic." For cloud computing, that makes the relative cost of telecom services (bandwidth and connectivity) vs. the cost of buying and maintaining compute power and applications a key economic driver for Clouds to succeed. The more attractive the cost of bandwidth and the availability of services, the faster the business uptake of cloud computing.
Add this to the related requirements for cloud computing – it has to be better than the home grown product, must provide features that are very costly on the home business campus and cheaper on the cloud utility, and must be ready to provide these services on demand, every day or as needed.
An example of a high cost, occasional-use service that demands high availability of traditional telecom is disaster recovery. But disaster recovery is not a Cloud Computing product! This is because fundamentally Cloud Computing is more than utility computing. By embedding SOA, SaaS, and service-level agreements, by incorporating virtualization and grid resiliency, Cloud Computing effectively eliminates the need for disaster recovery. By spreading the redundancy throughout the cloud, the only point of failure is that narrow network path that provides access from the user to the cloud. But today's telecom service providers offer many different networks and access avenues. When these are seamlessly linked with SIP or IMS infrastructures, getting to the cloud anywhere, anytime, anyway is realized – and provided via a service provider product. The Cloud Computing people understand this; witness the high-profile contributions of Microsoft's SCF team to the TMForum's Service Delivery Framework project.
Paul Wallis, again: "There has been talk of a two tier internet where businesses pay for a particular Quality of Service, and this will almost certainly need to happen for The Cloud to become a reality… In such a climate
|
|
By embedding SOA, SaaS, and service-level agreements, by incorporating virtualization and grid resiliency, Cloud Computing effectively eliminates the need for disaster recovery.
|
|
[of network failures] it will require asking the business to take a leap of faith to find solid footing in the cloud for mission critical applications." Service providers have the opportunity to twist the notion of security from a blocker to a driver. Is something more secure because you control it? Or more secure because it has network resiliency and unified focused management? For this argument to succeed, technology which is new and far from universal must become commonplace in networks and clouds. For real security, SAML might not be enough, and we might need dedicated or virtual networks running protocols such as secure-RMI. However, some security advantages are obvious: as soon as a cloud provider patches a security vulnerability, all its customers are immediately protected.
There are still a lot of outstanding issues. Because the cloud originally was a technology concept and then started becoming a business, it was not designed from the bottom up to meet specific business requirements. When MCI designed the Global Service Ecosystem, an early telecom version of Cloud Computing at MCI, the team (which included Wedge Greene) built in a data layer architecture that overcame the latency issue by dynamically positioning data into storage near the user access point (something like the way Akamai positions streaming close to the user access point.) Telecom can continually track the movement of users, and user movement is always slower than network transfer speeds. Dynamically mobile code and forward replicated business data objects, reflecting a global data service, coupled with network's knowledge of where the user is, can always put applications and data very near the mobile user. Latency is no longer an issue. Further, the reliability issue was addressed through a survivable application grid, a technology now common in today's service-oriented grids. But for this we need "routed" applications, not the point-to-point applications, which are typically used in clouds today. In effect, for the cloud to become a dominant telecom service product, it needs the architecture of the service ecosystem. Currently, this is not the architecture for Cloud Computing, but it is a possible path of strategic evolution: the telecom industry just needs to provide strategic direction and marshal resources to shape this outcome.
article page
| 1
| 2
| 3
| 4
| 5
| 6
| |
|
|
|
