Let's explore the concept of what software definition is, and how it applies to the industry today as well as your IT career.
For every hundred people who throw out this term, my bet is that maybe two or three of them actually understand what it is they're talking about, and that they're not just reading from a script their marketing director threw together.
But, just what could I mean by that?
Wait a minute, Caleb! Doesn't this mean that nearly everything in the IT industry's landscape falls into this definition is some way, shape, or form? It certainly does! What's laughable about the term "software-defined" is that it's nothing new; it's actually been present since IT's infancy in most industry aspects.
Arguably, perhaps the reason it's becoming more of an industrial buzzword lately is that more controlling processes that were historically at least partially present in hardware (hard-coded modems, and RAID controllers would be a couple more obvious examples) are starting to be re-worked to be controlled more within the realm of software, CPU cycles, and memory than actual dedicated ROMs that ran the processes.
The immediate plus side to operating more in software than hardware for control is that making changes to process requirements can now be done on a lower IT level (and maybe not even by an "IT" person at all!), as opposed to the historical case of having to either manually replace ROMs or simply recode the existing ones. These positives aren't uniform across every field; modems gain a minor, by comparison, improvement by being more software-controlled while SANs gain a more sizable featureset to work with by being changeable through software.
The tradeoff to this approach, as I'm sure you may have already thought of by our earlier mention of RAID controllers, is that there's almost always a performance hit when controlling systems through software because you've added in an extra layer of management requirements. Many advocates of "software-defined" systems may argue that these performance differences are minor to the point that they may not even be noticeable, and it's not my desire to apply a blanket statement to the contrary because each industry aspect is different in this regard.
However, a closer examination of three of the more obvious pitfalls of some of the largest software-defined movements in the IT industry today would be wise. Sadly, these pitfalls are rarely mentioned - and I've lost count of the number of IT technicians I've seen who've "drank the Kool-Aid" and fallen victim to them without a real understanding of why.
Case #1 - It's Little More Than A Term In Many Cases
"You're going to have to buy our software-defined network solution's licensing if you want to buy our new hardware. We won't sell a chassis to you unless you buy the SDN licensing along with it."
To be honest, we didn't really think we needed it. We already had a network management platform in place, and saw little need to throw thousands upon thousands of dollars towards a software-driven solution that had a lot of bells and whistles on top of a pre-existing product that already fit the bill for what we needed.
And thus, a CCIE comes onsite to try and smooth things over. Charming.
He went on a storybook-style venture for a while, explaining how in recent examples he'd seen their SDN solution change route patterns using granular criteria, simplify management with graphical interfaces that showcased topology layout, and similar items. Once he was done, I had a brief side conversation with our other engineer before responding:
"With regard to the routing distinctions you described, MP-BGP and IP SLA have already provided us the same solution that you outlined - the difference is that they're free, and have been part of the IOS package for over five years. We know how to use them. As far as simplified management is concerned, we dropped Cisco Prime in lieu of a third-party solution that's been fitting the bill for what we need. Even though Cisco's SDN solution offers more features in this area, it's more than twenty times the price of our current platform. I apologize, but we're simply not interested."
A week later, we were re-quoted the Cisco hardware we wanted minus the cost of Cisco's SDN licensing.
The point I'd like to illustrate is that in some cases, "software-defined" is tacked onto an existing platform, just in a new GUI housing, when it really offers little feature difference and a minor degree of administrative simplification. It's to the point where in many points in my career myself and my fellow engineers pushed hard to keep our non-technical bosses out of these sales pitch meetings - because it's too easy to get "googly-eyed" over hearing some of these buzzwords without understanding the ramifications and how they actually apply to your existing infrastructure.
Case #2 - Hardware Always Outperforms Software
I can attest to this in bench tests that I ran back when I was drafting what ended up becoming my Hyper-Scale Failure Risk Assessment algorithm. Software RAID, in many examples, wasn't even a viable business option simply because the performance differences between it and hardware RAID were so astronomical that deployments weren't even feasible without hardware-based RAID.
While you can sit down, re-design some circuit schematics, and ultimately try to shorten the signal path for software-based RAID to traverse (and many vendors have attempted this by using sub-processors that are closer to the disk array, ASIC circuits for basic switching, etc.), the end result is that there's still a pronounced difference in performance.
The tradeoff for the additional performance is scalability. Software outscales hardware in terms of how much it can accommodate, especially in a hypercomputing environment - making it necessary past a certain point in order to continue to grow yet maintain a degree of manageability. The way to incorporate this is to beef up your hardware to the point that you can overcome some of the inherent issues with software-driven RAID platforms.
In actual practice, only the largest enterprises can do this just because the amount of money on the table and the degree of supplier connections you need distances this practice from smaller businesses. Where does the definite cutoff point lie? It various by area - you need to weigh and decide that for yourself.
Case #3 - Your Understanding Of Hardware Has To Be DEEP
And, related to our conversation, Ceph is a software-defined cluster storage platform.
I know a plethora of IT programmers who embraced Ceph thinking that they would be able to live their lives peaceably in their code without ever having to touch or understand hardware storage concepts. I mean, Ceph is hardware-independent, right? What hardware you have shouldn't need to matter to a great degree as long as it's new and powerful, right? Wrong!
If you've ever read my article on how to select hardware for hyperscaled cluster storage, you have an idea of how much work actually goes into picking out hardware! in that article, we literally dive into the circuit schematic for our motherboards to examine the signal traces to determine how efficiently our platform can handle heavy load as well as shard and cell calculations. It's because Ceph is a software- defined solution (and not a pre-packaged hardware SAN solution) that an incredible amount of research has to go into what you're going to run it on.
To a seasoned systems engineer, something like this that should be a "given" and practically second nature in the buildout process is something that many actually skim over. There were even several instances back when I worked for a somewhat large online search engine that started with "Goo" where no one I asked could explain inconsistencies between interface speeds vs. the PCI-E lanes they were matched up with for transmission, etc.
The moral of the story is that if you're going to go with a software-defined storage solution such as Ceph, you need to understand your hardware to a comparable, if not greater, degree than you understand the code that's driving your platform. Otherwise, you may end up throwing countless dollars and labor hours trying to fix a problem after-the-fact, and may even succeed in producing an RGE over it! (resume-generating event)
On the contrary, I think it brings a lot to the table. And, as mentioned at the start of our conversation, it's been present in the industry for nearly four decades already.
As with anything, understand the workings behind the lingo. Know when a term is being thrown around without any "beef" to back it up. And, above all:
Good luck. Have fun.