The concept of a server needs to go the way of the dodo

One of the reasons I enjoy Twitter is that quite frequently – if you’re following the right people – you’ll see a tweet that is absolutely profound despite its simplicity and the constraints placed upon the author.

Recently we were having a mini-discussion on Twitter regarding the definition of availability that elicited just such a golden nugget from botchagalupe: “Apps designed for a cloud should remove the ‘server’ concept.”

First, I really like the use of the article “a” in reference to cloud as it speaks to all models of cloud: private, public, external, internal, and hybrid. Second, the simplicity of such a statement obscures just how profound the concept is and the long-term effects of cloud and virtualization on how we view architecture and data center design.

THINK RESOURCES, NOT SERVERS

Load balancers, a.k.a. application delivery controllers, have long since discarded traditional terminology such as “servers” and used jargon more germane to the industry like pool, farm, node, and cluster. Such terminology is, it turns out, perfectly suited to cloud and virtualized environments because it reflects the elimination of tight coupling between an application or service and a physical server.

Rather than referring to a server, we ought to be referring to a resource or a node. I’m partial to node, but that’s because I’m coming at this from an application delivery perspective. Resource, in terms of cloud computing, might be more palatable and accurate to purists but then again we aren’t quite at the point where we’re actually provisioning compute resources. Regardless, moving away from using the term “server” has the effect of removing the emphasis off the physical – or even virtual – server and onto the application or service being delivered. It also better represents the environment as applications really are more akin to nodes in a distributed system in a cloud.

In a cloud environment, of course, the server is irrelevant; it’s almost assumed in much the same way as organizations have long considered the network to just “be there” when it’s needed. That doesn’t mean that servers aren’t important; they are. After all, without them, where would you deploy applications and what would supply the actual compute resources necessary to execute them – and their virtual containers. It’s just that they aren’t, in terms of application delivery, really all that much of a factor. That’s not a bad thing, as a tightly coupled architecture can be detrimental to designing and implementing a dynamic on-demand infrastructure where applications – not servers – are the focus of attention.

This is a good thing for application and context-aware infrastructure but bad for infrastructure that is still tied to the notion of a server and, as is the wont of network-oriented devices, tied to IP addresses. And that’s really the biggest danger in a server-oriented data center: the tendency to tie application to server to IP address. This is dangerous because it inhibits the ability to move an application or take advantage of idle resources when increases in capacity demands must be addressed. It is difficult – and operationally expensive – to decouple an application from a server and an associated IP address in order to move it or clone it on another server and rebind it to a completely different IP address. Server virtualization solves part of this problem by abstracting the application environment from the physical hardware, and network server virtualization solves the rest of the problem by abstracting the notion of pools of resources from the virtual service.

The missing piece in the puzzle is the ability to decouple the application from that associated IP address which, in an IP-based world, is both harder and easier than it sounds. There absolutely must be an IP address, but it can’t be static or tied permanently to an application or service.

INFRASTRUCTURE 2.0 to the RESCUE

A dynamic infrastructure is able to remain fluid; its understanding of a pool is that it comprises nodes, and those nodes are specifically applications regardless of whether they reside on virtual machines or on physical platforms. A dynamic infrastructure is able to modify its understanding of a pool of applications or resources as those nodes change status: from available to unavailable, and vice-versa. The make-up of a “pool” may change from minute to minute or hour to hour or day to day, but the abstraction offered by the application delivery controller assures customers and users that of availability of their applications because they are abstracted from the implementation, in a very SOA-like fashion.

Along with application resources moving from one server to another comes, undoubtedly, a change in IP address as well. This is because there are no guarantees that a new application resource will even be on the same sub-network let alone network – an increasingly possible scenario when you consider cloud bursting, cloud balancing, and other hybrid architectures. What is necessary is the ability to instrument either the application or the hypervisor – or both – with instructions that communicate its current IP address to the infrastructure for which it may be relevant. Application and network security, secure remote access, application acceleration and load balancing infrastructure all need to know the IP address because, well, under the covers every network is still IP-based. The ability to integrate and collaborate with those applications and hypervisors and orchestration systems that make a cloud environment actually work is what makes Infrastructure 2.0 a key component to a successful cloud-based initiative. Without the ability to communicate changes and inevitably for the infrastructure to take decisive action based on those changes none of the “magic” of cloud and dynamic architectures can actually happen.

But notice that there are no servers in this equation. There is an application, there is a hypervisor (platform), and an IP address. The server is required, of course, but only in the sense that it’s required to provide a physical location in “meat space” on which the application can actually execute. It’s a resource provider, and nothing more. The infrastructure – network and application – does not need to even acknowledge its existence because it must be irrelevant if emerging data center models are to be as fluid as possible.

In fact, if we’re ever to get to the point where we cloud computing truly is about on-demand provisioning of raw compute resources across grids instead of on-demand provisioning of applications across servers we are going to have to start removing the notion of a “server” from our vocabulary.

As you should never put off until tomorrow what you can do today, let’s start right now and focus on the application as the central entity to our architectures, not the physical server.

Infoblox Launches ROI Calculator

Conventional wisdom suggests that spreadsheets and manual labor are almost free when it comes to managing IP addresses.  Yet a recent Computerworld Survey of enterprises found IPAM costs rising (on a per IP address basis) as networks grow.

Perhaps conventional wisdom is wrong.  Perhaps manual labor actually costs more than automation when it comes to the network, except it’s hard to track because it is scattered among multiple departments as a kind of invisible line item.  As we mentioned at the Future in Review panel with Cisco, VMware and F5 executives, “today’s networks are [often] run like yesterday’s businesses…”

Read more...

What is the "Smart" data center (SDC) It's a facility that is as much a part of your IT infrastructure as the Operating System (OS) is a part of a production server. In order for your server to boot up, it requires the bios. The bios in combination with the OS allows your server to act as a “System”. Now you might be asking "why is it important for my IT infrastructure to talk to the data center and vice versa?", because it will be the final piece that truly frees us from being slaves to our infrastructure, I’ll explain as you read on.

I believe there are several companies that have seen or are beginning to see this vision of the Smart data center, but as yet haven’t articulated it to the public. Those companies are Cisco, VMware & IBM/Eaton. Cisco recently bought (Richard Zeta a building management system company), in addition to having their Unified Computing System and EnergyWise, they must be thinking along the lines of my “Smart” data center theory. If Cisco isn’t working towards this goal then someone in product management should be fired. VMware has the ESX (vSphere now) platform with vMotion in combination with Dynamic Resource Scheduler (DRS) and Dynamic Power Management (DPM). I believe VMware sees the opportunity for IT platform integration with the facility and then IBM who partnered with Eaton to integrate Tivoli with Foreseer must also be thinking along the same lines.

Why is an SDC, the "smart" thing to plan for?

Consider just a few of the comments made by Lori MacVittie, Jame Urguhart & Greg Ness in previous blogs about Cloud, Intercloud and Cloud Bursting around the following;

-          Distributed application use

-          The ability to provision across clouds

-          Portable environments

-          Etc., etc..

All of the above point to a very fluid and dynamic compute capacity that is no longer limited by physical or logical infrastructure that requires heavy and manual human intervention.

Now, put yourself four years into the future.

It’s summer 2013, I’m on my favorite beach in Hawaii, sun burnt again, but we’re not here in the future to talk about me, this is about you. You’ve successfully implemented a cloud for your organization and you’re reaping all the benefits of having efficient infrastructure, disaster avoidance, improved customer satisfaction and faster time to market among other things. However, with all the aforementioned gains, what are some of the major opportunities you’ve missed? 

Did you consider the differences between your future cloud infrastructure and your current infrastructure and how that might impact your data center build requirements? In today’s data centers there are several factors that continue to weigh down our ability to make real efficiency improvements in environment management and human resource requirements. These factors include vertical application or hardware architectures that require unique components and custom configuration. There’s also the fact that if you don’t want your data center staff to revolt, you can’t plan on shrinking the size of your data center too much or turning the heat up to high. In the 2013 data center, you won’t have these problems, if you’ve planned properly and vendor partners have delivered on the promise of a smart data center.

The SDC in combination with cloud computing equates to a truly manageable environment that is more about capacity, than it is about buildings and hardware architecture. The current environment in a data center requires that your temp be kept at a level that supports human occupation and that your space design is conducive to the comfort of staff and the movement of equipment. Now in the future enlightened environment instead of buying large data centers that you build into over the course of 3-7 years, you can buy a cube, container or some other modular structure that provides just the capacity you need, when you need it, in a very efficient pre-built environment. These compact and efficient building blocks can be placed in the location that best suits your business needs and or that offer the best options for tax, power, and lease. This new data center strategy will drive down your cost of energy, cost of capital improvements and human resource and improve time to market. Now that your data center and your compute infrastructure are just “capacity” and not unique buildings with unique infrastructure designed specifically for each new requirement, you are free to “turn the lights off”, meaning the only human intervention is when a piece(s) of hardware fails and a vendor resource enters the room to replace the faulty unit. We all know that reducing human intervention also reduces risk. The next piece is having your building infrastructure work with your Intelligent Infrastructure Platform (IIP) to ensure the highest possible uptime, and the lowest possible resource costs (and be greener!).

The SDC working with your IIP can now take over for human intervention.  Your BMS, Power Management & IIP now effectively are acting as a system. The data center should be treated as a system (see Data Center Stack), now as a Smart Data Center it can act like one.

The following are some of the potential benefits of the SDCS (Smart Data Center System):

-          Power failure (distribute VMs to another area of the data center or to an alternate location)

-          Demand Response request from your utility (shut down non essential capacity and release the power to the utility for a sizeable rebate check)

-          HVAC failure (reduce current load by shutting down non essential services or moving load to another facility)

-          Water leak (move to another location)

-          Intrusion (move to another location and lock down the environment)

All of the actions listed could potentially be performed without human intervention, saving valuable minutes or hours of response time and limiting the chance of an application failure even happening.

The above are just some of the options that having an SDC might be able to offer you. If you aren’t asking your partners for this capability, then you should start immediately. With this SDC in place, you can provision in locations that offer the best possible cost and performance benefits, without worrying as much about available labor or air temperature averages. Instead, you can focus on the type and quality of service that you need to provide to your customer base all while guaranteeing lower cost of ownership and higher availability. How smart will your future data center be?

So once we have the intercloud, what are we going to do with it?

Some debate is heating up, at least on Twitter, about a variety of cloud-related topics. As James Urquhart pointed out in his “Three debates that will benefit cloud computing” debate is good, because it fuels innovation and drives markets forward.

One of the things that’s frustrating about new technology and concepts is that terminology often confuses the discussion. We periodically still see discussions – and debates – around the definition of cloud computing, after all, so that shouldn’t be surprising at all. Intercloud is another one of those terms that is going to cause some contention because it sounds like a technology, but apparently it’s not. According to the folks who started using it (like James) it’s more akin to the Internet in that it’s a description of what will grow out of interoperability and portability standards once they’re applied to actual implementations. Not to get all Euclidian, but the intercloud is a lot like the set of all clouds connected via standards-based mechanisms. What those mechanisms are may be up for discussion and there are certainly groups devoted to defining those mechanisms but suffice to say that right now the “intercloud” does not exist. It (probably) will but we’re a ways off from that.

But because the intercloud is more of a set of capabilities it really doesn’t do anything. Intercloud is like the Internet is like the network – without someone or something (usually applications) leveraging it, it’s just, well, there. So what could we do with intercloud besides avoiding vendor lock-in?

There are a couple of things that spring to mind; specifically cloud balancing and its closely related cousin, cloud bursting. I say closely related because, despite protests to the contrary, they are based on the same technological concepts and architecture, and work best when leveraging the intercloud. 

CLOUD BURSTING

Cloud bursting has already been talked to death but just as a refresher cloud bursting is the practice of “bursting” into a cloud when capacity has been reached in the corporate cloud/data center. The business case for cloud bursting primarily revolves around seasonal or event-based peaks of traffic that push infrastructure over its capacity but are not consistent enough to justify the cost of investing in additional hardware that would otherwise sit idle.

Cloud bursting takes advantage of global application delivery (load balancing) – or some strategic control point that acts very much the same - as a means to provide nearly immediate redirection of requests to an external cloud in the event that corporate resources are depleted. When a request is received the global load balancer decides which data center (corporate or cloud) should handle the request based on its understanding of capacity. Other variables can of course, be introduced, but basing the decision on where to route a request on other business or technical metrics immediately moves the architecture into one of cloud balancing, not cloud bursting.

So basically there’s a rule that tells the global application delivery solution to direct requests to CLOUD A or CLOUD B when the CORPORATE CLOUD is near or at capacity. It’s a bit more complex than that in implementation, of course, but when distilled down to its basic operations, it really is that simple.

CLOUD BALANCING

Cloud balancing is the routing application requests across applications or workloads that reside in multiple clouds. It assumes that all instances of the application deployed in the various clouds are accessible at all times, which makes it different than cloud bursting as bursting may actually require the deployment and/or launching of the application at a remote cloud. Cloud balancing is not simply load balancing across clouds. The simplification of load balancing down to a dumb process is part of what causes problems with the definition of such concepts. If one assumes that load balancing in general is a rudimentary, dumb process that has no awareness of context and no ability to make intelligent routing decisions then I suppose that the misconception that cloud balancing and cloud bursting have very little in common makes more sense.

But load balancing has not been, for quite some time, dumb. It evolved years ago into what analysts and vendors call “application delivery” and it is capable of quite intelligent, on-demand request routing based on everything from technical to business metrics. Cloud balancing requires that level of intelligence; it requires a context-aware decision maker that can collaborate with the rest of the infrastructure and solutions providing business-level metrics and information in order to make a decision, in real-time, regarding which “cloud” should respond to any given request. Service-level agreements, business metrics, response time, capacity, cost, power, etc... Any one or combination of these variables can provide the basis for deciding how to route a request.

So basically there’s a set of rules that tell the global application delivery solution to direct requests to CLOUD A or CLOUD B or the CORPORATE CLOUD when certain conditions exist. Those conditions are contextual, which is why the notion of context-awareness in application delivery solutions in general is an imperative when architecting a cloud-based (on-demand) infrastructure.

IT’S ALL ABOUT CONTEXT and AGILITY

Both cloud balancing and cloud bursting require intercloud in order to be as seamless as they are intended to be because without the interoperability and portability across clouds, well, things start to break down. Sure, you could do it without standards, i.e. today, but the cost and effort to do so is probably not going to engender a lot of tinkering in this area. The standards need to exist so the actually development and deployment of applications across multiple clouds is not only technically but financially feasible. Standards need to exist not just for deployment, but for management and gathering of data – the data that will be needed in order to utilize clouds based on business and operational metrics. Those operational metrics can – and should – include more than physical conditions on the network and in the data center, but also those describing costs – down to the cost of power at the moment, if possible. Business metrics should include cost thresholds, SLAs, and KPIs specific to the business. All this data is part of what makes up context, and context is what makes things like cloud balancing and cloud bursting valuable architectures. 

Context-awareness is the foundation of a dynamic infrastructure and a dynamic infrastructure requires integration and collaboration in the network and application network infrastructure, hence the focus on standards and interoperability. Only when a solution is capable of interpreting the myriad variables available from layer 2 through layer 7 (and beyond) can it start making decisions that are based on real-time conditions and business parameters rather than just CPU or memory resources or connections or response time. Certainly these are valuable factors in the overall equation, but the goal of IT and solutions implemented and deployed by IT is to provide business value. It stands to reason, then, that business goals and parameters and metrics should be a part of that implementation.

Cloud balancing isn’t as simple as it sounds, simply distributing requests in an orderly fashion across X number of clouds. It is, like modern load balancing in general, an intelligent, policy-driven, interpretive method of routing application requests in a way that adds significant value to the organization. From a process standpoint cloud bursting and cloud balancing are the same thing. Both leverage global application delivery as the real-time decision maker regarding how requests are to be distributed.  One might even go so far as to say that cloud bursting is a subset of cloud balancing as the former is more restrictive about when external cloud resources may be invoked than is the latter. But really, the big differences between the two are the metrics and business use-case in which they are utilized. That’s where the real value of these new-fangled ideas comes from: it affords IT agility which fuels business agility. It isn’t just about the bottom line or speeds and feeds, though these are certainly part of the equation. It’s about providing a framework through which the business and IT can innovate new ways of leveraging technology, and that enables other technology related markets to develop and deliver innovative solutions that provide value to IT and the organizations it supports.