Software Executive Magazine

February/March 2018

Software Executive magazine helps software executives grow their businesses by showcasing the business best practices of our readers, executives from established and innovative software companies.

Issue link:

Contents of this Issue


Page 36 of 43

FORGETTING ABOUT THE INSTRUMENTATION Earlier, I discussed selecting key metrics so that you can properly access the success of your DevOps initiative. However, it's also important to collect detailed data about both your running applications and the process- es you're using to write them and iterate on them. This data serves two main functions. The first is primarily reactive. If something goes wrong, you want to be able to trace the problem through your environment until you get to a root cause that can be fixed. You often run into second- or third-order effects. Excessive latencies somewhere in an environment increase page load times, which re- duces customer conversion, which ultimately leads to a drop in revenue. The second is more proactive: It's about detecting pat- terns and trends that you can use for things like capac- ity planning or optimizing your processes. Is your fail- ure rate going up or down? Are your developers getting burned out? We're seeing an increased use of statistics and machine learning for this type of trend analysis. Eyeballing dashboards doesn't scale and will also of- ten miss nonobvious patterns and anomalies. As with building in quality, data from early in the process can lead to fixing problems faster with less work. Cutting corners may save a few dollars in the short term but will lead to technical debt and less effective DevOps. TAKING A PATCHWORK APPROACH Much of the tooling commonly used for DevOps is open source. The cloud-native platform landscape, largely oriented around container technology, provides the most stunning example. However, many of the tools that developers use also spring from open source. The innovation that comes from all these upstream commu- nities is impressive. However, it also creates an almost irresistible temptation to cobble together unsupported and unsupportable assemblies of piece parts. The same can be said of the teams implementing DevOps. It may or may not make sense to go all-in on a cloud-native ap- proach. Some organizations prefer to focus on agility for a subset of their portfolio, while following a more conservative modernization strategy for the rest. However, for the cultural, organizational, and process reasons described above, it's important to approach DevOps as part of a coherent strategy. Not every group in the organization needs to use the same languages, tools, and methodologies. But start with a common container platform and build from there. Modular tech- nologies like microservices mean that everyone doesn't need to be in lockstep. But a technology strategy based on piecemeal adoption of the latest coolness is rarely the best path. S tomers? Better data for the business? More services to sell? These are all worthy goals, but a given business is likely to be more focused on some things than others (or they probably should be). Choose your key metrics with that in mind. If you're looking to have a direct effect on customer experience, a metric such as customer ticket volume might be ap- propriate. If it's efficiency, more cost-centric measure- ments will be better. Goldilocks' metrics are often the best — high enough level to be meaningful to business owners, while low enough level for operations and de- velopment teams to affect in some way. NOT BUILDING IN QUALITY Deployment frequency grabs a lot of DevOps headlines, but quality is just as important. This means taking time to write tests, implementing automated processes to verify you're not pushing out insecure code, and not leaving quality checks until too late in the workflow. In their 2017 State of DevOps Report, Puppet and DORA found that even low-performing teams were closing some of the speed gaps with their higher-performing peers. However, their quality wasn't improving propor- tionately. They speculate that "this is due to low-per- forming teams working to increase speed, but not in- vesting enough in building quality into the process. The result is larger failures and more time to restore service. High performers understand that they don't have to trade speed for stability or vice versa, because by build- ing quality in they get both." CONTINUING TO TREAT SECURITY AS A SILO Security has often worked as a gatekeeper at the end of the development process. That approach is out of step with the DevOps philosophy of shifting tests, security verification, and process checks to begin as early in the development pipeline as possible. "Shift left" is the term you'll often hear. There are many historical reasons why security has functioned apart from the rest of the devel- opment process. It's a specialized skillset with its own language and paranoia about all possible threats. And deep organizational security expertise is still needed. However, with DevOps (or DevSecOps if you prefer), it's important to better integrate security people into multi- functional teams. It's also important to promote a broad- er understanding of security principles and trade-offs within the organization as a whole. No one should think of security as being exclusively someone else's problem. As Gartner's Neil MacDonald wrote in a recent report, "Train all developers on the basics of secure coding, but don't expect them to become security experts." 37 SOFTWAREEXECUTIVEMAG.COM FEBRUARY/MARCH 2018

Articles in this issue

Links on this page

Archives of this issue

view archives of Software Executive Magazine - February/March 2018