ABOUT DEVCENTRAL

DevCentral News Technical Forum Technical Articles Technical CrowdSRC Community Guidelines DevCentral EULA Get a Developer Lab License Become a DevCentral MVP

RESOURCES

Product Documentation White Papers Glossary Customer Stories Webinars Free Online Courses F5 Certification LearnF5 Training

SUPPORT

Manage Subscriptions Professional Services Professional Services Create a Service Request Software Downloads Support Portal

PARTNERS

Find a Reseller Partner Technology Alliances Become an F5 Partner Login to Partner Central

---

©2024 F5, Inc. All rights reserved.

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.

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.