As more parts of IT become "software-defined," be sure you're asking the right questions.
What does it mean to have a software-defined architecture (SDA)? Most folks seem to think it will be important in the future, but there's very little agreement on what it means and how it's useful.
For example, in a recent ESG research study, we tried to understand how people define software-defined networks, which just one aspect of a software-defined architecture. We had a wide range of responses, ranging from automation and NFV to control/data plane separation. Those who are trying to be precise with an early definition of SDN may sound rather academic. But those who wave their hands and apply SDN to almost anything modern in networking end up sounding like carnival barkers.
Much of the interest in SDA comes from data centers that want to provide services similar to public cloud providers like AWS. But simply deploying some virtualized servers does not create an SDA.
Is your company considering a software-defined architecture? Learn about all the elements and how they work together at Interop's Software-Defined Architecture Summit on May 2 in Las Vegas.
Instead of concentrating on how an SDA is implemented, we need to pay attention to the problems the architecture can solve and the outcomes it provides. Virtualization is often touted as a prerequisite for SDAs, but I think that's looking at it from a rather low level -- focusing on the "how" and not the "what."
I'd rather step back and examine whether an SDA system provides these necessary functions: abstraction, pooling, automation, and orchestrated delivery of IT resources. Then we need to look beyond these functions and need to understand the results they can provide.
By going up one more level, we can look at the outcomes. The goals of SDA are to provide:
- Efficient use of resources, providing capex reduction
- Agility in provisioning and allocation of resources, providing rapidly delivery of services
- Automated operation, providing opex reduction
For example, if you are rapidly developing and testing large-scale software systems, you probably want to rapidly spin up test platforms in an automated manner. Automated systems that use scripts will sure beat implementing that manually. The end result is faster development and testing at lower costs.
Slicing and dicing of resources is critical, too. If you pool IT resources, you can carve out a large chunk for some heavy workloads, or a much smaller segment for a small test load. Pre-allocating resources at these different levels of granularity is wasteful, and also a pain to maintain. This is particularly true for storage (disk space) and server resources (such as memory or CPU allocation).
Networking is a bit different because it's a medium for transmission and not as physically tangible (like disk space), but the same type of carving out of resources is possible by allocating bandwidth, quality of service, and various forms of traffic engineering. The end result is the ability to build out a data center with much more flexibility in allocating resources to end users (referred to as tenants in cloud systems).
So the bottom line is, when you talk about deploying an SDA, the first questions should not be about how it is implemented, or what you need to buy. Instead the conversation must revolve around the problems that need to be solved.
Depending on your needs, improving your environment could result from a simple adaptation of the technology you already have implemented. For some IT shops, a bit of software and operational changes may be all that's necessary. Then again, you may decide on a wholesale replacement of your hardware and software infrastructure. But it should depend on the outcome you want to achieve.
The Software-Defined Architecture Summit at Interop Las Vegas will explore why your business might need an SDA, and the business outcomes you can work toward. Click below to learn more and register.