So after talking with customers and prospects over the years around the world – one unifying theme emerged – No one likes their current provisioning tools! (surprised?) While expecting infrastructure tools to flatulate rainbows may not be reasonable, we thought it would be interesting to document what we are hearing in the field. And who knows – maybe we can all work toward solutions that address modernizing infrastructure instead of just throwing out new buzzwords.
So let’s get into it:
Complaint #1: My tool(s) are too siloed
So they do one thing really well, but then to actually tie to other systems, you need an abstraction layer…and a data model…does it have an API that doesn’t fall over itself? The fix for this isn’t adding another silo – it’s getting these systems talking to each other. The problem is that if every silo wants to be the “master of truth” – you just end up moving the problem around.
Complaint #2: My tool(s) turned out to be more of a framework
Too many options and not API-driven just makes it harder, and reinforces the silo concept. This means that even minor changes to a system will be an ongoing project with a team, budget, support, etc.. This is where “shelfware” can come into play – software that is purchased, but never sees the light of production. Having a tool be able to provide value immediately, but also allow some room to grow/expand, helps mitigate this risk.
Complaint #3: My current tool(s) are scripts cobbled together with minimal documentation or historical references – but it technically works
That means that “it works” but making changes is a “real risk”. So you work around it and hope for the best…maybe an abstraction layer will help? We all have nightmares when dealing with legacy systems and being tasked with updating them to some new technology – suddenly, “it works” becomes good enough.
Complaint #4: My current vendor/tool is proprietary
This tends to come up when you talk budget. Typically the issue is that the initial cost is high for some solution, with a promise of a lower cost in the future. But when that doesn’t happen (or costs actually increase) – no one is happy. We have even heard of examples where the API for an installed system was a significant extra cost from the vendor instead of just being included by default.
Complaint #5: My current tool(s) are open-source, but there hasn’t been active development, so I need to figure out where to go next
This means that there are some open source solutions to these operational challenges, but as we all know, it’s a “roll your own” risk. This puts more pressure on the team to not only deploy the technology, but understand the business processes and product lifecycle. Then you get the added bonus of relying on someone else’s roadmap and diverging from the original solution. As a result, every upgrade can be a roller coaster, so you just stop upgrading. While you get the most flexibility here, you have to put in more resources up front and in the long term to see value. Suddenly your open source solution can look like more and more proprietary.
You are probably surprised that these 5 items were the most common complaints, and most likely your own provisioning tools are the antithesis. But here in Cranky Pants Land(TM) – DevOps lives in a world where the time required to execute is outweighed by the realities of dealing with operational tasks. We are fortunate to hear this feedback first hand and get some honest takes on the state of provisioning. While it provides us real data on how to make better software, these complaints could be around any operational code.
So What Next?
Let’s turn the frown upside down and shift to solutions. If you want to modernize your provisioning tools, how can you overcome these issues? How do you modernize your application infrastructure (SDN/NFV/$unicorn) when your plumbing capabilities are still command line driven/Excel? How do you support the reality of hybrid environments, but not drive yourself nuts having to support this mixed vendor, distributed location, DevOps landscape?
Well – we are cautiously optimistic (or is it ambiguously pessimistic?) at the positive direction that infrastructure software is going. With the proliferation of more native APIs and better automation tools being at the forefront, it bodes well for the direction of tools in this space. It is good to see the lessons learned from application and systems virtualization get applied to infrastructure, but there are plenty of examples where these new tools are just ignoring infrastructure (the saga of IPv6 compatibility is a telling use case).
So onward and upward – let’s not squish the sparkle of provisioning – but let us all learn to love operational tools again.
Questions? Concerns? You can contact us at 6connect to speak directly with an engineer. If you are looking to automate and scale your provisioning, we’ve got your back.
Email: info@6connect.com or call +1 (650) 646-2206.