iControl

Red Herring: Hardware versus Services

Lori MacVittie — Wed, 30 Nov 2011 12:18:00 GMT

In a service-focused, platform-based infrastructure offering, the form factor is irrelevant.

One of the most difficult aspects of cloud, virtualization, and the rise of platform-oriented data centers is the separation of services from their implementation. This is SOA applied to infrastructure, and it is for some reason a foreign concept to most operational IT folks – with the sometimes exception of developers. But sometimes even developers are challenged by the notion, especially when it begins to include network hardware.

ARE YOU SERIOUSLY?

The headline read: WAN Optimization Hardware versus WAN Optimization Services. I read no further, because I was struck by the wrongness of the declaration in the first place. I’m certain if I had read the entire piece I would have found it focused on the operational and financial benefits of leveraging WAN optimization as a Service as opposed to deploying hardware (or software a la virtual network appliances) in multiple locations. And while I’ve got a few things to say about that, too, today is not the day for that debate. Today is for focusing on the core premise of the headline: that hardware and services are somehow at odds. Today is for exposing the fallacy of a premise that is part of the larger transformational challenge with which IT organizations are faced as they journey toward IT as a Service and a dynamic data center.

This transformational challenge, often made reference to by cloud and virtualization experts, is one that requires a change in thinking as well as culture. It requires a shift from thinking of solutions as boxes with plugs and ports and viewing them as services with interfaces and APIs. It does not matter one whit whether those services are implemented using hardware or software (or perhaps even a combination of the two, a la a hybrid infrastructure model). What does matter is the interface, the API, the accessibility as Google’s Steve Yegge emphatically put it in his recent from-the-gut-not-meant-to-be-public rant. What matters is that a product is also a platform, because as Yegge so insightfully noted:

A product is useless without a platform, or more precisely and accurately, a platform-less product will always be replaced by an equivalent platform-ized product.

A platform is accessible, it has APIs and interfaces via which developers (consumer, partner, customer) can access the functions and features of the product (services) to integrate, instruct, and automate in a more agile, dynamic architecture.

Which brings us back to the red herring known generally as “hardware versus services.”

HARDWARE is FORM-FACTOR. SERVICE is INTERFACE.

This misstatement implies that hardware is incapable of delivering services. This is simply not true, any more than a statement implying software is capable of delivering services would be true. That’s because intrinsically nothing is actually a service – unless it is enabled to do so. Unless it is, as today’s vernacular is wont to say, a platform.

Delivering X as a service can be achieved via hardware as well as software. One need only look at the varied offerings of load balancing services by cloud providers to understand that both hardware and software can be service-enabled with equal alacrity, if not unequal results in features and functionality. As long as the underlying platform provides the means by which services and their requisite interfaces can be created, the distinction between hardware and “services” is non-existent.

The definition of “service” does not include nor preclude the use of hardware as the underlying implementation. Indeed, the value of a “service” is that it provides a consistent interface that abstracts (and therefore insulates) the service consumer from the underlying implementation. A true “service” ensures minimal disruption as well as continued compatibility in the face of upgrade/enhancement cycles. It provides flexibility and decreases the risk of lock-in to any given solution, because the implementation can be completely changed without requiring significant changes to the interface.

This is the transformational challenge that IT faces: to stop thinking of solutions in terms of deployment form-factors and instead start looking at them with an eye toward the services they provide. Because ultimately IT needs to offer them “as a service” (which is a delivery and deployment model, not a form factor) to achieve the push-button IT envisioned by the term “IT as a Service.”

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,platform,service,cloud computing,SOA,WAN optimization,hardware,software,blog

Ecosystems are Always in Flux

Lori MacVittie — Mon, 28 Nov 2011 12:27:00 GMT

#devops An ecosystem-based data center approach means accepting the constancy of change…

It is an interesting fact of life for aquarists that the term “stable” does not actually mean a lack of change. On the contrary, it means that the core system is maintaining equilibrium at a constant rate. That is, the change is controlled and managed automatically either by the system itself or through the use of mechanical and chemical assistance.

Sometimes, those systems need modifications or break (usually when you’re away from home and don’t know it and couldn’t do anything about it if you did anyway but when you come back, whoa, you’re in a state of panic about it) and must be repaired or replaced and then reinserted into the system. The removal and subsequent replacement introduces more change as the system attempts to realign itself to the temporary measures put into place and then again when the permanent solution is again reintroduced.

A recent automatic top-off system failure reminded me of this valuable lesson as I tried to compensate for the loss while waiting for a replacement. This 150 gallon tank is its own ecosystem and it tried to compensate itself for the fluctuations in salinity (salt-to-water ratio) caused by a less-than-perfect stop-gap measure I used while waiting a more permanent solution. As I was checking things out after the replacement pump had been put in place, it occurred to me that the data center is in a similar position as an ecosystem constantly in flux and the need for devops to be able to automate as much as possible in a repeatable fashion as a means to avoid incurring operational risk.

PROCESS is KEY

The reason my temporary, stop-gap measure was less than perfect was that the pump I used to simulate the same auto-top off process was not the same as the one used by the failed pump. The two systems were operationally incompatible. One monitored the water level and automatically pumped fresh water into the tank as a means to keep the water level stable while the other required an interval based cycle that pumped fresh water for a specified period of time and then shut off. To correctly configure it meant determining the actual flow rate (as opposed to the stated maximum flow rate) and doing some math to figure out how much water was actually lost on daily basis (which is variable) and how long to run the pumps to replace that loss over a 24 hour period.

Needless to say I did not get this right and it had unintended consequences. Because the water level increased too far it caused a siphon break to fail which resulted in even more water being pumped into the system, effectively driving it close to hypo-salinity (not enough salt in the water) and threatening the existence of those creatures sensitive to salinity levels (many corals and some invertebrates are particularly sensitive to fluctuations in salinity, among other variables).

The end result? By not nailing down the process I’d opened a potential hole through which the stability of the ecosystem could be compromised. Luckily, I discovered it quickly because I monitor the system on a daily basis, but if I’d been away, well, disaster may have greeted me on return.

The process in this tale of near-disaster was key; it was the poor automation of (what should be) a simple process.

This is not peculiar to the ecosystem of an aquarium, a fact of which Tufin Technologies recently reminded us when it published the results of a survey focused on change management. The survey found that organizations are acutely aware of the impact of poorly implemented processes and the (often negative) impact of manual processes in the realm of security:

66% of the sample felt their change management processes do or could place the organization at risk of a breach. The main reasons cited were lack of formal processes (56%), followed by manual processes with too many steps or people in the process (29%).

-- Tufin Technologies Survey Reveals Most Organizations Believe Their Change Management Processes Could Lead to a Network Security Breach

DEVOPS is CRITICAL to MAINTAINING a HEALTHY DATA CENTER ECOSYSTEM

The Tufin survey focused on security change management (it is a security focused organization, so no surprise there) but as security, performance, and availability are intimately related it seems logical to extrapolate that similar results might be exposed if we were to survey folks with respect to whether or not their change management processes might incur some form of operational risk.

One of the goals of devops is to enable successful and repeatable application deployments through automation of the operational processes associated with a deployment. That means provisioning of the appropriate security, performance, and availability services and policies required to support the delivery of the application. Change management processes are a part of the deployment process – or if they aren’t, they should be to ensure success and avoid the risks associated with lack of formal processes or too many cooks in the kitchen with highly complex manually followed recipes. Automation of configuration and policy-related tasks as well as orchestration of accepted processes is critical to maintaining a healthy data center ecosystem in the face of application updates, changes in security and access policies, as well as adjustments necessary to combat attacks as well as legitimate sudden spikes in demand.

More focus on services and policy as a means to not only deploy but maintain application deployments is necessary to enable IT to continue transforming from its traditional static, manual environment to a dynamic and more fluid ecosystem able to adapt to the natural fluctuations that occur in any ecosystem, including that of the data center.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,ecosystem,architecture,devops,security,performance,availability,automation,cloud,virtualization,orchestration,services,Tufin,blog

IT Services: Creating Commodities out of Complexity

Lori MacVittie — Mon, 24 Oct 2011 12:48:00 GMT

Let’s ignore the business for a moment. Why should IT be excited about IT as a Service?

The focus of IT as a Service (ITaaS) is generally on the value it would provide with respect to self-service provisioning for both business and IT customers alike. But let’s ignore the business for a moment, shall we? Let’s get downright selfish and consider what benefits there are to IT in implementing IT as a Service.

The big exciting thing about IT as a Service for IT folks is how it enables less-disruptive change. Less-disruptive means less work, less testing, less problems. At the foundational layer, in the data center architecture, it also provides IT the means by which solutions can be effectively commoditized. It’s one of the hidden benefits associated with service-focused paradigms in general, enabled by the power of abstraction.

The definition of commoditize according to Merriam-Webster is “to render a good or service widely available and interchangeable with one provided by another company”.

It is important before we continue on not to conflate interchangeable with interoperable. In many cases, service-oriented abstraction allows the pretense of interoperability where none exist by enabling a less disruptive means of interchange but it does not automagically create interoperability where none before existed.

Sorry, today you only get rainbows – no unicorns.

Abstraction and its cousin virtualization separate interface from implementation. A load balancing service, for example, virtualizes an application such that end-users interacting with the interface (the Load balancer) never need to know anything about the implementation (the actual application instances). This is how seamless scalability is achieved: adding more application instances changes the implementation, but the interface stays the same no matter how many instances may be behind it. The end user is blissfully unaware of the implementation and it can in fact be changed in any number of other ways – web server, application language, application architecture - without impacting the “application” even slightly. Storage virtualization, too, provides similar separation that allows IT to change or migrate storage area network systems – or extend them into cloud-hosted resources – without disruption. It’s a powerful tool that enables a whole lot of flexibility for IT.

VIRTUALIZATION + ABSTRACTION = FLEXIBLE ARCHITECTURE

What IT as a Service does is similar, only it does it in the foundations of the data center, across the entire infrastructure. In order to arrive at IT as a Service it’s necessary to first build up the services upon which subsequent layers can be built. Service-enabled APIs on infrastructure allow services to be developed that encapsulate specific functions, which in turn allows operational tasks to be created by automating (mashing up) the appropriate services. Those operational tasks then can be orchestrated to encapsulate an operational process, which is then exposed to business and IT folks for use in provisioning and management of resources.

Designing services is where IT needs to be careful; these services should be operational functions and not vendor-specific. If the services are vendor-agnostic, it is then possible to interchange solutions simply by changing the service implementation – but not the interface. Yes, this entails effort, but I said there were no unicorns today, just rainbows. This is the essence of commoditization – interchangeable components. It also means that in the right architecture, a service could be implemented elsewhere, in a cloud computing environment or secondary data center, rather than internal to the data center. In a fully dynamic data center, that service implementation could be backed by both with the appropriate implementation chosen at run-time based on a variety of operational and business factors, i.e. context.

Service-enablement in the foundation of the architecture also provides a layer at which more flexible policy enforcement can occur. This frees IT from concerns and checkbox support in components for specific authentication systems, i.e RADIUS, LDAP, AD, etc… A policy enforcement and access control layer can easily be inserted between service-tiers (or as part of the service-tier) that provides the authentication, authorization, and even metering capabilities without requiring radical support for the same within components themselves. The beauty of abstraction for IT is its ability to decouple components from tight integration with other systems such that a more flexible architecture is achieved. The service-tier effectively commoditizes the infrastructure layer and provides a safe[r] zone in which IT can optimize the infrastructure without negatively impacting those concerned with higher layers of the architecture – devops, developers, and business ops.

A combination of virtualization and service-enablement will provide the foundation necessary for IT to move another step forward to a dynamic infrastructure and IT as a Service. IT should be excited about IT as a Service because when implemented properly it will offer more choice and flexibility in architecture and in implementation.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: MacVittie,F5,IT as a Service,ITaaS,SOA,dynamic infrastructure,cloud computing,virtualization,devops,infrastructure 2.0

F5 Friday: How Can I Manage Thee? Let Me Count the Ways…

Lori MacVittie — Fri, 16 Sep 2011 13:21:57 GMT

#v11 A robust and diverse set of management tools enabling a variety of infrastructure integration options is essential to architecting a dynamic data center

In the continuing quest for a more dynamic data center, infrastructure integration must necessarily take center stage. While virtualization has enabled fluidity of server infrastructure, it has not done so for the network and may never be wholly suitable for the task for a variety of reasons.

But the agility resulting from virtualization, the ability to manage resources on-demand, must be incorporated into the network infrastructure in order to scale an on-demand, dynamic data center. Without the means by which infrastructure can adapt to the changing allocation of resources it remains a static beast requiring additional time and effort to manage in real-time.

It is not a scalable model. The network must adapt, it must become more fluid and capable of reacting to events and triggers and conditions with respect to the security, performance, and resiliency of the applications it is ultimately tasked with delivering.

But because no two data centers are the same and because the introduction of cloud computing has, well, made architectures even more cloudy, it is necessary for infrastructure to support a robust management plane, capable of integration with other data center components, management systems, and third-party frameworks. F5 has long been committed to a robust and flexible management plane, and the introduction of iApp in BIG-IP version 11 only expands on existing management-focused technologies.

THE F5 MANAGEMENT PLANE

The F5 BIG-IP management plane comprises three categories of technology through which BIG-IP and can be configured, controlled, and integrated.

LEGACY

A stable command line interface (CLI) is the staple of network infrastructure component management and F5 BIG-IP is no exception. F5’s CLI allows complete command and control of BIG-IP technologies across the core system and its diverse set of application delivery modules. Also falling into the legacy category is SNMP support. F5 maintains a set of SNMP MIBs enabling remote management and monitoring from virtually any SNMP-compliant management system or framework. SNMP support is key to supporting F5 integration with many network monitoring and management frameworks such as Cacti and Nagios .

API BASED

F5’s API-based management is a programmatic means of control and integration. Introduced in 2001, iControl provides fine-grained control over nearly every aspect of both execution and configuration on BIG-IP systems. With specific APIs designed for use with each module, iControl is a robust, flexible means of providing control over F5 BIG-IP. It’s SOAP-based interface makes it interoperable and the DevCentral team currently supports a wide variety of libraries and assemblies specifically aimed at making use of iControl as easy as possible. Python, Microsoft PowerShell, Java, Ruby, and even PHP are among the languages and environments supported.

iControl is the primary means through which F5 BIG-IP is integrated into both commercial management offerings and cloud computing environments. Oracle, Microsoft, WhiteHat Security, HP, and VMware all leverage iControl as a means to integrate BIG-IP and its application delivery services into their respective offerings. Cloud computing providers such as Rackspace leverage the API to integrate BIG-IP scalability services into its offering, making load balancing services easily accessible to its customers.

Not to be overlooked is F5’s own Enterprise Manager: a stand-alone management appliance (also available as a virtual edition) that, like our own partners, leverages iControl to manage BIG-IP systems. It is designed to provide basic configuration management of multiple BIG-IP systems and uses a centralized model to provide a holistic view of performance and configuration of BIG-IP devices across the data center.

More on iControl:

F5 iControl

Microsoft Application Center & iControl

F5 BIG-IP Solution Enables Rackspace Customers to Integrate

F5 WhiteHat Partnership Data Sheet

SCRIPTING BASED

As the role of devops within organizations continue to develop and evolve into an operational must-have, scripting-based integration of network infrastructure becomes vital to the design of repeatable, successful application deployments. In the past, TMSH (TMOS Shell) has been the primary remote (and local) scripting language of choice. TMSH offers an object-based scripting paradigm leveraging a TCL-like interface providing much the same level of configuration and management as iControl. TMSH requires less development-focused skills and knowledge to leverage, and integrates easily within the current script-based devops paradigm for configuration and management.

With the introduction of BIG-IP version 11, iApp has joined the management plane as an evolutionary scripting-based option. The core difference between TMSH and iApp is that iApp is more abstracted and includes a user-configurable, GUI template system that is more in line with current thought on the development of self-service options for infrastructure. iApp enables packaging of application delivery service configuration in a way that provides for repeatable, consistent deployment of applications architectures – not just applications. This capability aids in reducing time to deploy and the rate of human error introduced into lengthy, complex manual processes. Managing BIG-IP application delivery services via iApp enables operations to define services that can be self-service configured by IT or even business users as well as integrated into operational process workflows through scripting or other event-based triggers. iApp is a completely new way to manage infrastructure, and it moves the management of application delivery closer to the paradigm of self-service, automated networking frameworks similar to those leveraged today in cloud computing and highly-virtualized environments.

ONE SIZE DOES NOT FIT ALL

The premise is that no single management solution can support every customer with equal satisfaction. There will always be exceptions to basic management system rules, and there will always be custom integration requirements – more so now that enterprise IT is looking to enable a dynamic data center and ultimately IT-as-a-Service. Whether it’s integrating with Puppet or Chef in a devops-focused model, pre-integrated with VMware or Oracle, or a custom integration effort to enable infrastructure as a service in the data center or as a cloud computing provider, F5’s management plane provides the flexibility necessary to manage infrastructure, as a service.

The need for integration at the infrastructure layer is not going away and, in fact, will escalate as organizations turn their eye-of-efficiency toward the network. The ability to automate network components such as application delivery controllers and enable self-service management for specific application delivery services such as load balancing, acceleration, and security will become paramount to a successful drive toward IT-as-a-Service. A robust and flexible management plane is a must-have for infrastructure components to support and enable the integration necessary to automate and orchestrate data center operational processes.

Happy Managing!

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,F5 Friday,MacVittie,management,API,scripting,integration,SNMP,CLI,cloud computing,devops,Chef,Puppet,automation,iApp,v11,TMSH,iControl

The Infrastructure 2.0–Security Connection

Lori MacVittie — Mon, 22 Aug 2011 10:37:43 GMT

#infosec #infra2 If you take one thing away from the ability to programmatically control infrastructure components take this: it’s imperative to maintaining a positive security posture

You’ve heard it before, I’m sure. The biggest threat to organizational security is your own employees. Most of the time we associate that with end-users who may with purposeful intent to do harm carry corporate information offsite but just as frequently we cite employees who intended no harm – they simply wanted to work from home and then Murphy’s Law took over, resulting in the inadvertent loss of that sensitive (and often highly regulated) data. “The 2009 CSI Computer Crime survey, probably one of the most respected reports covering insider threats, says insiders are responsible for 43 percent of malicious attacks.” (The true extent of insider security threats, May 2010)

And yet one of the few respected reports concerning the “insider threat” indicates that the danger comes not just from end-users but from administrators/operators as well. Consider a very recent case carried out by a disgruntled (former) administrator and its impact on both operations and the costs to the organization, which anecdotally backup the claim “insider breaches are more costly than outsider breaches” (Interesting Insider Threat Statistics, October 2010) made by 67% of respondents to a survey on security incidents.

The Feb. 3 attack effectively froze Shionogi's operations for a number of days, leaving company employees unable to ship product, to cut checks, or even to communicate via e-mail," the U.S. Department of Justice said in court filings. Total cost to Shionogi: $800,000.

Cornish had resigned from the company in July 2010 after getting into a dispute with management, but he had been kept on as a consultant for two more months.

Then, in September 2010, the drug-maker laid off Cornish and other employees, but it did a bad job of revoking passwords to the network. (Fired techie created virtual chaos at pharma company, August 2011)

Let us pause for a moment and reflect upon that statement: it did a bad job of revoking passwords to the network.

Yeah. The network. See, a lot of folks picked up on the piece of this story that was directly related to virtualization because Mr. Malicious leveraged a virtualization management solution to more efficiently delete, one by one, critical operational systems. But what’s really important here is the abstraction of the root cause – failure to revoke access to the network – because it gets to the heart of a much deeper rooted and insidious security threat: the disconnected way in which we manage access to data center infrastructure.

INFRASTRUCTURE IDENTITY MANAGEMENT

Many years ago I spent an entire summer automating identity management from a security perspective using a variety of tools available at the time. These systems enabled IT to automate the process of both provisioning and revocation of access to just about any system in the data center – with the exception of the network. Now that wasn’t a failing on the part of the systems as much as it was the lack of the means to do so. Infrastructure 2.0 and its implied programmatic interfaces were just starting to pop up here and there throughout the industry so there were very few options for including infrastructure component access in the automated processes. For the most part these comprehensive identity management systems focused on end-user account management so that wasn’t as problematic as it might be today. But let’s consider not only where IT is headed but where we are today with virtualization and cloud computing and how access to resources are provisioned today and how they might be provisioned tomorrow.

Are you getting the sense that we might need something akin to identity management systems to automate the processes to provision and revoke access to infrastructure components? I thought you might.

The sheer volume of “services” that might be self-service provisioned and thus require management as well as eventual revocation are overwhelming^*.Couple that with the increasing concentration of “power” in several strategic points of control throughout the network from which an organization’s operational posture may be compromised with relative ease and it becomes fairly clear that this is not a job for an individual but for a systematic process that is consistent and adaptable.

What needs to happen when an employee leaves the organization – regardless of the circumstances – is their access footprint needs to be wiped away. For IT this can be highly problematic because it’s often the case that “shared” passwords are used to manage network components and thus all passwords must be changed at the same time. It’s also important to seek and destroy those accounts that were created “just in case” as backdoors that were not specifically authorized. These “orphan” accounts, as they are often referred to in the broader identity management paradigm, must be eradicated to ensure illegitimate access is not available to rogue or disgruntled operators and administrators.

(And let’s not forget cloud computing and the challenges that introduces. Incorporating management of remote resources will become critical as organizations deploy more important applications and services in “the cloud.” )

None of these processes – revocation, mass password changes, and orphan account discovery – are particularly sought after tasks. They are tedious and fraught with peril, for the potential to miss one account can be disastrous to systems. A systematic, programmatic, automated process is the best option; one that is integrated and thus able to not only manage credentials across the infrastructure but recognize those credentials that were not authorized to be created. The bonus in implementing such a system is that it, in turn, can aid in the evolution of the data center toward a more dynamic, self-service oriented set of systems.

THE INFRASTRUCTURE 2.0 CONNECTION

Thus we arrive at the means of integration with these identity management systems: infrastructure 2.0. APIs, service-enabled SDKs, service-oriented infrastructure. Whatever you prefer to call these components it is the ability to integrate and programmatically control infrastructure components from a more holistic identity management system that enables the automation of processes designed to provision, manage, and ultimately revoke access to critical infrastructure components. Without the ability to integrate these systems, it becomes necessary to rely on more traditional, old-skool methods of management involving secure shell access and remote scripts that may or may not themselves be a source of potential compromise.

The ability to manage identity and access rights to infrastructure components is critical to maintaining a positive security – and operational – posture. It’s not that we don’t have the means by which we can accomplish what is certainly a task of significant proportions given the currently entrenched almost laissez-faire methodology in data centers today toward access management, it’s that we haven’t stepped back and taken a clear picture of the ramifications of not undertaking such a gargantuan task. The existence of programmatic APIs means it is possible to incorporate into a larger automation the provisioning and revocation of credentials across the data center. What’s not perhaps so simple is implementation, which may require infrastructure developers or very development-oriented operators capable of programmatically integrating existing APIs or architecting new, organizational process-specific services that can be incorporated into the data center management framework.

More difficult will be the integration of operational process automation for credential management into HR and corporate-wide systems to enable the triggering of revocation processes. For a while, at least, these may need to be manually initiated. The important piece, however, is that they are initiated in the first place. Infrastructure 2.0 makes it possible to architect and implement the systems necessary to automate infrastructure credential management, but it will take a concerted effort on the part of IT – and perhaps a highly collaborative one at that – to fully integrate those systems into the broader context of IT and, ultimately, the “business.”

^* This is one of the reasons I advocate a stateless infrastructure, but given the absence of mechanisms through which such an architecture could be implemented, well, it’s not productive to wish for rainbows and unicorns when what you have is clouds and goats.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,Infrastructure 2.0,dynamic infrastructure,cloud computing,architecture,security,IDM,identity management

JSON Activity Streams and the Other Consumerization of IT

Lori MacVittie — Wed, 15 Jun 2011 10:21:36 GMT

The JSON Activity Stream specification could allow the (other and oh so soon forgotten side of) consumerization of IT to make its way into the data center.

Remember when I posited that the Next-Generation Management of Data Centers Should be Modeled on Social Networking and introduced the concept of “Infrabook” – a somewhat silly-but-serious-at-the-time idea that infrastructure should get “social”?

The recent publication of JSON Activity Streams – in addition to being very exciting from an infrastructure architecture perspective – may be exactly what is needed to bring this concept to life.

Seriously.

Infrastructure already knows how to “speak” a variety of management languages such as SNMP and even XML, so why not adopt a simple HTTP + JSON approach to share real-time updates and notifications in the data center regarding the operational status of the infrastructure as well as the applications its designed to deliver?

JSON ACTIVITY STREAMS at a GLANCE

For those not familiar with Activity Streams (or JSON, for that matter) let’s take a quick look at it through a fresh lens.

JSON – Javascript Object Notation – is an unstructured data format that is (more and more) commonly used to exchange data between applications using REST APIs as well as between the client (typically a browser) and an application. It’s actually a lot like XML, minus all the really hairy nesting and schematic constraints imposed on XML. While at first used primarily to enable real-time updating of clients a la AJAX, it is more and more frequently being used on the server side of architectures and thus as a means of integration, as well. It’s fairly simple to parse and manipulate and unlike its XML predecessor is far more human-readable. JSON primarily uses a name-value mechanism for serializing data and any old-skool object-oriented programmer will see similarities in its serialization with other, past and present object-oriented serialization techniques.

A simple example of a JSON message might be:

{"person": {

  "name": "Lori",

  "gender": "Female",

  "age": "None of your business",

  "location": "Earth",

}}

Pretty simple, right? I’d argue it’s far simpler than SNMP, which is often still the primary means of communicating events and alerts across a unified center management system.

Now, Activity Streams 1.0 basically says “here’s a standardized JSON format for exchanging activity data”. It includes an actor and associated information about the actor, a verb that describes what the activity comprised – with information regarding links to the activity when appropriate – and a target, i.e. where should the action take place. An activity describing the process of publishing this post, for example, would declare me the “actor”, the URL of this post as the object to “post” (the verb) with a target encapsulating DevCentral and its blogging system.

EXTENDING to INFRASTRUCTURE

Now, embracing that concept – actor, verb, object and target – you can probably see how easy it would be to extend that to infrastructure and the events and notifications typically reported on in the data center. Components become actors, for example, with verbs perhaps comprising “report, notify or alert”. Objects become URLs back into logs or the system itself while targets may be specific people, systems or applications.

Consider then that instead of writing to a SYSLOG server, you’re writing an “Activity Stream” to an Infrabook server, essentially a database of activities from across the data center that can be correlated using mechanisms provided by the specification.

The JSON Activity Stream 1.0 specification allows for extensions, stating: “Other specifications MAY define new object types and verbs for use with the concepts and serializations defined in this specification. To be clear, new extension properties can be added anywhere in the JSON serialization of an object or activity.”

Given such extensibility options, it would be relatively simple to define a set of “verbs” that related to management of infrastructure. For example, we could define such activities as similar to those already commonly used for logging purposes on infrastructure today:

AUDIT An activity indicating a message regarding changes to the object on component actor with the target being a specific audit log, e.g. security, network, application or ops.
ALERT An activity indicating a message about a situation requiring attention regarding object on component actor with the target being a group or individual or system.
DEBUG An activity indicating a debugging (troubleshooting) message regarding object on component actor with the target being a group or individual or system.

We could also extend those common categories and come up with a few new ones that might help us better identify and prioritize messaging in Infrabook itself, such as:

ATTACK An activity indicating an object layer attack is occurring on component actor with the target being a group or individual or system.

For now, it’s not necessary to dive into specifics, we need only recognize that there are many ways we could slice and dice the kinds of activities occurring on infrastructure of which we want to be notified. For now it’s merely important to see how something as developer oriented – JSON – and social networking oriented – Activity Streams – could be applied to infrastructure and the data center in general. That’s the other side of devops; the side we rarely see but need to take more interest in if we’re going to evolve devops and Infrastructure 2.0 past scripts and service-enabled SDKs.

THIS is the OTHER CONSUMERIZATION of IT

JSON Activity Streams 1.0 is an excellent example of taking developer and application-oriented technology and applying it to operations in a way that would evolve management to better fit the way in which we, as human beings, today interact online. The next generation is comfortable with the social networking paradigm and that, as much as iPads and mobile phones and always-on mentality, is the essence of consumerization of IT – the use of Web 2.0 and beyond application technology in the organization.

Remember these predictions, back in the day when Web 2.0 was the buzzword of the day?

Technologies used to power popular consumer-oriented applications will eventually saturate the corporate market.

This is leading to the "consumerization" of the enterprise market, said Gartner analysts today at the formal opening of the Gartner Symposium ITxpo 2006 here.

Technologies such as AJAX, REST and RSS form the technical underpinnings of Web 2.0, the term used to characterize the next generation of Web applications.

-- Web 2.0: The 'Consumerization' of The Enterprise, October 2006

Applications have already adopted many Web 2.0 and social networking concepts – Salesforce.com Chatter anyone? – so it seems logical that at some point we, as in data center infrastructure folks, are also going to have to belly up to the bar of social networking and consider how to adapt its concepts to improve and evolve data center management and collaboration.

Consumerization isn’t merely having to deal with gadgets and devices penetrating the organization from consumer land, it’s adopting those technologies where and when it makes sense to do so. In the case of Web 2.0, we have yet to see that really happen in IT. But we need to if we’re going to enable the dynamic, integrated and collaborative infrastructure necessary to support an on-demand paradigm replete with hyper-connected users, applications and systems.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: MacVittie,F5,JSON,Activity Streams,social networking,infrastructure,devops,web 2.0,integration,XML,management

F5 Friday: The More The Merrier

Lori MacVittie — Fri, 20 May 2011 09:30:47 GMT

Heterogeneous storage systems remain one of the more difficult data center components to virtualize. F5 ARX and ARX Cloud Extender continue to broaden support for more systems, making it easier to normalize data storage – even if the data and provider interfaces aren’t.

This week Don joins us to share the latest news from the F5 Data Solutions Group.

The advent of directory virtualization opened up the ability to intelligently tier storage without a lot of manual intervention. The use of the strategic point of control between consumers of file services and the providers of those services through programmable rules and single-directory architecture made moving files from tier to tier without impacting users a viable option for both the short and long term.

This means that an organization can put in SSD drives for the most frequently utilized and performance-critical files, a tier one high-speed disk or disk/ssd hybrid vendor for the next level of files, and a tier two vendor’s slower solution for the bulk of files maintained in any given enterprise. The most used files go on the fastest, most expensive equipment the organization is willing to purchase, while the bulk of files go on slower but less expensive disk. For most of you, this is nothing new, this is the real benefit of storage tiering.

But unstructured data growth just continues to roll on. Without concern for the fact that many organizations are running on much tighter budgets than they were five years ago, and that those budgets are the status-quo going forward, according to research firm IDC, at an astounding 61% annually. That is a whole lot of data to manage while trying to do all of the other things that IT is responsible for, driving the relevance of storage tiering to the forefront, and making an alternate storage mechanism appealing for companies who have identified the least frequently used data on their traditional NAS storage.

Enter F5 ARX Cloud Extender, the tool that allows your directory virtualization appliance to make use of cloud storage and/or cloud storage gateways. When first released, ARX Cloud Extender was qualified for use with Iron Mountain VFS Cloud Storage, Amazon S3, and NetApp Storage Grid. The programmable API utilized to interface with these vendors was always intended as a tool to expand the offering to provide customers with the most options for their cloud storage needs.

WHAT’S NEW?

Following through on those plans, the F5 Data Solutions Group has been hard at work developing interfaces to an increasing number of cloud storage providers, with the announcement at Interop of EMC Atmos support that allows EMC object storage to be treated like any NAS device in your datacenter. That allows you to move files out to the cloud, where costs are more diffused and the pool of available resources is theoretically unlimited. More flexibility, more extensibility, and still the rules-based engine to move your data around without your manual interference.

So get ARX, choose whatever cloud storage vendor you like, rest assured that ARX secures your data while storing it in the cloud, and don’t worry at all about Web Services APIs or other non-standard file access mechanisms, ARX has you covered. Storage tiering with a breadth of cloud offerings. That makes you more agile, while saving you money. If you already own ARX but haven’t checkout ARX Cloud Extender yet, look into it, another tool to solve unstructured data growth problems will make your life easier, or your options more varied.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: MacVittie,F5,F5 Friday,storage,virtualization,cloud computing,EMC,Atmos,big data

The Consumerization of IT: The OpsStore

Lori MacVittie — Wed, 18 May 2011 09:57:10 GMT

Tablets, smart phones and emerging mobile devices with instant access to applications are impacting the way in which IT provides services and developers architect applications.

When pundits talk about the consumerization of IT they’re mostly referring to the ability of IT consumers, i.e. application developers and business stakeholders, to provision and manage, on demand, certain IT resources, most usually that of applications. There’s no doubt that the task of provisioning the hardware and software resources for an application is not only tedious but time-consuming and that it can easily – using virtualization and cloud computing technologies – be enabled with a self-service interface. Consumers, however, are demanding even more and some have begun to speculate on the existence of “app stores” within IT; a catalog of application resources available to consumers through a “so easy my five-year old can do it” interface.

Unfortunately, such systems always seem to lay upon the surface. It’s putting lipstick on a pig: the pig is still there and, like the eight-hundred pound gorilla, demands attention. The infrastructure responsible for delivering and securing the applications so readily available in such “enterprise app stores” are lagging far behind in terms of the ability to also be automatically and easily provisioned, configured and managed. What we need is an Ops Store.

IT as a SERVICE

Cloud computing environments, specifically IaaS, have gone about half-way toward creating the Ops Store necessary to complete the consumerization of IT and enable IT as a Service. Consider the relative ease with which one can provision load balancing services using most cloud computing environments today. Using third-party cloud computing provisioning and management frameworks, such processes are made even simpler, with many affording the point-and-click style of deployment required to be worthy of the moniker “on-demand” and “self-service.”

But in the enterprise, such systems still lag behind the application layer. Devops continues to focus primarily on the automation of configuration; on scripts and recipes that reduce the time to deploy an application and create a repeatable deployment experience that takes much of the guess-work and checkbox task management previously required to achieve a successful deployment. But in terms of providing an “ops store”, a simple, self-service point and click “so easy my five year old can do it” interface to such processes, we are still waiting.

But these automations are still primarily focused on topology and configuration of the basics, not on the means by which configuration and policies can be easily created, tested and deployed by the people responsible: developers and business stakeholders. Developers end up duplicating many infrastructure-related services – security, performance, etc… – not because they think they know better (although that is certainly sometimes the case) but because they have no means of integrating existing infrastructure services during the development process. It’s not that they don’t want to, they often aren’t even aware they exist and even if they are, they can’t easily integrate them with the application they are developing. And because ultimately the developer is responsible to the business stakeholder for the application, the developer is not about to abrogate that responsibility in favor of some unknown, untestable infrastructure service that will be “incorporated during deployment.” Anyone who’s sat through a user acceptance meeting for an application knows that the business stakeholders expect the application to work as expected when they test it, not later in production. It’s a Catch-22, actually, as the application can’t move to production from QA until it’s accepted by the business stakeholder who won’t accept it until it meets all requirements. If one of those requirements is, say, encryption of sensitive data then it had better be encrypted at the time the stakeholders test the application for acceptance. If it’s not, the application is not ready to move to production. The developer must provide all functionality and incorporate all services necessary to meet business requirements into the application before it’s accepted.

That means operational services provided by the infrastructure must be available to developers at the time the application is being developed, particularly for those services that impact the way in which data might be handled. Identity and access management services, for example, are critical during development to ensure that the application behavior respects and adheres to access policies.

In a DevOps world, the operations team provides infrastructure as a service to product teams, such as the ability to spin up production-like environments on demand for testing and release purposes, and manage them programmatically. [emphasis added]

-- Tired of Playing Ping Pong with Dev, QA and Ops? (CIO Update, May 2011)

Developers need a way to manage infrastructures services programmatically; an “Ops Store”, if you will, that enables them to take advantage of infrastructure services.

NEEDED: INFRASTRUCTURE DEVELOPERS

While it “would be nice” if an Ops Store was a simple to navigate and use as a existing consumer-oriented application stores. But that’s not reasonable. What is, reasonable, however is to expect that a catalog of services is provided such that not only can developers provision such services but that they can subsequently configure and invoke them during development. It seems logical that such services would be provided by means of some sort of operational API, whether SOAP or REST-based. But more important than how is that they are provided; made accessible to the developers who need them to incorporate such services as required into the broadening definition of an “application.”

It is not likely to be operational-minded folks that enable such an interface. Unfortunately, devops today is still more concerned with ops than it is development and continues to focus on providing operational automation without much concern for application integration – even though that remains a vital component to enabling IT as a Service and realizing the benefits of a truly dynamic data center. This concern will likely be left to a new role, one that has yet to truly emerge in the enterprise: infrastructure developer. One that understands how developers interface and integrate with services, in general, and can subsequently provide the operational services in a form more usable to developers, closer to an “ops store” than an installation script.

While scripting and pre-execution automated configuration systems are great for deployment, they’re not necessarily well-suited for on-demand modification and application of delivery and access policies. There are situations in which an application is aware that “something” needs to be done but it can’t do it because of its topological location. The delivery infrastructure, however, can. Consider that the dynamic nature of applications is such that it is often the case only the application, at execution time, knows the content and size of a particular response. Consider, too, that it may also recognize that the user is a “premium” member and therefore is guaranteed “higher performance.” The application developer should be able to put 2 and 2 together and instruct the infrastructure in such a way as to leverage whatever delivery policies might enable the fulfillment of that guarantee. But today there’s a disconnect. The developer, even if aware, can’t necessarily enable that collaboration because the operational automation today focuses on deployment, not execution. Developers need the means by which they can enable applications to be more contextually aware of their environment and provide actionable data to infrastructure regarding how any given response should be treated.

If we’re going to go down the path of consumerization and take advantage of the operational efficiencies afforded by cloud and service-oriented concepts, eventually the existence of Infrastructure 2.0 enabled components has to be recognized and then leveraged in the form of services that can be invoked from within the application. That will take developers, not operations, because of the nature of that integration.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: MacVittie,F5,devops,dynamic infrastructure,infrastructure 2.0,API,integration,context-aware,cloud computing

(IP) Identity Theft in Cloud Computing Environments

Lori MacVittie — Mon, 16 May 2011 10:51:02 GMT

#devops #infosec Shared resources do benefit organizations, there’s no arguing about that. But when resources forming the basis of identity are trusted and then inadvertently shared, you may find your (IP) identity misappropriated.

In the past two years there have been interesting stories floating around about what happens when IP addresses are “shared” in public cloud computing environments. You’ve no doubt heard how someone spun up an instance and was immediately blacklisted by some other website because the last application assigned that IP address was naughty on the Internets.

Organizations have struggled with such issues and admittedly they are somewhat unique to the shared, up and down nature of cloud computing. In the history of Internet this type of scenario has certainly happened with dynamically assigned IP addresses from ISPs and even statically assigned addresses that were formerly assigned to someone who got the IP address listed as a SPAMmer or otherwise tagged as a carrier of illegal or malicious intent. But these are not the only issues with shared IP addresses. It’s not really that the organization dealing with such skeletons in their IP address closet are experiencing reputation damage, it’s that technical – and often very static – security systems are tightly coupled to IP addresses. They haven’t adequately, yet, evolved to deal with the reality of highly volatile IP address assignment. We still use IP address as a “unique” identifier even though today, particularly with public cloud computing, it’s anything but.

And if you thought being tagged as guilty by (IP) association was bad enough, you haven’t considered the potential for application “identity” theft that could leave applications open to back-door attacks.

MISTAKEN IDENTITY

So let’s assume that two applications are deployed in a cloud computing environment. Let us further assume that both use multiple instances and a load balancing service to maintain availability and scalability. What happens when Application A drops an instance – and therefore its associated IP address – and that IP address is subsequently assigned to Application B?

Usually nothing bad, that’s for sure. That’s just another minutes’ work in a public cloud computing environment. But what if the load balancing service for Application A did not drop the IP address.

Yeah. Isn’t that interesting? Application A is going to break (assuming a rudimentary but commonly used in cloud computing round robin algorithm) 25% of the time. Every fourth request will result almost assuredly in either an error or the wrong content. But that’s would actual be a good thing, considering the alternative possibilities.

1. The customer who now “owns” the IP address is a legitimate customer whose only intention is to deploy an application in the cloud. The customer is angrified because this case of mistaken (IP) identity is costing them money in terms of bandwidth and processing power to constantly field requests that should not be directed to them in the first place. Those requests are not valid for their application, but they pay to process and reject them nonetheless.

2. The customer who now “owns” the IP address is an evil genius with a plan to now use the mistaken (IP) identity to serve up malicious traffic. Perhaps a browser vulnerability-based injection. Perhaps some content that looks like it belongs on the site that tricks the user into confirming their login details, providing an easy means of credential theft. Or perhaps it’s the perfect means of delivering what looks like valid content to the page that’s nothing more than a phishing attack. Oh, the options if you’re an evil genius just go on and on. After all, the IP address is trusted by the application it is serving content to, so a lot of the obstacles that attackers must navigate to deliver malicious content on other sites are eliminated in this scenario.

Think such a scenario is far-fetched? It’s not. It’s not widespread (yet), either, and it’s difficult to target an application in such a manner because of the (seemingly) random nature of IP assignment in cloud computing environments, but mass SQL injection attacks aren’t exactly targeted, either. They’re designed to take advantage of a vulnerability when one is found, and part of its usage is the discovery of such an existing vulnerability. A maliciously minded person could certainly set up such an attack method and then sit back – and wait. After all, most attackers aren’t using their money to perpetrate such attacks anyway, so they’re unlikely to care that they’ll wrack up a lot of money in instance costs while waiting for a successful scenario to come about.

HOW IT HAPPENED

There are a couple of possibilities for how such a scenario could (and did) happen. Based on the nature of load balancing and dynamic environments, however, it is easy enough to extrapolate how such a situation could easily arise.

First and foremost this scenario is enabled by a tight-coupling between “application” and “IP” address. This tight-coupling is a dependency that is no longer necessary in well-architected high-availability environments and, as we are learning, can be dangerous to the health and security of applications in highly dynamic environments such as cloud computing where IP addresses are shared and cannot be relied upon as a definitive identifier of anything. This is particularly impactful in load balanced environments, where IP addresses are still used to identify nodes and where operations has failed to separate the application identity from an IP address.

Load balancing works by applying an algorithm to choose a resource from a pool of resources dynamically. There are numerous algorithms that can factor in a number of variables (resource capacity, performance, connection limits, etc…) but all rely upon information gathered from the application to determine suitability to fulfill any given request. In healthy load balanced environments there is a very nearly symbiotic relationship between the load balancing service and the applications, as it is from the application and its supporting infrastructure that the load balancing service receives the status information crucial to making decisions.

In this particular scenario, it is likely a failure to properly monitor the application compounded a failure of process to remove a resource from the pool in the first place. In a cloud computing style environment, this may have been the result of an automation failure.

1. AUTOMATION FAILURE

The load balancing service was either local to the cloud provider or at the customer’s site and upon release of the instance/IP address, whatever automation or process that was in place that should have removed that IP address from the pool of available resources did not. This could have been due to a disconnect between the way in which the instance was de-provisioned; perhaps the customer used a method that was unanticipated by the provider and thus no corresponding entry point into an automated process was provided for, making it impossible for an automated response from the load balancing service. Or perhaps the load balancing service was external to the provider, and the resources integrated into an existing load balanced system internal to the customer’s data center, in a hybrid-style architecture and no such automation exists and instead relied upon manual intervention. Human error is a common instigator of operational failures so this is a distinct possibility as well.

2. MONITORING FAILURE

All load balancing solutions use some kind of monitoring to ensure that a resource is actually available. This monitoring occurs on a fixed interval basis as determined by the service/configuration, and can be implemented using a variety of techniques – from ICMP replies to advanced content verification. ICMP, the most rudimentary but least costly (in terms of bandwidth and processing) method, is wholly inadequate to determine the availability of an application because it is designed only to garner a response at the network (IP) layer. TCP-based monitoring, as well, is designed to garner a response at the application or web server layer, and is better than ICMP but still fails to determine whether an application is actually available in the sense that it is (1) running and (2) returning valid responses. Advanced health monitoring that verifies the availability at the network, server and application layer is the only certain method to guarantee true application availability. Such methods involve making a request and receiving a response from the application and then verifying the content is what was expected. If it is not, the node (member, resource) can be marked as “unavailable” and taken out of the rotation for the load balancing algorithm, ensuring that no further requests to that resource are made.

AUTOMATION needs CONTEXT

Regardless of what disconnect caused the load balancing service to fail to remove the instance when it was decommissioned, proper health monitoring techniques would have caught the problem and resolved it such that neither the original assignee of the IP address was serving up invalid content (or failures) and the inheritor of the IP address would not be inundated with requests that resulted in extraneous and unnecessary costs.

More importantly, however, proper health monitoring would prevent a scenario in which the (application) identity of what may be a trusted service can be misappropriated and used to further some evil genius’ plans. Automation of any kind – and make no mistake, health monitoring that can automatically pull a resource out of a pull is a form of automation – requires context to ensure it makes the right decisions at the right time. It’s simply not enough to PING or open a TCP connection and assume that means anything other than basic networking and application platform services are available. In an environment where networks and resources are shared, the ability to ascertain availability of an application is critical not only to the successful delivery of an application but as we are learning, its security as well.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: MacVittie,cloud computing,devops,load balancing,security,application delivery,monitoring,automation,dynamic infrastructure

F5 Friday: HP Cloud Maps Help Navigate Server Flexing with BIG-IP

Lori MacVittie — Fri, 06 May 2011 11:00:50 GMT

The economy of scale realized in enterprise cloud computing deployments is as much (if not more) about process as it is products. HP Cloud Maps simplify the former by automating the latter.

When the notion of “private” or “enterprise” cloud computing first appeared, it was dismissed as being a non-viable model due to the fact that the economy of scale necessary to realize the true benefits were simply not present in the data center. What was ignored in those arguments was that the economy of scale desired by enterprises large and small was not necessarily that of technical resources, but of people. The widening gap between people and budgets and data center components was a primary cause of data center inefficiency. Enterprise cloud computing promised to relieve the increasing burden on people by moving it back to technology through automation and orchestration.

As a means to achieve such a feat – and it is a non-trivial feat – required an ecosystem. No single vendor could hope to achieve the automation necessary to relieve the administrative and operational burden on enterprise IT staff because no data center is ever comprised of components provided by a single vendor. Partnerships – technological and practical partnerships – were necessary to enable the automation of processes spanning multiple data center components and achieve the economy of scale promised by enterprise cloud computing models.

HP, while providing a wide variety of data center components itself, has nurtured such an ecosystem of partners. Combined with its HP Operations Orchestration, such technologically-focused partnerships have built out an ecosystem enabling the automation of common operational processes, effectively shifting the burden from people to technology, resulting in a more responsive IT organization.

HP CLOUD MAPS

One of the ways in which HP enables customers to take advantage of such automation capabilities is through Cloud Maps. Cloud Maps are similar in nature to F5’s Application Ready Solutions: a package of configuration templates, guides and scripts that enable repeatable architectures and deployments. Cloud Maps, according to HP’s description:

HP Cloud Maps are an easy-to-use navigation system which can save you days or weeks of time architecting infrastructure for applications and services. HP Cloud Maps accelerate automation of business applications on the BladeSystem Matrix so you can reliably and consistently fast- track the implementation of service catalogs.

HP Cloud Maps enable practitioners to navigate the complex operational tasks that must be accomplished to achieve even what seems like the simplest of tasks: server provisioning. It enables automation of incident resolution, change orchestration and routine maintenance tasks in the data center, providing the consistency necessary to enable more predictable and repeatable deployments and responses to data center incidents.

Key components of HP Cloud Maps include:

Templates for hardware and software configuration that can be imported directly into BladeSystem Matrix
Tools to help guide planning
Workflows and scripts designed to automate installation more quickly and in a repeatable fashion
Reference whitepapers to help customize Cloud Maps for specific implementation

HP CLOUD MAPS for F5 NETWORKS

The partnership between F5 and HP has resulted in many data center solutions and architectures. HP’s Cloud Maps for F5 Networks today focuses on what HP calls server flexing – the automation of server provisioning and de-provisioning on-demand in the data center. It is designed specifically to work with F5 BIG-IP Local Traffic Manager (LTM) and provides the necessary configuration and deployment templates, scripts and guides necessary to implement server flexing in the data center.

The Cloud Map for F5 Networks can be downloaded free of charge from HP and comprises:

The F5 Networks BIG-IP reference template to be imported into HP Matrix infrastructure orchestration
Workflow to be imported into HP Operations Orchestration (OO)
XSL file to be installed on the Matrix CMS (Central Management Server)
Perl configuration script for BIG-IP

White papers with specific instructions on importing reference templates, workflows and configuring BIG-IP LTM are also available from the same site. The result is an automation providing server flexing capabilities that greatly reduces the manual intervention necessary to auto-scale and respond to capacity-induced events within the data center.

Happy Flexing!

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: MacVittie,F5,F5 Friday,HP,Cloud maps,CLoud Computing,automation,infrastructure 2.0,integration