The Seventh of an Eight-Part Series on the Future of Infrastructure in a Software-Defined World: All around us, software is running and automating more items and functions across all facets of our lives. We describe this new reality as “SDx,” for software-defined everything. This post is the seventh of an eight-part series that examines the changing SDx world, looks at the implications for IT infrastructure organizations, and provides practical information to help you stay competitive in the future.

If you want to understand how rapidly the cloud is becoming integral to IT infrastructure, just follow the money. According to the International Data Corporation’s (IDC) most recent Worldwide Quarterly Cloud IT Infrastructure Tracker, cloud IT infrastructure spending in 2014 topped $26.4 billion – up 18.7 percent from the year before. In the fourth quarter of 2014 alone, it accounted for about 30 percent of all IT infrastructure spend.

As a key element of the SDx infrastructure (SDxI) and a major driver behind sweeping changes to how we consume its components, the cloud is helping SDx transform who is buying IT infrastructure and what use cases they’re solving for. In the process, it also is shaping the form of infrastructure components and how they’re delivered to us.

In this seventh installment of our series on the future of infrastructure in a software-defined world, we look at how evolving infrastructure form factors and delivery models blur the line between technology vendors and service providers, and how they support the defining hallmarks of SDx: efficiency, flexibility and customization.

For our purposes here, we define form factors as the form in which your product comes: hardware appliance, software application, or software as a service (SaaS). Delivery models explain how you receive your infrastructure product.

Under the traditional infrastructure model, major vendors had all the power. They dictated the design of infrastructure components, and IT people consumed them. The vendors dictated how their products integrated with others, and customers were limited to whatever integration points or configuration points the vendors provided – even though the points often reflected only the most common setups driven by the majority of customers, or custom setups funded by customers willing to spend the most dollars.

IT organizations have tolerated the arrangement because (1) the IT scale differences between most of the largest customers in the client-server world were limited, and (2) IT’s span of control was not as broad as it is now.

Traditionally, a typical three-tiered application architecture for deploying web applications would consist of web servers, application servers, and database servers. Administrators would manually deploy all standard network, storage, and compute components, as well as appropriate security and acceleration appliances. The multi-stage process easily would take four to eight weeks and involve coordinating projects between application, security, operations, and infrastructure teams to bring up the infrastructure and applications, and test integration points.

This type of siloed, cumbersome process is not tenable in today’s IT environment. As adoption of SDx applications increases and IoT devices become more pervasive, the infrastructure required to support these new applications, devices, and organizations scales multiple orders of magnitude beyond the client-server needs of the last 20 years. In an SDx world, technology itself becomes a business differentiator, and traditional form factors are no longer adequate.

Organizations need infrastructures that help them get the most productivity out of their application teams. While many of the biggest players are building their own infrastructures themselves to make this happen, most organizations today count on at least the ability to customize their infrastructures (usually with software) to meet the cost and technical requirements they need to deploy SDx apps.

As with traditional infrastructure form factors, SDxI is made up of hardware components, software components, and increasingly, infrastructure functions delivered as a service. But unlike traditional components, which are veritable lockboxes of proprietary code and hardware design, SDxI form factors emphasize openness, flexibility, and customization. Here is a quick overview:

Under the previous infrastructure model, proprietary hardware products came out of the box the way they came out of the factory, with limited ability to customize or adapt to specific needs. Today, even commercial hardware products give customers the ability to programmatically control, customize, and enhance software to meet application requirements.

For example, modern switches like Arista's allow customers to install their own Linux modules and applications. And Dell will ship their switches pre-installed with different variations of open-source-based switching software that are easily customizable and modifiable.

In contrast to proprietary hardware, white box hardware (also known as commercial-off-the-shelf, or COTS) is generic, non-branded server or switch hardware. The hardware is often built using reference architectures provided by silicon manufacturers such as Intel or Broadcom, who create designs to accelerate their chips’ adoption.

The advent of SDx has been a key accelerator for the growth of white box hardware. Customers began with buying white box server hardware from contract manufacturers, installing open-source software on them, and extending and customizing the hardware by writing software tailored to their applications. The practice now has spread to networking and storage devices, and many large cloud service providers and leading enterprises have come to view white box switches as viable platforms.

From a business standpoint, the previous generation of infrastructure software was written to lock data in. This effectively locked customers in with vendors as well because once data was in a system, it was too difficult to migrate it out.

In today’s SDx era, commercial software is more open. It often provides a robust set of APIs and extensible interfaces that enable buyers to customize software to better integrate with their own applications. Vendor lock-in is still a possibility, only now it’s a matter of process rather than data. SDxI software may become so integrated into a company’s business process that it becomes an indispensable part of the infrastructure and the cost to migrate too high in terms of expense or lost revenue.

For businesses with more development and DevOps resources, open-source software allows them to get the functionality they need without having to purchase an entire software stack from an Oracle, Microsoft, or VMware. Open-source software has existed for quite some time, but now a larger, richer proliferation of open-source projects and technologies allows buyers to choose from literally thousands of options to develop their own software applications and custom infrastructure.

The vast majority of organizations will blend both proprietary and open-source software in their SDxI. For those organizations whose apps are their business differentiators, open-source and in-house development will play a more dominant role. For example, Google, Facebook, and Amazon all have used open-source software to build and tailor their infrastructure and integrate solutions with existing vendor hardware.

SaaS is no longer the new kid on the block, but it’s only been the last couple years that its reach has extended to infrastructure. Applications now can automate and simplify previously manual tasks to monitor, operate, and manage the infrastructure. Unlike expensive proprietary software limited to the few companies that can afford it, almost any infrastructure buyer can create an account and subscribe to a service.

With IaaS and SaaS, the boundary between in-house software infrastructure and external services is no longer as defined as in the past. External XaaS (as a service) solutions can be blended with proprietary vendor solutions and open-source components to build SDx applications. For example, an organization could build an SDx application using a database as a service (IBM Cloudant) back end combined with in-house private cloud infrastructure for the application and web tiers coupled with CloudFlare content delivery network (CDN) and security services.

With new infrastructure form factors come new ways of delivering them to customers. Under the old model, commercial software licenses were perpetual and based on numbers of users, sockets, CPUs, or ports. Now, even “regular” perpetual commercial infrastructure software is more like a subscription service in that it’s based on how much a customer consumes rather than the number of people using the software.

For example, networking companies like Brocade and Juniper are migrating to usage- and subscription-based pricing. If you use 10 Gigabits of firewall, they’ll charge you for 10 Gigabits. They don’t care if you spread the bandwidth over one or one thousand software and hardware appliances.

With infrastructure as a service, customers typically access applications through a subscription, then consume the applications through an end user portal, API, or the cloud. Cloud service providers (CSPs) and infrastructure vendors offer such a plethora of delivery options that it can be hard to know where to start. Here are just a few of the new delivery models:

• Application is supplied by and directly provided by an “as a service” vendor. Example: Zscaler provides Internet security as a service. Customers consume the service by setting up a connection between Zscaler and their own infrastructures, either on the front end or back end.

• Application is supplied by and delivered by a CSP. Example: Amazon Web Services (AWS), which was one of the first CSPs to begin offering infrastructure as a service. If your application is running in AWS and you want a load balancer, you check a box on the screen and Amazon supplies you with its built-in load balancing as a service. You “pay as you go.”

• Application is supplied by vendor, delivered by CSP. Example: You want to use a specific software appliance like Brocade’s virtual router, but you want to pay as you go. This delivery model allows you to essentially rent an instance from Amazon and install your Brocade vRouter, which is delivered via Amazon’s infrastructure.

• You already own a software license but want to instantiate it in the cloud. Example: You bring up a software instance in Amazon and work with a licensing manager to manage it.

With the myriad options available, the best place to get your bearings is right where you are. If you have a cloud-based architecture, start with the solutions that can integrate into your private or public cloud. If you have existing licenses or relationships with networking services or solutions, work with your vendors to figure out if your licenses are able to transition to private, public, or hybrid cloud infrastructure.

If you don't have preferred vendors, look at the built-in functionality of the cloud infrastructure you’re running applications on because it tends to provide easier integration and management. If your CSP doesn’t provide the functionality you need, see if your cloud ecosystem of partners rents third-party solutions that can be integrated with applications running on these clouds. The vRouter instance above would be one example; other applications such as a vFirewall can work the same way.

The new freedom of choice in SDx form factors and delivery models comes with a new responsibility to make those choices. The good news is that SDx applications, form factors, and delivery models are all inherently designed to promote extensibility and flexibility, allowing you to pick the best blend for your business at any time.

In the next and final installment of our series, we’ll look at how to be an effective, successful SDx player and help you prepare your organization for the SDx revolution.  As always, we encourage you to share your thoughts on the ideas we covered here, or general thoughts about the future of infrastructure in a software-defined world. Add your two cents in the comment section below, or email us. We look forward to hearing your perspective!

1. What is Software Defined Everything - Part 1: Definition of SDx
2. Software Defined Everything Part 2: Cloud Infrastructure
3. Software Defined Everything Part 3: SDx infrastructure
4. Software Defined Everything Part 4: SDx Infrastructure Buyers
5. Software Defined Everything Part 5: SDx Use Cases
6. Software Defined Everything Part 6: Infrastructure Attributes
7. Software Defined Everything Part 8: Succeeding in an SDx World