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 sixth 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.

As SDx disrupts traditional business models in just about every industry, it places new demands on IT infrastructure and changes the technical requirements to operate it. SDx applications and cloud infrastructure require a level of scale, automation, and flexibility that traditional IT infrastructure simply was not designed to support, and the toll is starting to show.

The seemingly limitless technology demands, the booming number of SDx applications, and the shift to cloud-based IT services have created an unprecedented workload for the IT infrastructure that only continues to grow. Software-defined infrastructure (SDxI) is the next-generation, cloud-first infrastructure that can connect and manage billions of end users, billions of virtual and physical services, and millions of applications.

At a macro level, SDxI differs from traditional IT infrastructure in that it is designed to leverage software innovation over hardware and automation over manual operations. Rather than make traditional all-in-one products or product suites, SDxI uses cross-technology programmability to create highly customized solutions that integrate various technologies and products. In the last installment of our series, we talked about how SDxI has spawned new use cases that help define how to apply SDxI technologies to next-gen business problems. Here, we’ll define the specific attributes SDxI infrastructure needs to address these use cases and the ones yet to be defined.

Next-generation IT problems are rapidly outpacing old infrastructure models, frameworks, and operating processes. Changing economics, business models, and upstarts have eroded the competitive edge of companies that built IT advantages over the last 30 years.

For example, traditional powerhouses such as Hertz, NBC/Universal, Target, and Hilton are based on traditional business models and legacy IT capabilities. Yet it’s companies like Uber, Facebook, Alibaba, and AirBnB who are the most valuable in their industries. These new leaders own no cars, create no content of their own, maintain no inventory, and own no real estate, but they understand that meeting business and customer demands in an SDx world require a fundamentally different approach. Each of these upstarts runs its business off the next generation of IT infrastructure, often built with common building blocks tied together with unique software.

To achieve the gains SDx technologies promise, the shift from traditional infrastructure to SDxI must go beyond form factor changes. Simply replacing physical routers with virtual ones without upgrading the rest of the infrastructure or the management and orchestration systems will not come close to realizing the potential of SDxI. Developing a software-defined infrastructure that meets the demands for personalization, customization, agility, scale, and efficiency requires more than just acquiring software-defined components. SDxI also depends on improvements in deployment, integration, security, and orchestration between components and supporting hardware platforms.

As we developed our taxonomy of SDxI use cases, we identified a common set of infrastructure attributes among both end users and vendors who are successfully using SDx technologies. Following is a summary of key SDxI attributes and examples of real-world scenarios that reflect them:

SDxI must be highly software-centric to meet the agility, automation, and efficiency requirements of SDx applications. Instead of spending time working with vendors to develop proprietary hardware-based solutions to solve infrastructure problems, SDxI builders instead focus on innovation in software. They’ve found that commercial, off-the-shelf (COTS) hardware platforms more than suffice with their compute and data handling capabilities.

The performance gap between proprietary hardware and COTS systems has closed drastically in recent years and continues to shrink. Spurred on by large R&D investments, platforms based on x86 and ARM architectures are advancing rapidly. This allows SDxI architects across enterprises, cloud service providers, and telecommunications service providers to keep hardware platforms universal and consistent in order to focus more energy on software that transforms the platforms into a scalable backend for SDx applications.

For example, Facebook developed and runs one of the largest data center operations in the world. Driven by a need to lower costs and achieve higher utilization of the hardware platform, it spearheaded the Open Compute Project (OCP), which creates open-source hardware designs for compute, storage, and networking based on COTS platforms. Many OEM platform manufacturers have adopted the resulting solutions, and the project has attracted many other contributors. Facebook has tapped into the collective hardware expertise across manufacturers, freeing itself up to focus on software innovations.

At the same time that it introduced OCP, Facebook also drove innovations in other software SDxI components for storage, database, and application frameworks. It developed advanced software designed to operate data centers much more efficiently and released its Facebook Open Switching System (FBOSS) into open source to help adoption of software-driven data centers.

Beyond a focus on software, SDxI tends to be highly virtualized across compute, networking, and storage elements that are managed and orchestrated by resource management systems. The type of virtualization may vary from hypervisor- and container-based, to API-based. This approach of separating the application from the underlying hardware and even software elements allows greater portability of applications across a wide variety of hardware and software platforms, allowing for increased agility and choice.

Virtualization also provides superior management for supporting template-driven deployment (e.g. cloning or using preconfigured VMs), snapshotting, and rollbacks. Even when infrastructure executes on bare-metal systems, SDxI can use bare-metal management systems that provide an abstraction for orchestration systems to work with to minimize the dependence on specific hardware elements.

For example, many well-known SDx applications today utilize Amazon’s AWS EC2 cloud infrastructure. AWS utilizes a modified version of the Xen hypervisor-based compute system as well as their proprietary virtualized networking and storage. However, SDx applications simply interact with the EC2 API. With vendors supporting EC2-like APIs for private clouds within enterprises, these same SDx applications can be easily ported to run internally. Or conversely, these applications can be started within a private cloud but be scaled up into AWS (cloud bursting) if needed.

The latest wave of innovation at Docker and with Linux containers are driving a similar “virtualization” movement, but with applications packaged into a cluster of containers that provides agility and less overhead than traditional hypervisor-based virtualization. Docker and others also are working on network and storage virtualization initiatives that make them a compelling alternative to traditional virtualization. Regardless of the actual technological implementation, we anticipate such virtualization and abstraction will continue to be a key attribute of SDxI.

Automation provides significant ROI, even with smaller enterprise infrastructure. More importantly, it prevents costly mistakes that arise from manual configuration. Historically, physical infrastructure equipment (compute, storage, network) was configured item by item, port by port, line by line. This command-line-driven approach requires far too much manual work for a large SDx application, which may scale to thousands to tens of thousands of servers, and hundreds to thousands of networking and storage elements.

SDxI teams often use DevOps tools once used primarily for server and application configuration – tools like Puppet, Chef, Ansible, CFEngine, and Salt – to configure networking and storage elements. Coupled with SDN and NFV approaches for networking, this has improved manageability and automation, and increased the scale a single infrastructure administrator can manage. The ratio of administrator to possible devices managed now has increased from one administrator to tens or hundreds of devices, to one administrator to thousands of devices.

For the largest scale in SDxI, infrastructure teams are looking for the next step up: policy- and intent-driven infrastructure. Policy- and intent-based systems can continually monitor the infrastructure for events and changes, react to them automatically if appropriate, and alert administrators in real time to ensure the intended policy is enforced. Such an infrastructure needs to provide sufficient embedded intelligence that can automatically translate intent into actual commands on infrastructure elements without requiring DevOps teams to create complex automation scripts that need humans to issue them at the right moments.

For example, Google was an early adopter of DevOps automation and SDN, and it now is driving an intent-based networking initiative along with BT and other large carriers. Other early vendor solutions such as Cisco’s ACI and Nuage’s VSP focus on defining and applying policy across an entire infrastructure instead of box-by-box configuration. And on the open-source front, we see multivendor efforts such as the Group-Based Policy initiative in OpenDaylight and OpenStack, as well as the Network Intent Composition (NIC) project on the networking front and the VMware-led open-source Congress project on the infrastructure front to ensure compliance with business and operational policies. 

SDxI must understand the appropriate context of users, applications, devices, and locations related to the creation of a virtual machine, container, or even a data flow or set of network attributes such as source/destination addresses and tags. Advanced infrastructure needs to be able to provide data gathering on context-relevant metrics for debugging, security and audit, performance management, and billing and marketing.

Historically, context-awareness was the purview of specialized point products such as networking devices (primarily Layers 4-7) that directed and processed traffic based on rules and inspecting incoming data. But this processing only occurs at specific points in the infrastructure. SDxI applications are more demanding and need holistic context-awareness across networking, compute, and storage to optimize workload placement in context of what a user, device, or app is trying to accomplish.

For example, efforts are underway to add contextual-driven automation to both private and public cloud environments via OpenStack Heat. In this model, external context-based triggers drive VMs and their computer, storage, and network resources to spin up or down to maximize performance, minimize latency, or meet appropriate business objectives. Goals may be based on users or applications that are served by the system and resource availability in the data center.

SDxI architectures by default are adaptable and extensible though modular software and hardware components that often include blocks of open-source software implemented in a service-oriented architecture (SOA). The term “microservices” is often used to describe some of these new approaches. Compared to older-generation architectures that often are layered within a single monolithic deployment (i.e. one giant packaged application), SDxI consists of a larger number of small agile components, sometimes geographically disparate and not always full-owned by the SDx application owner.

In turn, these components provide robust and scalable services (caching, registry, etc.) to each other. At the same time, each of these microservices can be swapped out with another similar-functioning component. For example, if a SQL database service is not working well for handling time-series data, the SDx architect might replace it with a NoSQL solution that handles the data much better – all without affecting the overall solution architecture.

Examples of microservices architecture in production include Amazon.com itself, which triggers up to 170 individual applications coordinated in a loose fashion. DevOps and orchestration systems play a much larger role in these architectures because of the larger number of elements to coordinate.

SDx applications are in a constant state of development. To maintain their competitive edge, businesses often need to quickly add new features and capabilities to applications, which may require new functionality at the infrastructure level. SDxI architectures and the elements within these architectures need to be field-extensible to enable application developers to customize the infrastructure based on the changing nature of their applications.

Traditional infrastructure approaches and vendors often can’t respond quickly enough to the rapid rate of change of SDx applications. In some cases, SDx application needs are so specialized to specific organizations that it simply is not profitable for a vendor to create that level of customization in the base product for such a small set of customers.

For example, large financial institutions may have specialized requirements to modify networking elements to be aware of specific fields in a financial protocol like IPFIX or messaging protocols like AMQP, and to rapidly distribute or replicate packets differently based on packet content. By leveraging the extensibility of programmable elements in network switches (e.g. Arista with its programmable FPGA), financial institutions can achieve what they need without forcing the vendor to build new functionality.

Similarly, large cloud service providers have extended functionality on infrastructure solutions by either gaining access to specialized APIs or by leveraging and extending the open-source code bases used by many white-box infrastructure providers (e.g. Cumulus Networks).

Security is the one critical SDxI attribute that is the most “work-in-progress.” Many SDx applications have access to large amounts of sensitive data (e.g. personal finance applications like Mint.com or retail applications like Amazon.com), and the number of hacking attacks is increasing. Numerous, high-profile security breaches range from the Target hack and the Sony hack, to the more recent loss of data in the breach of the U.S. government OPM database.

Given the critical importance of SDxI going forward, it is critical that every SDxI element have built-in capabilities for access control, secure and encrypted data handling, resistance against attacks, and strong authentication between components that interact. Likewise, every SDxI architecture needs to ensure overall security via improved visibility and ongoing monitoring, as well as provide a secure platform to house SDxI components.

The good news is that major infrastructure vendors are tooling up to ensure that point breaches within the infrastructure do not create massive data center exposure. Vendors including Cisco, Intel, and Microsoft have made hardening infrastructure solutions a significant initiative. Intel’s Trusted Execution Technology (TXT) ensures that the BIOS/EFI and the operating system and upwards all remain uncompromised. Vendors like Skyport use these technologies to build cloud-managed secure servers that can deployed in data centers worldwide while ensuring protection for the data and apps that reside on these servers.

The industry is making progress on the security front, but if our innovation doesn’t get ahead of the hackers, we will eventually see roadblocks to rolling out new SDx applications that add value in personal finance, medical health records, and health and fitness because of the fear that SDxI cannot protect against and contain new attacks.

Now that we’ve outlined the key attributes of an effective software-defined infrastructure, stay tuned for our next installment, when we go over SDx delivery models and form factors. Register below to receive that and every installment via email and be the first to receive them.

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 thoughts 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 7: Infrastructure Form Factors & Delivery Models
7. Software Defined Everything Part 8: Succeeding in an SDx World