Don’t Sacrifice Services for Speed

Lori MacVittie Miniatura
Lori MacVittie
Published September 26, 2016

No, not that kind of speed. The other kind of speed.

Velocity, the speed with which applications can be developed and released into production, is a common driver of organizations adopting agile development methodologies and DevOps for deployment. Metrics frequently revolve around “cycle times” and “deployment frequency”, which are often cited in conjunction with those of agile, which measure time in increasingly short “sprints” as a means to get features and functions to the market faster.

It’s about speed, and cloud has long been touted as a means to realize it. No lengthy procurement times, no wait for rack and stack. Scheduled deployment windows that may require wait times in months? No such thing. The “agility” of cloud is really just a synonym for velocity. In a 2015 survey conducted by CA Technologies, 9 out of 10 executives faced increased pressure to release apps more quickly. When achieving proper market velocity is the question, cloud is often seen as the answer.





But in rushing to the cloud, organizations are often forced to sacrifice services, generally because comparable offerings or deployment expertise aren’t available. That’s a problem, particularly when it comes to the operational trifecta of performance, security, and scale. Sacrificing any of the above can have a devastating impact on profit as well as productivity, both metrics upon which the business measures itself on a quarterly if not daily basis.

That’s likely why the majority of respondents in Network World’s 2016 State of the Network survey indicated the primary drivers of networking investments were improving performance (55%), data security (53%) and ensuring availability (50%).

Our own State of Application Delivery surveys finds similar importance placed on all three as well. When asked which services respondents would not deploy an app without, security and availability tie for the top spot. And performance? It’s the last thing organizations would give up, even if meant making their networks more secure.

Organizations need the “best of both worlds” approach. They need the agility, i.e. velocity, of cloud computing to match the speed with which dev and ops are pushing apps into production, but they can’t sacrifice the services upon which they rely for security, scale, and performance to get there. A breach, poor performance, or failure to scale at a critical moment is as damaging as not getting the app to market at all.

The problem is that the two worlds appear to be at odds with one another. This is the data center dissonance that arises from trying to support both reliability and agility at the same time.

It turns out the worlds are not actually as disharmonic as it sounds. The agility needed at the business level to optimize operations with apps and things and get features and functions to market faster and more frequently, stands on the reliability of the infrastructure that delivers it. It isn’t that the network isn’t capable of moving at that speed, it’s that the network requires a bit more attention to ensuring that not only are deployments repeatable, but that they are consistent and predictable as well.


That means the traditional approach to deploying those app services required to maintain security, scale, and speed is not the problem. It’s the velocity with which they are deployed that’s an issue. Combatting that means turning to programmatic methods like APIs and templates that, when combined with orchestration, impel the deployment of app services to greater speed. Speeds more in line with those of app dev and ops.

One solution is to employ an operationally consistent set of services in all environments, whether traditional or colo, public or private cloud. With a platform capable of deployment across a robust set of environments (like all the clouds and traditional data center), organizations can improve velocity by reducing the operational friction caused by creating and managing multiple sets of policies, some of which may be lacking the necessary capabilities to promote consistency and compliance. With a platform approach, centralized command with decentralized execution can become a reality, and provide the repeatability on which confidence in deployments is built.

The use of templates or treating ‘infrastructure as code’ promotes reliability by ensuring the consistency and repeatability of service deployments across environments, while the orchestration improves the velocity as a means to support the more fluid, agile nature of operations today.

You can have the best of both worlds. Reliability and agility. You don’t have to sacrifice services for speed. You just have to make sure you’ve got the right platform, with the right capabilities, in the right places.