Yesterday Peter Farrell pointed me to a brochure site he did for a friend. Looks great, it's running Mach-II 1.8 beta, using SES URLs, all great stuff.
Then he told me it was running on Open BlueDragon for Google App Engine (GAE). VERY cool. You can read a bit more about it on Peter's blog. I could be wrong, but I think this may be the first production site running on OpenBD on GAE. (If there are others out there, I'd love some links!) The interest in running CFML apps on GAE has really been picking up lately, and with good reason. It's a dead simple way to deploy CFML applications to Google's cloud, and unless the site is going to get a huge amount of traffic it's completely free. Free CFML engine, free hosting, easy deployment right from Eclipse ... there's a lot to love here. No more hunting around for cheap shared hosting accounts that are so restrictive they're barely usable, no more spending money on a VPS if you don't need one (though I highly recommend them!), you just build your app and deploy right to GAE. Since a lot of people I've been talking with recently aren't all that familiar with GAE, I'd like to point out that it's a bit of a different paradigm than many other cloud computing services. Unlike Amazon EC2, where you're dealing with things at the server level, GAE is application-oriented. So you don't have a server with an operating system on which you install a servlet container and OpenBD, instead you're simply deploying individual applications to Google's Java infrastructure. It's a really nice way to do things since the server-level stuff is all handled for you. Be aware that there are some restrictions on what you can do on GAE vs. deploying on your own server, but really these are just differences rather than any huge impediments:
An old college buddy called me last week. He works for a manufacturer who sells a product into data centers (among other markets) and he wanted a data center professional's insight into "this whole cloud thing."It seems a colleague of his is trying to convince his whole company to prepare for the cloud computing paradigm shift, where "everything will exist within about ten huge data centers." I have to admit, I laughed when I heard that. My friend wanted to know what impact cloud computing will have on the future. "Is what this guy's saying really going to happen?"
In my answer, I went over how much of the thinking and hype surrounding cloud computing is built upon fallacies while ignoring the market realities. Let me outline those fallacies here.
Could computing fallacy #1: New technology always supersedes old technology
I wish I had a dollar for every time I heard or read something akin to "Everything will move to the cloud." The basis of this statement is a deeply held fallacy in the minds of so many people who follow technology, especially the "pundits" one reads in the trade rags and blogs. Everything? Really?
For everything to move to the cloud, the cloud would have to become the solution to all the needs of all people. This is impossible.
This fallacy is an extension of an old economic fallacy -- that of the limited market. The more gains X makes in a market means that Y and Z lose. For some reason, perhaps people's desire to sort everyone and everything into piles named "winner" and "loser," they assume that in any given market there can only be one winner and everything else loses.
So all thinking becomes weighted toward the supposed winner. In reality, markets constantly shift and, for all practical purposes, have no limits. Further, if you have a product or service that satisfies a set of customer needs better than the competition, you will make sales. Not all customers have the same needs, so there is no way that any single technology, service or business model can exclude all others by its mere presence in the marketplace.
Indeed, for everything to move to the cloud, the cloud would have to become the solution to all the needs of all people. This is impossible.
For the new to replace the old seems like the natural order of things -- after all, we no longer drive horse-drawn buggies, right? But one could argue that the modern car is the natural evolution of the buggy, with the internal combustion engine merely replacing the horse itself as the prime motivator. The aircraft did not replace the car, despite the predictions of nearly all pundits in the middle of the 20th century. (Where are our flying cars, anyway?) Nor have many other older technologies vanished; trains and ships still traverse the planet despite much "better" technologies having been developed since their invention. Television hasn't fully replaced radio or movies. Those markets instead have expanded to allow all these technologies to survive in their own niches. Those niches may expand and shrink over time, but the new technology rarely, if ever, completely replaces the old.
Bringing it back to information technology, mainframes are still built and sold despite the perception that they're technological dinosaurs. Why? Because they serve a need that newer technologies cannot meet. If anything, the market for mainframes remains about what it was a decade ago. Sure the market isn't growing like it was in the 1960s, but it is likely actually larger in terms of the number of physical units operating than it was back then.
Cloud computing, even if it is wildly successful, will not replace the forms of computing we use today. It will only expand the markets and provide new solutions to some old -- but mostly new -- problems. Technologies really bloom and create markets when they solve new problems rather than replacing the solutions for old ones.
Cloud computing fallacy #2: Cloud computing is new technology
It is not a new technology, just a new name. At its core, cloud computing represents no new technology. It is just a buzzword du jour that's applied to a collection of older technologies being packaged and sold in a new way.I've heard the term used to describe everything from Amazon's EC2 to Skype, from Gmail to Salesforce.com. I find it hard to believe that these all fall into a single definition. Their sole commonality is that they are services delivered over the Internet.
It seems I'm not the only one with this opinion.
If anything, I would argue that cloud computing isn't really about technology at all, but really a way of provisioning and selling computation.
Before it was called "cloud computing," it was called various names at various times, as the concept iterated itself though history: Time sharing, client/server, network computing, thin clients, utility computing, application service provider, grid computing, Software/Platform/Infrastructure as a Service, etc. None of these terms, including "cloud computing," describe any new technology, only ways to deliver or provision existing technology. It boils down to rental rather than purchase, period. If I rent you my car, I cannot claim to have invented the automobile, or the concept of renting it, either.
Fallacy #3: Cloud computing will replace data centers
I've heard this fallacy from many sources. Cloud computing represents no threat to the data center whatsoever. If anything, it will just require more data centers. That answers my friend's worry -- but how did this fallacy originate?Well, data centers are very expensive. They are very expensive to build and very expensive to operate. As power densities (that is, the number of Watts per square unit of measure available within a given data center) go up, so do construction costs. The current average cost to build a data center in the U.S. up to modern standards is between $1,500 and $3,000 per square foot.
Compare this to the cost of the average office building at $150-$200 per square foot and you'll understand why CFOs tell their CIO/CTO counterparts to rent rather than buy. And that is just the building part. Once the construction is complete, you have to operate that facility, and that costs money too.
When you boil down what a data center does, it is pretty simple. A data center is a facility that turns electricity into bits, usually on a grand scale. The byproduct of that industrial process, like so many other industrial processes, is heat. Power comes in, usually in vast quantities, and gets burned up by the silicon and rotating discs and transformed into bits, which exit the facility on the wires to be delivered to you, the consumer of bits. This makes heat, which has to be mitigated by mechanical cooling, because without cooling, the computers will fail faster. This very website resides on a server in a data center. This server runs 24 hours a day, and even when people are not reading these bits, it burns up energy and makes heat all the day and night. Multiply that by millions, if not billions, of servers running in every data center around the globe. Now layer on top of that the cooling systems to mitigate the generated heat and you'll see how operating these facilities is very costly.
Cloud computing doesn't change data centers or their economics. Cloud computing providers still have to build and run data centers or rent the space from colocation providers. That requires capital expenditure. In order to pencil out economically, the cloud provider has to either charge its customers enough to pay for the build in a reasonable amount of time and cover the monthly operating costs, or oversell its capacity and hope it doesn't bite the business in the ass.
This is why I've said the only reasonable current cloud provider business model is Amazon's, which is based on excess capacity. Essentially, the cloud customers contribute to Amazon's data center return on investment while they scale their own operations. It is a brilliant model. But anyone who is starting out as a standalone cloud provider faces a rough road to profitability.
All the world's computing needs cannot be collapsed into those "ten huge data centers" my buddy heard about. The reality is that as industry, business and society use more and more information technology, there will be more and more data centers. They will range in scale from re-purposed broom closets to giant campuses of warehouse-sized facilities. Many organizations have very specific needs that cloud computing may never be able to address, and for those organizations there always has to be the choice of a traditional facility.
Cloud computing fallacy #4: Cloud computing can work for any IT need
There are several IT needs that cannot be solved with cloud computing. Meeting audit requirements is one. I've written about this fallacy before, and it caused a bit of an uproar. It seemed to be the first time anyone brought this issue up, and it became a hot topic in the cloud blogosphere for a short time. I felt vindicated when a cloud provider admitted what I said was true.The basis of cloud computing is the same basis as Web hosting -- your data on somebody else's servers. The same reasons that people chose to not use a Web host apply to a cloud provider: control of assets, risks associated with overselling capacity, support concerns, interoperability concerns. There are literally hundreds, if not thousands, of reasons why IT organizations and individuals would prefer to keep their data out of a public cloud computing system. Most come down to a single word, which is trust. That brings us to our last fallacy.
Cloud computing fallacy #5: The cloud is secure
Cloud computing is no more secure than any other form of computing, which is to say, not very. Or perhaps more accurately, as secure as it is designed and managed to be. For an excellent analysis of data security in a cloud environment, I highly suggest reading Rich Mogull's thoughts on the subject.Rich obsesses about all things security and does a far better job than I could in delving into the specifics. To his analysis, however, I'll add a more encompassing and less data-specific view of security that is more about trust and consequences than the integrity of the data itself.
The greatest hurdle to the widespread acceptance of cloud computing is trust. Trusting one's data to systems whose location, condition, environment and state of load are virtually unknown is a difficult thing to do. Many of these questions apply to any services (hosting, colocation, Software as a Service, etc.) purchased online, but the "cloudy" nature of cloud computing amplifies many of them beyond simple answers found in other scenarios.
- How well is that data protected?
- How stable is the company that owns the infrastructure?
- Is the data center owned and maintained by the cloud provider or is it colocated in some other company's facility?
- If the latter, is the cloud provider keeping current on all its bills or is installation subject to suspension by its colo provider?
- What about bandwidth?
- Is the cloud provider multi-homed?
- Does the provider have geographic redundancy?
- What happens when the power goes out?
- Has the provider tested its generator(s)? How well are its power backup, network and HVAC systems maintained?
- Is there anyone on-site if something goes wrong?
- What sort of service-level agreements does the provider have?
- What happens to our data if the cloud provider goes out of business?
- What sort of security is in place to monitor customers?
- What happens if somebody else on the system(s) we're using is a spammer?
- How is blacklisting handled?
- Could AUP violations by other customers impact our operations?
- Are assigned IPs SWIPed to customers or does everything track back to the cloud provider?
- How is DoS traffic filtered, or are we going to get billed for it?
- What happens to our data when we scale back usage or cancel our service?
I could go on and on.
Many of these issues resolve to how much can you trust your cloud provider? Trust takes a long time to build. Most of IT is fairly critical corporate data and infrastructure, so it may be some time before trust is built up enough to move much of this sort of data to cloud deployments. Trust can also evaporate almost instantly once it is lost, so all it will take is a single high-profile cloud-related failure to put all cloud business at risk.
Now, it may seem that I'm somehow anti-cloud. Nothing could be farther from the truth. It is a sensible method for provisioning computing resources on demand and fulfills a very real market niche. I just do not believe that it is the answer to every IT problem, nor is it the sole future of IT -- only small portion of it. Cloud computing will expand the market. I can envision a very near future where companies use a hybrid of traditional dedicated data center resources with cloud deployments to extend, replicate or expand as demand warrants. The cloud is indeed a new paradigm, but it lacks the underlying "shift" that alters the entire industry around it. The pundits should sheath their hyperbole and focus on what cloud computing can do for people rather than what it will do to the marketplace.
very good post
AM3 Technologies has been awarded its largest contract to date. AM3 will be providing a Fortune 100 client (to be named later) an internal cloud that will provide them millions of dollars of revenue-generating services while saving them over $600k in hardware costs. A great way to finish what can only be described as a slow year.



While there is much debate on the IT side as to whether Cloud computing is revolutionary, evolutionary or “more of the same” with a snazzy marketing label, in the legal context, Cloud computing does have a potential significant impact on legal risk. Part three of our ongoing Cloud legal series explores the relationships in the Cloud, and the potential legal implications and impacts suggested by them (if you would like, for context, you can read Part One [the Basics and Framing the Issues] and Part Two[Privacy and the Cloud] of the series. In the legal world, some take the position that Cloud is no different than “outsourcing”. Unfortunately, making that comparison reveals a misunderstanding of the Cloud and its implications. It is sort of like saying that running is no different than running shoes. Like “running,” outsourcing is a general term describing an activity. In this case the activity involves organizations offloading certain business processes to third parties. Cloud computing (like “running shoes”) is a “new” method for leveraging existing technologies (and technological improvements that have occurred in the past 20 years) that can be used by outsourcers to provide their services more effectively and cheaply (as running shoes represents a technology that can be used to achieve the activity of running more efficiently). In other words, one can outsource utilizing a Cloud architecture provided by a third party, or by using a more traditional dedicated third party hosted technology solution. Both are different technologies or methods for achieving the same activity: outsourcing of business processes. For lawyers analyzing outsourcing to the Cloud the question is whether the technology, operational aspects and various relationships of a given Cloud transaction create new legal issues or exacerbate known legal problems. To illuminate this question, this post explores the relationships that exist between organizations outsourcing in the Cloud (“Cloud Users”) and those providing services in the Cloud. Coincidentally (or maybe not so much) understanding these relationships is crucial for attorneys that need to address legal compliance risk and draft contracts to protect clients entering into the Cloud. Dark Opaque Storm Clouds or White Fluffy Transparent Clouds? When it comes to relationships is the Cloud more like a dark storm cloud that one cannot peer into, or is it more like a fluffy, light and transparent cloud that allows one to see what is happening within? Unfortunately, the current forecast in some areas is for dark Clouds that make it difficult for Cloud Users to understand exactly with whom they are dealing and who is storing and processing their data. Transparency may be elusive and the very nature of the Cloud computing architecture may be the cause of this. In other words, even if an attorney wants to discover who is actually processing their data, the nature of the Cloud may make it very difficult for Cloud providers to provide definitive information on that point. This is in stark contrast to most traditional outsourcing relationships involving a single vendor and dedicated computing resources or software. Moreover, even if all the Cloud players are known, it may be difficult for Cloud Users to manage and shift responsibility to a party that it has no direct relationship with, and no direct contractual legal rights or remedies. In a traditional dedicated outsourcing model (e.g. web or data hosting, ASP model, etc.) organizations often deal with a single service provider that provides computing resources. That service provider typically would own or control the computing resources that support the outsourcing transaction. Oftentimes those computing resources would be dedicated solely to a particular client. To clarify and solidify this one-to-one relationship the outsourcing contract might have a clause prohibiting the use of sub-contractors to provide the services. In terms of legal risk, the organization utilizing the service provider would be able to conduct its due diligence (e.g. privacy compliance, “reasonable security,” etc.) on a single entity. Moreover, the organization would be able to negotiate a contract shifting risk between it and the service provider knowing that the service provider in essence directly “controlled” the risk by virtue of its control of the computing environment. Even in cases where a service provider uses a sub-contractor, in the typical case, the organization could fairly easily discover the identity of that party and perform its due diligence. More rare are instances of generic unidentified sub-contractors, or sub-contractors utilizing sub-sub-contractors. Relationships in the Cloud: Who is processing my data? It can be very different in the Cloud (click here to view one version of the Cloud landscape). This is not to say that Cloud relationships are not/cannot involve one-to-one relationships like traditional outsourcing. They can. At the base of the Cloud stack, it would not be unusual for IaSS providers to have direct relationships with some of their end-clients. For example, if an organization contracts directly with Amazon Web Services, a Cloud Platform (Infrastructure as a service – IaaS), to allow the organization to build its computing resources in Amazon’s Cloud, it would have a degree of confidence that it was dealing with the party that directly controlled and was responsible for maintaining the Cloud Platform. However, there are service-oriented organizations (integrators) that will actually help to build computing resources on a particular Cloud Platform. In that case a client would not necessarily have a direct relationship with the Cloud Platform, and yet would be subject to the limitations and problems of the Cloud Platform. The problem is more prevalent as one moves up the Cloud stack. Companies that offer software as a service (SaaS) may have built their application within a particular Cloud Platform (examples can be found here, here, here, here and here). The Cloud User again would typically be dealing solely with the SaaS provider despite the fact that the Cloud User’s data is actually being stored and processed (in part or whole) by the Cloud Platform (at the PaaS or IaaS layer). In fact, it is possible that a particular Saas may actually serve its application on multiple Cloud Platforms. Those Cloud Platforms again are one step removed from the Cloud User and each may pose different legal risks. For example one Cloud Platform may have servers across the globe thereby potentially exposing a Cloud User to multiple privacy laws in various jurisdictions, while another may be purely domestic (thereby limiting the jurisdictions to which it the Cloud User may be exposed). In fact, there may be significant economic incentives for SaaS providers to switch between Cloud Platforms that are more efficient or less expensive (thereby improving the SaaS profit margin). To make the situation more complex, it is also possible for a particular SaaS to use more than one Cloud Platform for an individual Cloud User client. In these cases, data processing might alternate between multiple Cloud Platforms (either because it provides for better efficiencies or perhaps a particular Cloud Platform provides the SaaS with a better price/profit margin). Again, in the legal context this can be problematic. If a SaaS decides to move processing to a Cloud Platform with weak security for example, it could significantly increase the liability risk of a Cloud User if the platform suffers a security breach. It would be very difficult to perform adequate “due diligence” where data is constantly shifting between multiple Cloud Platforms. Cloud Service Aggregators Unfortunately, this may be just the tip of the iceberg. In the foregoing example the Cloud User was at least dealing with a single Cloud SaaS provider on the front end. This would not be the case when dealing with Cloud service aggregators. Aggregators essentially bundle (and possibly integrate) multiple SaaS services into a “single” service (examples of aggregation models are here and here). For example, one could envision an aggregator bundling multiple Cloud SaaS offerings for use by travel agents (you can search for examples of SaaS providers serving industry verticals here). The bundle might include a customer relationship management application, a booking and reservations application, a credit card processing application, a billing platform, an international time zone translator application and an electronic signature/e-commerce application. To the Cloud User this bundle would appear to be a single seamless consolidated application. The reality is that each of the applications may be operated or created by separate SaaS providers. It is also possible that each of these SaaS providers might serve their application on a different Cloud Platform. There may be variations in each application in terms of reliability and security. Moreover, as discussed above each SaaS provider might be using multiple Cloud Platform’s and that use may not remain static (e.g. it’s a moving target). While aggregation models appear to be just gaining traction they could become more prominent going forward, and legal and security/privacy impacts of these models need to be carefully scrutinized. The Legal Conundrum The scenario described above poses significant legal challenges for Cloud Users’ transactional and compliance counsel (as well as security and privacy professionals). Due diligence and contracting are potentially much more difficult when the Cloud is involved. In some cases the Cloud User may be two or three levels removed from the organizations actually processing and storing the Cloud User’s data. For example, without a direct relationship with the lowest level Cloud Providers, organizations will not be able to directly analyze compliance issues around privacy and security compliance and reasonableness. As such Cloud Users will have to somehow confirm that the direct party they are dealing with engaged in proper due diligence. It almost becomes a meta analysis: due diligence might involve a Cloud User analyzing whether a Cloud Provider’s due diligence process itself was adequate. This would likely include receiving any reports or other types of analysis performed by the higher and lower level Cloud Providers. As discussed below it should also include a review of the contracts the higher layer Cloud Provider has with the level below it. Of course it more than two levels are involved or there are multiple service providers or Cloud Platforms involved on a particular level, one must have confidence that each of the players also performed adequate due diligence on the providers it utilizes, and so on. So in essence, the Cloud User would be seeking to somehow validate that the Cloud Provider performed adequate due diligence of the due diligence process of the Cloud providers in the level immediately below it. In essence, the Cloud User would want to see a “Chain of Due Diligence.” This requires that the providers on each level of the chain think ahead and anticipate the needs of the Cloud provider or Cloud User in the layer immediately above it. Another example to illustrate the point involves incident response contract terms. What happens when the Cloud transaction involves multiple layers and the lower layer suffers a data security breach exposing the PII of the Cloud User’s data? What happens when the Cloud User needs to implement a litigation hold to preserve data where the data resides in the lowest layer of the Cloud? In a typical direct outsourcing relationship, the outsourcer and its client would build processes in to address these issues and the contract would provide for particular rights and remedies. While similar contractual rights and obligations may be built into a Cloud transaction, it is not clear how useful they would be when multiple layers are involved. For example, if a SaaS built on a Cloud Platform has itself failed to obtain certain rights and abilities to forensically analyze and preserve data processed in the Cloud Platform, the Cloud User may not be able to adequately build defenses in a security breach context or implement an effective litigation hold (regardless of what the contract between the SaaS and Cloud User provides). A final example: data retention and destruction policies. What if the SaaS provider is working on a Cloud Platform that creates residual copies of data that the Cloud User has a legal obligation to delete? What if the SaaS provider works with a Cloud Platform that does not have the technology or capability to properly wipe data? Even if the Cloud Platform has these capabilities, what if the SaaS provider has not negotiated for the right to obtain these services? Again, to make this work it is incumbent on the SaaS provider to anticipate the end Cloud User’s needs and to only work with Cloud Platforms (or other Cloud providers) that have the capability (and willingness) to meet those needs. Conclusion We are very much at the start of the Cloud computing phenomenon, and luckily we have an opportunity to proactive identify and attack these issues now. However, it appears that Cloud is gaining significant momentum and time is running short to address these matters. While the ultimate “solutions” will take time to develop, legal counsel (and the legal community as a whole) should begin developing strategies and approaches for handling Cloud transactions. A key factor (and crucial first step) in addressing Cloud legal risk for a particular transaction is understanding the relationships of the Cloud. Legal counsel (with a huge assist from IT and security) should consider taking steps to achieve this understanding and limit risk, including without limitation: Legal Implications of Cloud Computing -- Part Three (Relationships in the Cloud)
Mike Manos, Senior Vice President of Technical Services at Digital Realty Trust, believes that the coming decade will see more changes in data centres than has occurred in the past 30-40 years combined. Mike predicts that we are entering a period of significant development in the way data centres are designed, built, operated and utilised.
- A Decade of Advancement for Data Centre Facilities
While Moore's Law has influenced enormous advancements in IT technologies like servers over the past ten years, there has not been equivalent innovation on the facility side for data centres. If in the year 2000 someone jumped into a time machine and travelled forward in time to today, data centre facilities would look very similar. That is because most companies continue to design and build their data centres in a very parochial way – designing them to a set of outdated technical specifications prescribed by a decades-old tier system, or simply designing them from scratch on a whiteboard using hand-me-down principles from their last major data centre project years and years before. Someone jumping into a time machine from 1990 or 1980 or even 1970 would have a similar sense of déjà vu. Data centre facilities would seem eerily familiar, frozen in time, still wearing bellbottoms and sporting muttonchops as if 30+ years had not passed.
But that is going to change in a dramatic way over the next few years, so much so that I predict data centre facilities will evolve more in the next decade than they have over the past four decades. We are entering into a period of fundamental change for data centres, in terms of the specifications that are used for data centre plans, in terms of the kinds of technologies that are used in the facilities, and in terms of how companies conceive and execute their data centre strategy. We've seen some important movement in each of those areas over the past couple of years by enterprises that are ahead of the curve, and those changes will rapidly become industry-wide during this decade.
- The Decline of Monolithic, Tiered Datacentres
One of the biggest changes that will happen is a mass-extinction of the kind of monolithic data centres designed to a single tier that have been at the top of the food chain for the past couple of decades. Those will go the way of the dinosaur because of their inefficiency in terms of capital usage, their high energy consumption, and their obsolete technical specifications. What will take their place is a more nimble species of data centres based on the principle of modularisation. Rather than being designed and built in a parochial manner as highly complex one-of-a-kind buildings, data centres will be built with an increasing level of standardisation that will drive tremendous efficiencies in terms of capital investment, reliability, speed of completion, ease of maintenance, flexibility and energy usage. Over the coming decade, data centres will become modularised to such a degree that they will be produced like an assembly line product: like a constant stream of shiny new Mondeo coming out of a Ford factory as opposed to one-of-a-kind custom cars slowly built from scratch and at great expense.
- The Real Impact of Cloud Computing
Another big change in the industry over the coming decade will be driven by cloud infrastructure. There is a lot of talk about cloud computing, but much of the commentary I have read has misconstrued the true impact of cloud computing on data centres. Corporate date centres will not go away. That kind of prediction grabs headlines because it is provocative, but it's inaccurate. Cloud computing will have a significant impact on industry, but in a different way. Over the next few years, large providers will build cloud computing infrastructure across the globe to provide base-level computing services that are more efficiently supported by cloud computing infrastructure. There will also be the emergence of private clouds for similar purposes. These changes will make certain computing functions like data storage and backup a commodity, allowing companies to focus their own data centres and IT teams on more strategic initiatives. The data centre of tomorrow will be less about basic functions that every company must have. Instead they will focus on computing that differentiates companies in ways that give them market advantages and drive growth. In this way, they will become even more important as strategic assets. For both the corporate data centres and cloud computing data centres, modularisation will be the norm rather than exception because of the efficiencies that a modular approach brings to capital expenditure and flexibility.
- Power Capping and the Global Integration of Data Centre Facilities
Another key change over the next decade will be driven by power capping. Enterprises are going to be able to integrate their data centre infrastructure in a way that enables them to optimise their energy consumption not just on a facility basis, but on a global basis across their entire portfolio of IT assets. From a facilities perspective, a tools perspective, and an applications perspective, data centres will be integrated in a way that allows enterprises to optimise their energy usage and energy costs. Enterprises will be able to move their computing activities from facility to facility around the world in a dynamic way, shifting applications geographically to optimise energy consumption, and unshackling them from specific facilities in a way that has never before been possible. This will be another key driver for modularisation because standardised data centres will be best suited to support this kind of dynamic approach to IT infrastructure management.
- A Game of Cat and Mouse with Government Regulation
My last prediction for the coming decade is related to the impact of governmental regulation and taxation on the industry. For the past 30-40 years, data centres have largely been a back office asset that has escaped the scrutiny of government regulation, but that will change. Because of their increasing prominence, their energy intensiveness, and their distributed nature across national borders, data centres will be a target for governmental scrutiny over the next decade. This will lead to regulation and taxation intended to address issues such as privacy and carbon emissions. I predict that this decade will see the beginning of a game of cat and mouse between government bodies and the data centre industry as regulation and taxation and innovation go head to head. The days of data centres operating in a bubble insulated from regulation and taxation are numbered, and my advice to people responsible for their corporate data centres is this: Do not underestimate the impact that government regulation and taxation will have on the infrastructure investments that you will make and the ones you have already made.
