Applying KnowIT: Everything as a Service, SDLC, and DevOps
Applying KnowIT: Everything as a Service, SDLC, and DevOps
In this post, I'm going to attempt to demonstrate how the convergence of DevOps culture and tooling with Software Development Life Cycle (SDLC) expressed via Platform as a Service (PaaS) can deliver the enterprise from the subjugation, bureaucracy, and downright misallocation of resources of regulated and compliant Enterprise SDLCs.
Join the DZone community and get the full member experience.Join For Free
Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.
In my last post on Everything as a Service (Software Defined Everything, Everything as a Service and the Market) I applied the KnowIT principles (NoDev, NoOps, and NoIT ) to better inform my decision-making in order to realize the outcomes we desire so that we can meet and exceed the expectations of our stakeholders when considering the 'why,' 'what,' and 'how' of delivering Everything as a Service (XaaS).
In this post, I'm going to attempt to demonstrate how the convergence of DevOps culture and tooling with Software Development Life Cycle (SDLC) expressed via Platform as a Service (PaaS) can deliver the enterprise from the subjugation, bureaucracy, and downright misallocation of resources of regulated and compliant Enterprise SDLCs. Furthermore, I will argue that the introduction of Runtime Application Self-Protection into the SDLC will compound the benefits for a fully automated DevOps Circuit.
Begin at the Beginning
For the purpose of this discussion, I consider software, systems, and service development life cycle as broadly being the same thing, a series of steps that provide a model for the development and management of the software, system, or service. Any entity engaged in the creation of these S's will have an SDLC, no matter how informal it may be.
The necessity for formalizing the SDLC into a process that is regulated, secure, and compliant is a function of the size and nature of the business; where it operates (jurisdictional boundaries: local, national, regional, and global) and the awareness which the business has of the total cost of developing and maintaining its software, systems, and or services. A detailed discussion of SDLC is beyond the scope of this post—suffice to say, a global enterprise probably maintains more than one SDLC and has a menagerie of different applications (code and binary repositories, continuous build, test, and delivery tools, etc.) often duplicating functions and their decencies, to implement their SDLC processes.
If this situation isn't complex enough, throw into the mix the traditional silos and dependencies inflicted by outmoded organizational models. For example, with the separation of development, testing, release management, and operations, unsurprisingly, you have a situation where release cycles take months.
Your best development talent leaves to join startups out of frustration, and what you have left is a potent mix of individuals that either know how to subvert the rules or worse, still actively engage in their creation. These individuals make no useful contribution and simply engage in fighting a losing battle with entropy using change requests and approval gates.
This picture may be overly bleak and somewhat exaggerated, but I'm sure it's a familiar picture to most of my readers. I think Adam Curtis's documentary series Pandora's Box captures the essence of the absurdity that can arise from the implementation of what seems to be a rational plan to manage complexity.
Ultimately, the unintended consequence of Enterprise SDLC is to impede the progress of code into production and, with it, value generation for the business and the sense of satisfaction of those creative individuals involved in producing software, systems, or services.
DevOps as a culture, practice, and toolset is penetrating the enterprise today because it has delivered results which are unambiguously superior to traditionally siloed IT with all its built-in cultural in and out groups and bizarre RACI that makes operations staff accountable for applications, while developers are off the hook as soon as the code is in production. Early and stunning success has left the business craving more DevOps from IT and the market has responded to the demand in what I believe is an excellent expression of innovation. In little more than a decade (we were doing DevOps before it was called DevOps) the culture, technology, and the market have driven DevOps awareness, if not quite full implementation, into every sector that produces IT.
However if we step back and look at the scale of Enterprise SDLC we can see how DevOps, on its own, will not fully meet the high expectations it has raised for the enterprise. The diagram below depicts a classic Enterprise SDLC. While DevOps permeates many aspects of SDLC, clearly there are gaps, most significantly in the provisioning and maintenance of the infrastructure underpinning Enterprise IT.
Everything as a Service
The demand delivery service classes that constitute XaaS: IaaS, SaaS, PaaS, etc. are of fundamental importance in realizing the full benefits of DevOps and, among these service classes, PaaS is the obvious delivery vehicle for enterprises that must maintain on-premise infrastructure while aspiring to greater cloud adoption.
In my previous post: Resurgence of Platform as a Service I outline the benefits of PaaS for the enterprise and, given the diagram above, anyone that has taken the time to evaluate PaaS technologies on the market can't fail to notice that the more mature products from vendors, with experience of enterprise clients, maintain within their product portfolios all the technical building blocks demanded by Enterprise SDLC.
What distinguishes one PaaS from another, at least from the perspective of SDLC is the degree of automation, simplicity, and flexibility that they afford for transforming existing products and processes to those that are required to deliver the goal of rapid and secure deployment into production from source.
Selecting the right PaaS for your enterprise is not a trivial matter if your goal is the transformation of IT from a complex behemoth bemoaned by the business and the butt of slurs from your developer community into an organization that truly generates value for customers, shareholders, employees, and other stakeholders.
The technology selection is the first domino to fall in the transformation journey, the first micro transformation, if it doesn't fall, or falls in the wrong direction, the consequences will be, as we like to say where I work, career limiting.
Security in the DNA of the XaasS, SDLC, and DevOps
As someone who has been coding Java on and off for about twenty years and who has spent the last ten years in IT infrastructure, I can't help but notice that the vast majority of tools that comprise a DevOps Circuit are Java-based. From issue and bug trackers to code analyzers and continuous build, test, and deploy tools, Java continues to be a ubiquitous technology within the Enterprise. This popularity is not without its costs and risks and those costs and risks are greatest in the area of security and patching.
I have discussed this problem at length in previous posts (see: Cutting the Cost of Patch Management, Enter RASP and AppSecurity for Java, and Cyber Threat Intelligence) and, for a full breakdown of the financial, temporal, and lost opportunity cost of Java patching, I direct readers to Waratek's white paper Maximising the ROI of Cyber Security Strategy with RASP. For the uninitiated, Runtime Application Self Protection (RASP) is a term championed by Joseph Feiman while he was a Research Vice President and Fellow at Gartner and refers to
Security technologies that are built or linked into an application or application runtime environment, and is capable of controlling application execution and detecting and preventing real-time attacks
Simply deploying the DevOps and SDLC Java tools to AppSecurity has a positive impact on risks and costs, but the benefits are exponentially increased when one considers that application code is what is being propagated through the SDLC and AppSecurity for Java is, therefore, applying the benefits of RASP not just to the DevOps Circuit tools and the Java containers deployed to the PaaS, but also to every line of code being built, tested, and deployed throughout the entire Enterprise SDLC. The ramifications for securing Java code, from genesis to realization in production, constitute a paradigm shift in the way that Java is secured.
Published at DZone with permission of Hussein Badakhchani . See the original article here.
Opinions expressed by DZone contributors are their own.