Cloud Landscape

A DevSecOps Journey for the Enterprise

By October 30, 2018 No Comments

At Scalr, we have been fortunate to work with companies all over the world that are undergoing digital transformations where digital and enterprise applications need to innovate and be delivered faster in order to keep pace and gain competitive advantage in the market. During these often difficult transitions and after, platforms and applications have to change fast in response to ever-shorter feedback cycles, while legacy systems must be streamlined through automated deployment approaches. Enterprises need to find and adopt fundamentally new ways to build software and infrastructure, including innovative engineering practices that can embrace the necessary agility and speed.

 

Difficult Digital Transformations

 

Most organizations struggle with digital transformations as they find many challenges along the way to reaching the desired state. Often, enterprises have grown not only organically, but also through many mergers and acquisitions, leaving the current environment as a huge, overly complex technological tangle. That complexity and variety extends not only to the technologies and capabilities, but also to the approaches and practices around development, release, operations, and support for software. In many cases, organizations will spend more time and resources on testing, deploying, and releasing software than on designing and building it. Additionally, they find a lot of product incidents are the result of human error from manual testing and release processes. In the age of cloud and in the age of automation, these problems are no longer sustainable.

We find these problems across the spectrum, from long-time cloud users to complete newbies. Across the board, what these companies lack is a consolidated, enterprise-level and tool-backed approach to supporting a global, agile, and automated DevSecOps practice across the stages from planning to operation. Essentially, what we see is an adoptive and monolithic approach to managed-cloud usage with slow adaptation and a dubious approach to APIs, all of which inhibits the DevSecOps path forward.

 

An Enterprise-Grade Approach to DevSecOps

 

And while DevSecOps means different things for different stakeholders, we believe that, with the right tooling and relationship model in place, architecture and operations teams have the opportunity to lend the ‘you build it, you run it’ philosophy a certain degree of truth. Of course, there’s an operational spectrum from dedicated 24/7 ops team to the BU owns its own SLA and OLA. And DevSecOps clearly cannot be taken to mean, ‘you can do whatever you want’. So how can teams resolve these operational challenges and achieve deep and sustainable cost reductions while delivering value by streamlining IT delivery? That is the question Scalr endeavors to answer through a uniquely business-aware technology architecture.

Scalr employs a tiered, hierarchical architecture model which allows for software-defined policies to be set at multiple levels and inherited by each level below. At the corporate admin level, IT can define governance that must be upheld by every project, regardless of the business or use-case. But corporate IT cannot and should not know the intricacies of every business unit or project, and thus cannot have the responsibility to set governance policy at the application level. Instead, a second and third business unit and environment- or team-specific level has control to set its own policies around security, compliance, cost, etc. That gives development teams more flexibility and agility to build the infrastructure they need while keeping guardrails in place to guide them.

This is how we interpret increased agility supporting faster times to market, and team-level ownership of infrastructure and SLAs. We don’t interpret this as the sacrificing of controls, governance or security principles. Quite the opposite, we see this as an opportunity to drive evolutionary change. The kind of change that facilitates release at pace, introducing new features in days or hours and not weeks or months, performing those introductions or releases independently of major release cycles. This is the freedom to release with complete confidence, the ability to accelerate test cycles in representative environments, eliminating regressive defects in earlier stages of development lifecycles and identifying and mitigating security vulnerabilities at different stages of the build process.

 

Reaching the Desired State

 

Architecture and operations organizations need to deliver self-service, adaptive and guard-railed agility to developers to increase speedier times for deployments and market delivery, combined with centralizing and governing security engineering of everything deployed to the cloud. The goal of this transitional process automation and DevSecOps architecture? To deliver full automation across the DevSecOps pipeline, identify the tooling to accomplish it, and make sure that the combination of tools is fully adaptive to each other and integrated and that the engineered platform delivers the required capability set over the business, application, data and technology domains.

Over time, that the phased approach will take enterprises from an ad hoc-to-manage state to the desired optimized state. Not only will it slash complexity and time-to-market, but this automation architecture will also provide BUs and business owners better visibility and controls over their spend and will reduce risk through the centralization of security standards, as well as the elimination for the need for the business to create shadow IT and expose the enterprise to unnecessary risk and loss of reputation.

In the end, enterprises can have the vision and the power to deliver a robust DevSecOps practice, community, and consciousness that will allow them to to outpace the market and establish themselves as leaders.

 

 

Leave a Reply