When strategies are formed it quickly becomes obvious that cloud computing is more about balance than anything else.

At a time when you’d think cloud computing would be the primary “go to” strategy for managing scale and rapid growth multiple well-known and demanding organizations are building their own data centers instead.

With all the hype around cloud being faster, cheaper, and more efficient these folks must be crazy, right?

Not at all. In fact, these moves illustrate the growing friction between the economy of scale offered by cloud computing and the control and flexibility that is part and parcel of owning one’s own data center.

In April Twitter announced plans to build a data center of its own. On Wednesday it provided additional details on the Twitter Engineering blog.

“Later this year, Twitter is moving our technical operations infrastructure into a new, custom-built data center in the Salt Lake City area,” wrote Twitter’s Jean-Paul Cozzatti, who said having dedicated data centers will provide more capacity to accommodate growth of 300,000 new users per day. “Keeping pace with these users and their Twitter activity presents some unique and complex engineering challenges. Importantly, having our own data center will give us the flexibility to more quickly make adjustments as our infrastructure needs change.”

-- Data Center Knowledge, “Twitter Picks Utah for New Data Center”

Twitter isn’t the only Web 2.0 savvy organization moving to their own data center. Facebook earlier this year announced it, too, was also investing in building out its own data center.

BUT CLOUD AUTO-SCALES and STUFF!

It’s not all about scalability. I know that sounds nearly heretical, but it’s not. And it’s not a new mantra, either. Scalability is certainly a factor in why one would choose cloud computing over a localized deployment, but also important are control and flexibility. 

Another consideration is the ability to customize your data center infrastructure to provide more granular control of operations. “That control gives us a ton of flexibility, and we can build new things without having to wait for our partner,” said Heiliger [Jonathan Heiliger, Facebook’s VP of Technical Operations]

-- Data Center Knowledge, “Data Centers: For When The Cloud is Not Enough”

If I’ve said it once I’ve said it a thousand times: control is a huge factor in the decision making process and something that isn’t effectively offered by today’s public cloud computing offerings. Remember the Information week analytics Cloud computing survey in 2009?

Even though security remains concern number one, control and configurability are on the top of the list, as well. The issue of control has almost always gone hand in hand with cloud adoption inhibitors, but it always takes a back seat to the more glamorous and scary “security” issue. These are not minor stumbling blocks in many cases, and the inability to rapidly adapt an infrastructure to meet growth and scale and make architectural changes, if necessary, are paramount to success. If cloud computing cannot provide the agility necessary to meet these challenges then it is logical to assume that organizations will either (a) stay in the local data center or (b) move to a local data center from the cloud when it becomes obvious the environment is inhibiting forward momentum.

Current adoption patterns indicate that this is not an anomaly, but will instead likely become the norm for organizations. Applications that are initially deployed “in the cloud” will, upon becoming a critical business application or growing beyond the meager means of control and flexibility offered by the cloud, will migrate to the data center, where control and agility are provided by the simple fact that the organization can change at will any piece of the infrastructure – from its physical implementation to its logical organization – at will. This is evident in the percentage of organizations using cloud for “dev and test” but not for production. Clearly the economy of scale and rapidity of deployment makes the cloud a perfect environment for development and testing but not necessarily production.

ECONOMY of SCALE MAY be INHIBITING SCALE

The irony is that the economy of scale offered by cloud may well be biting cloud in the proverbial derrière as it becomes the inhibitor to effective scale by limiting or making extremely difficult the architectural changes necessary for an application to scale in a cloud environment.

At some point scalability can become not about the application but about its infrastructure and the way in which that infrastructure interacts. It can become about the network and its components and how applications end up interacting with and through that infrastructure. In a cloud computing environment it is rarely the case that a customer can impact that infrastructure and, when it can, it is then limited by other factors such as underlying virtualization technology and the physical server infrastructure on which the application is ultimately deployed. If the answer to a scalability obstacle is more bandwidth and higher throughput, you can’t really add another NIC to a server in the cloud. That’s not your call. But it is if you’re in the data center, and it is virtualization – not cloud - that ultimately provides the agility to make such a change and rapidly propagate that change across the application deployment.

It isn’t always about costs. Well, okay, it is about cost but in IT it’s about cost as it relates to performance, or flexibility, or other operational functionality required to successfully meet data center and business goals. When spending less on infrastructure results in higher operational costs, the organization really hasn’t saved money at all. Savvy CIO and CTOs understand that it’s not a battle, but a balancing act. It’s not about achieving the highest economy of scale, but the best economy of scale given the specific operational and business needs.

If we look at cloud in terms of what it does offer instead of what it doesn’t, we may discover more useful architectures than were previously thought to exist.

I have a fairly large, extended family. While I was growing up we gathered at our grandparent’s home during the holidays for, of course, a meal. Grandma would put extra chairs around the table but because she had five children (and spouses) there really wasn’t any room for us grandchildren. So we got to sit … at the little kid’s table. Eventually we weren’t “little kids” any more and we all looked forward to the day we could sit at the “big” table with the adults.

Now grandma was a stickler for time, and dinner was served at exactly twelve noon. Not 12:01, not 11:59. 12:00. Exactly. If you weren’t there, that was just too bad. So it inevitably it was the case that someone wasn’t on time and it was then that, in age-descending pecking order*, some of the “kids” got to sit at the “big” table. Until the Johnny-come-lately adults showed up, at which point we were promptly banished back to the kids table.

This “you can sit at the big-table unless a grown up needs your place” strategy is one that translates well to a hybrid cloud computing strategy.

THE LITTLE KIDS’ TABLE = THE CLOUD

There are myriad surveys out there regarding the inhibitors to cloud adoption. At the top is almost always security and control. CIOs are quick to indicate they do, in fact, have interest in the cloud and its purported operational benefits, but they aren’t necessarily willing to risk the security and availability of business-critical applications to get them.

As has been previously mentioned in Why IT Needs to Take Control of Public Cloud Computing, it may be that IT needs to adopt the view that the data center is the “big” table at which business-critical applications are deployed and the cloud, as the “little kids’ table” is where all non-critical application end up when the “big table” is full. A kind of cloud bursting, if you will, that assumes business-critical applications have priority over local data center compute resources. Non-critical applications may be initially deployed locally but if business-critical applications need additional compute resources then non-critical workloads must give up their local resources and move to the cloud.

This strategy treats cloud as it is today, as compute on-demand and little more. It assumes, moreover, that the application needs very little “care and feeding” in terms of its supporting application and application delivery infrastructure. A little non-specialized load balancing for scale and a fat pipe might be all this application really needs. That makes it perfect for deployment in an environment that caters to providing cheap “utility” compute resources and little else because it can be migrated – perhaps even while live – to an off-premise cloud environment without negatively impacting the business.

That would not be true of a business-critical application for which there are strictly defined SLAs or compliance-related polices, many of which are implemented via complex integration with other components, systems, and applications internal to the data center. Migrating a business-critical “application” is a lot more complicated and time-consuming than a non-business critical, non-integrated application. That’s because the former requires either (a) migration of all related components and supporting infrastructure or (b) a secure, optimized tunnel to the off-premise cloud computing environment that enables the continued use of integrated application and network components.

CLOUD (IM)MATURITY DRIVING FACTOR

The immaturity of cloud computing environments with regards to the availability of enterprise-class infrastructure services continues to be a root cause of cloud “reluctance.” Without the ability to deploy a critical application in an environment similar to that of the local data center, CIOs are going to be understandably cautious. But for applications that don’t need such a complex network of support infrastructure cloud computing is well-suited for deployment and doing so is certainly – at least from a CAPEX and long-term OPEX point of view – the most appealing option available.

Before cloud can mature, before we reach the “network standardization and services-based infrastructure” we need the standards upon which standardization will be based. Interestingly enough, that doesn’t necessarily mean industry standards. The speed at which various standards organizations are moving today makes it highly probable that organizations that are moving more quickly will develop their own set of standardization that will eventually form the basis for industry standards. Some might argue, in fact, that this is the way it should happen, as organizations are the ones that use and exercise the Infrastructure 2.0 APIs and frameworks currently available across the infrastructure spectrum to integrate and manage infrastructure components in their own data centers.

Without those standards and the resulting infrastructure services, in order for organizations to reap the benefits of cloud computing we should probably stop looking at cloud with a “glass is half-empty” view and take a “glass is half-full” perspective, instead. Don’t look at cloud in terms of what it doesn’t offer, but instead what it does offer: inexpensive, easily and rapidly provisioned compute resources. Compute resources that can serve as overflow for non-critical applications when the really important applications need more compute power.

* As the oldest grandchild I was good with this order of operations, of course.

Reflecting on last week’s Interop in Las Vegas I found myself thinking as much about what wasn’t there as what was.  While I believe the official reports that claim attendance gains over last year, the show just felt small.  More importantly, it felt uninspired.  Here we are in the midst of a major transformation in the way we build computing systems, led almost entirely by VMware, Amazon, Microsoft, Google – and without major influence from the networking industry. 

The network is behind, way behind, when it comes to delivering the strategic benefits of cloud computing in terms of dynamic, flexible movement of workloads among computing centers.  And from what I saw at Interop, its about to get worse –

Read more...

As I’ve mentioned, Cisco’s CTO predicted 1 trillion net connected devices by 2013 and I don’t think Padma was counting virtual machines.  With the rise of the three horsemen (netbooks, virtualization and cloud computing) it seems obvious that today’s enterprise networks are in need of a fundamental overhaul, starting with the automation of the tired, manually managed IPAM, DNS and DHCP infrastructure.

Read more...

Don't let the moniker of Infrastructure 2.0 fool you. Applications are an integral part of the new network equation.

jetNEXUS has a nice post entitled, “What does Application acceleration mean?” Aside from completely ignoring protocol acceleration and optimization (especially good for improving performance of those chatty TCP and HTTP-based applications) the author makes a point that should have been obvious but isn’t – compression is actually good for image heavy sites.

It’s true that images are technically already compressed according to their respective formats, so compression doesn’t actually do anything to the images. But a combination of browser rendering rules and client-side caching make the impact of compressing the base page significant on the overall performance of an image-heavy site.

Firstly, the images can't be displayed until the base page arrives at the client, so it follows that the quicker you can deliver the base page, the faster you can request the objects and the quicker the page can load.

Secondly, web sites and applications generally have a consistent look and feel. As such the effect of client side caching is significant. This means that most of the data that will be sent is compressible as most of the images are already saved at the client side.

This is definitely one of those insights that once it’s pointed out makes perfect sense, but until then remains an elusive concept that many of us may have missed. Understanding the way in which the client interprets the data, the HTML and all its components, means the ability to better apply application delivery policies such as those used for acceleration and optimization to the application exchange. Combined with the recognition that compression isn’t always a boon for application performance – its benefits and performance impact depend in part on the speed of the network over which clients are communicating – the application delivery process can be optimized to apply the right acceleration policies at the right time on the right data.

It may be necessary, however, for the application to take a more active role in deciding what acceleration policies should or should not be used, especially in the case where one of the primary factors is regarding the content of the response being returned. While an intermediary capable of inspecting the application data on ingress or egress is certainly able to intercept the data and inspect it to determine the number of images in the content, it would be more efficient for the application to participate in the process instead as it can provide that information without needing to inspect the data on every request.

This is yet another example of why it’s important to understand the application from end-to-end. In this case it’s not so much a matter of having components that are application-aware, but rather it’s important for those responsible for putting application delivery policies into place that need to understand the application end-to-end and be aware of its behavior at both endpoints: the client and the application. A dynamic infrastructure integrates the unique context available from application, the network, and the client to make more intelligent decisions regarding the delivery of the application. The application must be an active participant in this process in order to complete the delivery trifecta that will optimize and accelerate application delivery to users based on the context in which the request was made.

The application instance, which is almost certainly “hidden” behind an application delivery controller or load balancer and other network infrastructure components (firewalls) cannot “see” the speed of the network over which the user is requesting data, but the intermediary can. The application knows how many images are on a given page without requiring additional inspection and parsing. If the application can communicate that information to the application delivery controller, where the application acceleration policies will be applied, that data can be used as a factor in the optimization equation.

That’s one of the precepts of Infrastructure 2.0, that the endpoints collaborate just as the infrastructure collaborates to provide the information necessary to make the best decisions for delivery (security, acceleration, optimization, distribution) possible. It’s a matter of determining (1) where the policy should be applied, (2) what information is required to make the best-fit decision at the time the request was made, and (3) what component is the best source of each variable. In this case, the application is the best source of information regarding the make-up of the application while the application delivery component is the best source of information regarding the network. Combining the data into a single equation and deciding what policy to apply to each response will yield the greatest benefit for both the client and the organization in terms of efficient use of resources.