Why a modern development cycle for modern workloads is your destiny
Who doesn’t like a solid Luke Skywalker quote to kick off May 4th? While today is set aside to celebrate all things Star Wars and, for us, Stor Wars (May the Fourth Be With You!), I thought it would be appropriate to walk through one of the largest opportunities facing enterprises today: Modernizing your storage approach.
I will be the first to admit the word “modern” has been overused, which makes using it for this blog a bit of a challenge. Although the word modern is overused by so many others, I will argue they don’t necessarily have the proof points to back up the use of the word modern as it relates to their solutions and especially their delivery cycle. It’s time your “Enterprise Strikes Back.”
Finding a solution provider that will evolve to meet your future needs
As companies are investing in solutions, the smart buyers have a keen interest in more than just the features to fit their needs today, instead they also focus on how the product evolves to meet their future needs.
Qumulo not only uses the word “modern” to describe our solution, we back it up in how we deliver our solution from a product development perspective. One of the things that is refreshing for me is being part of a company that values the progress of the product through a company-wide process called “sprints.” A sprint is a feature lifecycle that we roll out every two weeks, so customers don’t have a typical wait time of 3, 6, or 9 months for a feature release. When a feature is ready and has successfully exited the sprint, the feature is rolled up into an update with other features for our customers to deploy. As I was writing this blog I was informed by one of our sales team about a customer running a competitor’s solution in one of the major PaaS clouds and suffering through loads of issues and bugs. I’m sure it will be all hands on deck by the vendor to attempt to fix this but this is not what I call modern and not what I call a customer first mode of operation. Throughout this blog I’m going to go into some detail around why selecting a solution based on features is important, and how release cycles and development models can be equally important to customers, and ultimately why Qumulo checks all of those boxes. Lastly, I’ll talk about why these differences in development philosophies matter to customer success..
Finding a solution provider that meets the pace of your business
That’s a tall order and many customers find themselves caught between a rock and a hard place due to decisions that were made even just three years ago. Could the challenges you face today have been averted by selecting an alternative solution that not only is modern by usability standards but modern in the way it is delivered? This is the “onion” we will peel back a bit because we believe this modernization may be your competitive advantage.
Finding the right solution provider
Probably the key reason decisions are made to purchase one solution over another is the feature comparison. If you have a checklist of top features you require, typically your initial pass through all of the responding vendor products are either preserved or removed based on a feature completeness score assigned to each. So, features matter, but what about tomorrow or three months down the road? What about enhancements, bug fixes, major releases? Do those matter as much during the decision-making process? How are you scoring the vendors on tomorrow versus today?
Think back to a time when you made a decision to purchase a solution, issued the PO to your reseller, and the vendor(s) subsequently submitted the order for fulfillment and somewhere along the way, 2, 3, or even 6 months down the road you finally deploy the solution only to find that your environment has changed and the features you based your selection upon are now lacking one or two checkboxes. How long did it take for the vendor to deliver a fix, an update, or a maintenance release to support you? With Qumulo, this challenge is alleviated with our robust Qumulo Care portal, where release notes, updates and technical guides are at your fingertips.
Having been on the buyer’s side, I know how important the features are when it comes to selecting the right vendor and solution, but I also learned, the hard way, how important it is to understand how the vendor responds to feature requests and enhancements.
Release cycles 101
Back in the day, a phrase I use a lot since I’ve been in this industry long enough to actually use it, we worked off of something called “planned obsolescence,” a term I first heard used by Steve Jobs in the mid to late 80s upon the delivery of the first Macintosh as he referred to the complete system. This concept was taken to new heights with the advent of the iPhone and MacBook Pro laptops years later. Ultimately, as I began working more and more with software-leading solution vendors the term of choice was “release cycle” to refer to software only. Early in my career the companies I worked with were happy with 1 major release every 1-2 years and 3-4 point or dot level releases throughout the year in between the major releases, and bug fixes when severity levels reach between 3 and 2 on a more immediate basis. You may hear this called “Sev2”, “Sev3”, etc. referring to the severity level of the bug. Below are the 5 Severity levels typically found in most development handbooks.
- Sev1 is a showstopper causing the solution to fail or not proceed with testing or qualification.
- Sev2 is a critical bug that may affect a functional area of the software to the point of failure such as a traditional method for install via a UI v a cursus interface (command line)
- Sev3 is a major bug, but doesn’t necessarily affect the entirety of the application. It may be deemed major due to the priority given or based on the usability decrement scored by quality assurance.
- Sev 4 is a minor bug
- Sev 5 is trivial
No product should ever be released with Sev 1 or Sev 2s knowingly. On occasion Sev3s are discovered during an edge case deployment by a customer that the engineering and product management team did not see as being a first class use case, in which case the vendor should quickly submit a maintenance fix for this Sev3 because it has a high priority given the use case. If a company says they have a modern solution, then their delivery cycle should match that moniker.
Agile vs Waterfall
For companies to say they have a modern solution for modern data centers, it should follow that they subscribe to a modern development approach and release cycle. In some cases, this is simply not the case. In fact I believe one of these storage oligarchs recently announced that they are moving to a 6 month release cycle! How wonderfully 90s of them to do so! Releases are just as important as the features you are selecting at the outset, in fact, I would say that during your selection process and in your selection criteria it is important to ask the question about release cycles and get it in writing. A company I worked for many years ago made significant promises to deliver features to a major telecommunications provider in the midwest if the customer agreed to purchase the solution. The customer agreed but with stipulations. If the features were not delivered on time, there would be a monetary compensation back to the customer for every month the requests went unfulfilled. While I know personally the developers were working very hard to deliver, I also know now the process of release was really holding them back from truly delivering on a timely basis. They, like many still today, were using the waterfall approach.
Why the differences between agile and waterfall, matter
These are two approaches to a project management style and philosophy. Here’s the way I look at them from a high level.
Again, this is a very high level, but it does show some significant differences between the two methodologies. I shared a little of my experience with the Waterfall method earlier, but let me address another example and how I first was exposed to what Agile development was all about and why I believe it is so important.
At a previous company I was working with a client, a good and loyal client, on a project involving a new technology we had just acquired and integrated into a brand new solution for the backup/recovery market. There was a specific requirement this customer needed and I determined based on multiple other conversations with other customers, analysts, and my own experience that this request was more broadly required for all versus just this one customer. When I brought this feature enhancement request to product engineering with all of my supporting documentation and background information to support this request, I was met with “we can probably get this done in 6 – 8 months. We have to go through a Phase review to ensure viability of your request and then continue through the balance of the phases before we can get Engineering Verification, and then QA/Test.” I asked for more clarification and found that this company, for every code adjustment, had an 8 phase process before anything could be delivered, starting with Phase 0: which was just to determine by majority vote if it would be accepted into the lifecycle model. They used and continue to use the Waterfall model. When it was explained to me I likened it to a train with a series of box cars attached to it. As you sit at a train crossing waiting for the train to pass you watch each box car sequentially move by your eyes, this linear process is what would hold up my customer receiving this feature and ultimately be the demise of this otherwise successful project.
That’s when I learned about Agile development, which has the concept of sprints, mentioned at the outset of this blog, that focuses on specific features. Unlike the waterfall approach, sprints are typically released on a schedule from two weeks to a month with preference leaning on the shorter timeline. In fact if you read the Agile Manifesto one of the key principles states, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Early and continuous delivery. That is a modern approach to meeting your ever changing business environment.
Qumulo is agile
Qumulo from day one had a vision for a company that would deliver a modern file data platform to customers who were looking for something they could not find in the market at the time. Qumulo founders interviewed seemingly 1000s of prospective customers about what they are looking for in a file data platform. This began the philosophy of placing the customer first in all things, it also meant for Qumulo to “satisfy the customer through early and continuous delivery of valuable software” we needed to do things differently from the inside out and that means we need to be agile, flexible, and customer focused. So, unlike many of the storage oligarchs who are still stuck in a waterfall or a modified waterfall model, we started fresh and with a clean slate and put the customer first by listening to their needs and delivering. Every two weeks there is a new update of code for our customers who can choose to install the updates when they are released or wait if they’d like.
Hardware Independent. Qumulo is 100% software only, which means you can choose the hardware you would like to use from our qualified list or any cloud of your choosing from the three major providers.
Hardware dependent. Some have claimed to disaggregate from the hardware but the fact remains they still are dependent on their specific branded hardware to function.
New Comers, Old Model
Some of the newer players have entered the storage market with solutions similar in construct to that of the oligarchs in that they require very specific hardware to function. While they may claim to be software only, the fact that you must choose from their one distributor with a very specific set of hardware makes them more of an “old soul” and not in a good way.
On Premises, Cloud, or Hybrid will yield the exact same experience for our customers. Because our software code will run in any of those locations without variation, our customers will have consistent usability performance whether in the cloud or on premises
Since these legacy players have yet to truly deliver a software only version of their storage solution, the cloud experience is varied between vendors and across cloud platforms. One of the legacy oligarchs will only support up to 500TB in one cloud and not all of the features one would expect from an on-premises solution. While the other just lands pallets of hardware to the cloud and calls it a “service”
New Comers, Old Model
Some of these newer players must have been part of creating the playbook for the legacy solution providers because they too have no way of creating a seamless experience in the cloud without shipping pallets of hardware and calling it a “cloud journey”. While interesting, to use the word “modern” is a stretch.
Qumulo focuses on customer outcomes and their success. As such we are an agile development group and do offer updates every two weeks. In the “cloud forward” world we live in today, you can’t wait to deliver features to your customers. It is a very competitive market we live in today and customers depend on a truly modern experience across the board.
As mentioned earlier, it appears based on the release cycles of some legacy storage vendors that they still adhere to the waterfall (or modified waterfall) methodology. 6 month release cycles, hardware revs, etc is a throwback to 20-30 years ago.
New Comers, Old Model
While some of these newcomers do leverage the agile development philosophy, they short circuit themselves by the physical design constraints of their solution by being tied to specific hardware. And while it may not be an issue today, there could be a chance the hardware will reach a point of obsolescence leaving you with no choice but to do a forklift upgrade. In fact one vendor has announced a major hardware refactoring that will make all previous versions incompatible with its ideology of long term investment protection.
Awaken your enterprise with modern solutions to outdated problems
Without a doubt the features of a product certainly weigh heavily during the selection process. If you’re looking for a solution that supports SMB3 but only supports SMB2, then it is fairly safe to say that the vendor supporting SMB2 will receive a much lower score compared to those who support SMB3. However, if you have features you require today but yet to have succinct plans for implementing those features or better yet all things are equal, then it really is incumbent upon you to dig in a little deeper and ask about tomorrow. Ask what the vendor’s release cycles are and how often you have access to updates to your software, how long the updates will take and then, ask for it in writing.
Our customers are our delight, when our customers succeed then we succeed – it is a very simple equation. From our Customer Success Slack Channel, to our Agile Development Methodology, to our open communication across business groups within Qumulo, and access to any executive on our team to answer or address any questions you may have, Qumulo is positioned to continue to accelerate into the future because we have modernized so many outdated processes and functions that still linger inside some of the legacy players and even some of the newcomers. So when we say Qumulo is the modern file data platform for your modern data center or cloud, we mean it and can back it up.
In the words of Obi Wan, “Remember…the Force will be with you, always.”
Chapa, signing off.
David A. Chapa is a technical evangelist and strategist with over 30 years of industry executive and analyst experience helping organizations with data protection, recovery, and storage–and how to leverage cloud infrastructure, from hybrid to hybrid-multi-cloud. David is the head of competitive intelligence at Qumulo.