Recently at the DevOps Enterprise Summit in San Francisco, one of the presenters outlined a scene from DevOps hell: The business team “forgets” to tell the development team they need an app for an upcoming campaign. This is the middle of the week, and the app is needed the following Tuesday. Yes. Less than a week. The app will support a large campaign focused on a charity for children. It’ll be announced on a morning television program. The demand is likely to be high. It’s for children, after all.
Most organizations would see this as a nightmare scenario. Rapidly building an application with an unknown user demand seems impossible. Imagine the all nighters leading up to the release and the worry of having days or weeks focused on dealing with bugs, performance issues, and scale challenges — not to mention the pressure from the company if the application fails to meet the objective and the inevitable tarnish that would have on the brand.
But the presenter calmly explained, the developers’ concern wasn’t high at all, and that was primarily for one reason. They were confident that their processes would allow them to deploy their code reliably and consistently. Why were they so confident?
In large part, this confidence was a result of a known and structured continuous delivery (CD) framework. Tools and processes are in place to test and deploy code at will with a low risk of failure or incident. I’m not able to speak to that presenter’s continuous delivery processes, but I can share how SolidFire customers find similar outcomes.
The necessary components for an application deployment can exist in the code. Organizations implementing CD can do this through automation and tool integrations. Extensible infrastructure components, like SolidFire for storage, mean that the tasks or configurations can be done without a human handoff. We focus our efforts in this regard by taking advantage of our full-featured API. Through direct integrations with platforms like Docker, OpenStack, CloudStack, and VMware, we enable our customers to effortlessly integrate SolidFire into the software deployment process.
Additionally, we can allow the use of tools such as Puppet and PowerShell or languages such as C#, Java, and Python to integrate into the tools or languages already in place in the organization. The storage layer can now be managed through code, and in many cases, without any development work by our customers.
This capability removes barriers that typically exist where time-consuming handoffs or manual tasks reduce the time to value on the deployment of the application, potentially increasing the risk associated with the deployment. We certainly hope that any last minute development efforts for our customers are geared toward taking advantage of a market opportunity instead of a lack of communication. However, if that time does present itself, our customers are already well positioned for SolidFire to be an enabler instead of a barrier. Code on!