Shifting Even Lefter: Can Infrastructure Help?
October 19, 2016

Barry Phillips
Panzura

DevOps leaders are engaged in an all-out effort to "shift left" so they can deliver better software faster and at lower cost. Much of this effort entails fairly dramatic re-engineering of the dev/test process. And, if we're honest, much of it also entails a management culture of extreme demands on the development and test team.

But while we're building our state-of-the-art DevOps toolchains and pumping our people full of Hint Kick, there may be another smart way to shift even further left:

Re-think build distribution infrastructure.

The Physics of Process

Process and management culture can't overcome the laws of physics. And if you have to share massive builds or artifacts across multiple dev and test teams worldwide—as financial institutions, game developers, and other organizations often do — physics definitely gets in your way.

That's because you have to keep shipping these massive files over the network to those multiple locations again and again as you cycle through your dev/test processes. On the typical enterprise network, that code distribution can take hours.

Consider a 10GB build distributed to five different locations from your primary facility over a 10Mbps MPLS connection. You don't have to be a network expert to do the math. If a couple of your remote locations have 5Mbps connections, it takes them 5 hours to get each build. If three of those locations have 2Mbps connections (as is likely the case in Asia), code distribution takes 12.5 hours.

So the physics of code distribution costs you a day. Repeatedly.

The irony is that the more agile and iterative you try to get in this scenario, the more you pay this distribution time-tax. Conventional code distribution is therefore a primary enemy of the Agile/DevOps "shift left" imperative.

The Shift-Enabling Alternative

The alternative to conventional ship-it-over-the-network-and-wait-a-day approach to build distribution is a hub-and-spoke model that allows you to lets you maintain a "gold copy" of your current codebase(s) in the cloud — while providing all your remote locations with their own local copies that get continuously and automatically updated with any changes as they occur.

This model eliminates network-related bottlenecks while allowing your geographically dispersed teams to collaborate without tripping over each other's work.

The result: You can shift left much more aggressively, without the constant counter-productive impediment of a network that can't deliver your builds fast enough to your entire team.

Of course, if you're leading the shift-left efforts at your company, you probably don't own your company's IT infrastructure. So you'll have to make your case to whoever does.

But it's a worthwhile effort. Hub-and-spoke code distribution gives software-intensive businesses competitive advantage by dramatically accelerating time-to-market for digital deliverables—while ensuring that test/QA rigor doesn't unnecessarily delay that delivery. It also saves infrastructure owners lots of money in storage, bandwidth costs and network acceleration hardware.

So if you want to shift left — but keep running into a chronic network bottleneck — have that conversation today. It'll be a win-win for your business and your budget!

Barry Phillips is CMO of Panzura.

The Latest

September 18, 2017

Web development and web design are intertwined in such a way that there is not one without the other — not anymore at least. The following outlines 5 benefits of collaboration ...

September 14, 2017

Mastering modern software development by building a "Modern Software Factory" is at the heart of business success in the digital economy, according to the results of a survey of over 1,200 IT leaders released today by CA Technologies ...

September 13, 2017

IT-Business convergence is needed to deliver continuous change, but many of the current tools add complexity and fail to merge the two, according to the Panaya 2017 State of Functional Testing Report ...

September 11, 2017

Application Program Interfaces (API’s) represent an effective way to build and manage mobile services. By using APIs — a set of routines, protocols and tools for building software applications — application developers no longer have to buy technology software or hardware. Instead, they can simply plug into a growing open ecosystem of API-driven services. It is simple to integrate, and saves time and money for new developers ...

September 07, 2017

More than a quarter of enterprises globally have not built, customized or virtualized any mobile apps in the last 12 months, according to the latest mobile app survey by Gartner ...

September 06, 2017

The number of malware breaches (to use a generic term) are rising in near exponential numbers and, unless there are radical changes, this is set to continue unabated. Most pundits agree with this forecast ...

September 01, 2017

DevOps encourages communication and collaboration between development and operations teams. Achieving greater synergies between the Dev and Ops teams doesn't happen overnight, but it is possible to fast track the process with the right technologies in place. One such technology is IT automation ...

August 29, 2017

Newly released data shows that distributed denial of service (DDoS) and web application attacks are on the rise once again, according to the Second Quarter, 2017 State of the Internet / Security Report released by Akamai Technologies ...

August 28, 2017

Organizations that are actively managing the quality of open source components flowing into production applications are realizing a 28 percent improvement in developer productivity, a 30 percent reduction in overall development costs, and a 48 percent increase in application quality, according to the 2017 State of the Software Supply Chain Report from Sonatype ...

August 24, 2017

Being able to deploy distinct code elements quickly, matched with the ability to deploy the next release version or the previous version, facilitates moving forward, even on failure. The small program unit minimizes the production impact upon failure — maybe only a few people experience the problem instead of a large set of application users when large code deployments go wrong. Besides implementing small code segments, there are two additional reasons why fail forward has proven successful: continuous integration and testing ...

Share this