Enterprises have been telling me for years that they want to move their IT infrastructure to an "as-a-service" model. Sometimes their goal has been to create "mash-able" applications that can run through browsers to reduce desktop support costs. Recently they’ve wanted to add tablets and smartphones to their roster of data devices. Then there’s cloud computing and virtualization. Lots of missions, and yet the average data center still looks pretty much the same.
As a group they knew, but the knowledge was distributed among them rather than concentrated--that is, a specific and logical consensus plan emerged from their individual responses, yet only 42 of 277 enterprises had actually implemented all the pieces of this consensus model.
The plan, in a nutshell, is to visualize data center modernization as layers of "as-a-service" infrastructure.
First Layer
At the bottom of their layer stack was "data-as-a-service". Enterprises told me that virtualization and cloud computing in particular demand a database architecture that can distribute data elements to various storage resources but offer access to them as a single virtual database. The architecture has to support the popular "ACID" acronym of database harmony: Atomicity, Consistency, Isolation, and Durability.
Two trends were emerging here. One was the "No-SQL" drive to replace RDBMS (relational database management system) with some faster architecture; and enterprises were particularly interested in the tree/hierarchical structures and Google's BigTable, an open-source version of which is offered in Hadoop cloud software. These appear to be great for transaction processing, but enterprises are still wrestling with how to integrate them with their reporting and business intelligence needs.
The other trend was the use of database appliances that would essentially offer higher layers with virtual access to data while disguising the underlying implementation. Oracle is the premier provider of appliances of this sort, but surprisingly, enterprises indicated that Oracle wasn't pushing appliances for this data-layer mission, and respondents were thus a bit confused about how to use this type of appliance to greatest advantage.
Second Layer
The second layer of the model is the application services layer, the place where servers actually run the applications. Increasingly, this is seen as consisting of a layer of application servers as the bottom sublayer, then a layer of web servers. This is where virtualization and cloud resource assignment are critical, and while it’s also the place where most software attention and competition is focused, enterprises say they understand the issues within this layer the best of all. Here, the problem is what could be called the "boundary functions", meaning the way that applications link to the database layer and then upward into the top or "Enterprise WAN" layer, toward the client devices.
The direction most enterprises want to take is to provide a front-end to applications in the form of a third layer--the "Web Server" layer--that would provide the GUI for their business applications. By introducing this layer, they introduce the flexibility needed to support those new types of devices, to mash up applications into worker-specific displays, but also to insulate the real applications from minor changes in how data is obtained and used.
The challenge here is that this sort of application split--into a presentation and functional sublayer--greatly expands the inter-process communication associated with a given transaction or application. Data centers have always had to network servers to storage, but adding a need to network app servers to web servers raises network demand and increases the risk that complex data center switching architectures of many switch layers will introduce large and variable delays. Storage networks can be isolated from the rest of the data center if that remainder has simple network needs, but adding application/web interconnection to the mix forces users to consider consolidating storage networks and the rest of the data center into one network, and that network had better be flatter. This is what’s generating all the flap over "flattening" the data center LAN.
The boundary between the application/web part of the data center and the client is the boundary between the data center network and the enterprise WAN. The problem here in both virtualization and cloud computing is that the server resource that will be assigned to an application isn’t static, so the user connection to the application has to support more dynamic assignment of addresses. Enterprises envision two approaches, one based on DNS or directory tools and the other based on "elastic" IP addresses and NAT (network address translation).
Where application-to-server assignment is fairly long-term, you can always use a directory like the DNS to convert an application URL to an address because you won’t be doing too many updates. Where the assignment is more dynamic, the Amazon approach of using an "interior address space" based on NAT and then translating a static address to a dynamic internal address seems best. The latter process is similar to that used for server load balancing, and it has the advantage of at least potentially offering a bridge between public and private components of a hybrid cloud.
What seems to be happening now is that enterprises are focusing on data center modernization not as a holistic task but as a series of steps, and in many cases they're neglecting the fact that there's an interdependent relationship among the parts. The reason for the focus in the first place is that many are getting into their modernization projects because of vendor sales pressure, and most vendors are concentrating just on the one specific thing that they’re trying to sell. That's too bad, because the enterprises with the broadest vision of modernization report making more progress and securing more benefits for their efforts.
