What SaaS teaches us about automating network infrastructure
The success of SaaS is largely due to companies being able to identify and encapsulate in software commoditized business processes. The same holds true for network and infrastructure teams inside the business.
SaaS (Software as a Service) is the largest of the “cloud” markets today. In spite of the excitement around IaaS (like AWS and Azure and Google Cloud), the reality is that SaaS has far outpaced all other forms of “cloud” in terms of adoption rates and continued growth.
And it hasn’t shown signs of stopping. A poll in early 2016 illustrated this continued explosion of SaaS, with respondents reporting that the number of SaaS apps officially supported by IT growing 50% in merely one year, rising from 8 in 2015 to 12 in 2016. The report predicts that number will grow again, hitting 17 in 2017.
Considering that “cloud” is now ten years old, that’s some pretty impressive adoption rates for what are traditionally considered pretty standard applications. We are talking about CRM, ERP, CMS, and productivity-related office suites and file sharing sites.
You’re probably wondering what SaaS has to do with automating infrastructure. These are apples and steak, after all. Automating provisioning and scale in the network is not anything like SaaS.
Except it kind of is. Bear with me a moment, I’ll explain.
See, one of the common themes running through all SaaS applications is commoditization of function. Drag and drop for file sharing is a pretty well-understood paradigm for sharing files, whether it’s on the desktop using shared folders on the network or using a browser-based interface. Same thing for documents and presentations, and even publishing content. There’s a pretty well-defined process that defines how one goes about doing X or Y, and whether the interface is a web-browser or a stand-alone app doesn’t really change the process, just the icons and interface.
Many business functions, too, are highly standardized (commoditized). The process a customer service representative (CSR) follows upon answering your very important call (and it really is, they all assure us it is) is likely very much the same regardless of who you’re interacting with. Calling the cable company or a retail firm about an order nets you a fairly standardized experience. But don’t take just my word for it, here’s a great article from Harvard Business Review (from 2005) discussing this very convergence on process standardization that would, shortly thereafter, lead to the phenomenon now known as “SaaS.”
Standard processes also allow easier outsourcing of process capabilities. In order to effectively outsource processes, organizations need a means of evaluating three things in addition to cost. First is the external provider’s set of activities and how they flow. Since companies have not reached consensus on just what comprises cost accounting or HR benefits management, for example, it remains ambiguous what services should be performed between buyers and providers. Therefore, organizations need a set of standards for process activities so that they can communicate easily and efficiently when discussing outsourced processes. These process activity and flow standards are beginning to emerge in a variety of businesses and industries. Some are the result of efforts by process groups such as the Supply-Chain Council, which has more than 800 businesses as members.
Once any process is standardized (commoditized) it becomes pretty easy to codify and slap a front end on it that you can sell. And I’d posit that it was the underlying commoditization of those business functions that helped propel early SaaS providers to stardom. With a basic data model and interface, it was pretty easy to provide the minimal customization required by customers to make the process match the customer’s needs. Voila. Instant success.
Now let’s apply that to infrastructure and the network. There are quite a few processes related to provisioning, management, and scale that are so commoditized across applications that netops can type the commands required in their sleep. The only deviations are application-specific variables like ports and IP addresses and routes. These are the changes that change review boards like, because they don’t have to think about them. “Oh, you’re going to add a firewall rule for that app. Approved.”
Like the attention required of netops to execute them, their approval requires very little consideration because it’s been done a hundred times, the process is always the same, and everybody knows what’s going on. They’re consistent, predictable, and repeatable.
Approved.
These are the commoditized processes internal to IT that are ripe for automation and orchestration. These are the best places to start if you’re looking for quick wins to prove out the business value of investing in automation efforts. Build an interface atop that commoditized process, and shim it into the process (integration) in place of the manual methods being used today. Voila. You’ve reduced the costs of executing that process and as an added benefit, it’ll go faster because you didn’t have to wait for the next change control board meeting (you might be able to skip it, in fact, which is like a benefit all to itself).
Yes, it requires time and probably money (and maybe investment in tool and training) but the short time costs are going to pay off in the long run. Automating time consuming, commoditized processes frees up engineers and architects to work on other projects. Projects that aren’t likely to be automatically approved by the change control board.
SaaS wins when it looks at a business, understands a common process, and provides an easier, faster way to navigate it. That was true in 2006 and it remains true today. The same is true for infrastructure automation efforts. Find the common processes and provide an easier, faster way to navigate them – whether it’s for the “end user” or other engineers.