Developers in a technology company are responsible for innovating customer facing features and fixing errors. Their efforts are distinctly visible within and outside the organization. DevOps and Security teams (DevSecOps), on the other hand, are responsible for a defensive posture to protect the organization from threats that could lead to irreparable damage to the business. The very nature of this responsibility means there is a substantial lack of visibility. While major developer milestones are celebrated, in the DevSecOps world no news is good news. Nobody wants to hear about an intrusion attempt that was prevented or worse, a security incident that was mitigated.
What is the Conflict?
In many modern organizations, the developers feel that their productivity is hindered by DevSecOps teams who have justified blocking self-service and access to critical systems for developers citing irresponsible behavior and hence a security risk. Developers raise support tickets to DevSecOps and have to wait days for them to be fulfilled. In organizations where developers are allowed unfettered access, the security of the cloud infrastructure is in shambles. Open ports, unchanged passwords, untracked keys, unencrypted disks and the list goes on.
What led to the Conflict?
Microservices and the Death of Local Environment
In the pre-cloud world applications were largely monolithic. A single binary could be spun up in a developer’s laptop supported by a SQL server and practically all developer needs would be satisfied. With the advent of the cloud and microservices, the application split into many components. Some were owned by other developers and run as independent containers with their own packaging processes and even frameworks, while other components were provided by cloud providers as SaaS, for example S3, DynamoDB, Azure Tables, Service Bus, etc. It became very difficult to run a local stack. Access to cloud services also required access keys and provisioning in the cloud account that were no longer local and owned by the developers. What would sometimes work locally may not work in the cloud.
“The developer’s basic development lifecycle now required IT and security operations, who traditionally operated at a different (slower) cadence and were not used to the level of volatility that software development required.”
High velocity of the Cloud Era
In the pre-cloud era it was common for a popular banking website to go into maintenance for long hours and sometimes even for a whole weekend. In today’s world a momentary outage requires a root cause analysis. Continuous Integration and Continuous Deployments are mantras that further add to the woes of traditional security teams. To some extent this was addressed as long as the changes were limited to the application code and no infrastructure component was touched. But any change in the infrastructure would add multiple days of delays.
The Solution: Empathy and Automation
While the problem at hand is not something that can be designed in a single blog post, here are two foundational elements worth considering:
Empathy
The starting point towards a solution is for the developers and DevSecOps teams to have empathy towards each other’s cause as well as skill sets. Developers are not operators or InfoSec experts. Infrastructure-as-Code might be a coding tool, but the subject matter expertise in terms of IAM policies, Virtual Networks, subnets, WAF, and other such details are lost to the developers so it’s unfair to expect them to write and maintain it on their own. Similarly expecting operators to be highly proficient in Programming in unfair. Most infrastructure automation Tools like IaC, Ansible are scripts that don’t asynchronously and require a human being to execute. This unlike a self service SaaS software that developers build daily. Thus seamless self-service or fast turnaround time is unfair as well.
“Developers are not operators and Operators are not developers”
Automation
Every organization believes in automation. But most build automation for the consumption of DevSecOps rather than Developers. Further, user access to the cloud is still largely an unsolved problem. The automation has to be thought through from the lens of developer self-service with DevSecOps focusing on guard rails. Techniques like application centric abstractions, trust zones, and Just-in-Time access are fundamental to this approach.
“DevOps teams should build automation with an aim of Automating themselves out of the daily developer workflows a.k.a provide DevOps-as-a-Service.”
We understand that it is probably beyond the means of most organizations to solve this problem on their own. The industry needs a new category of automation software on top of public cloud that could be used to build a fully secure and compliant infrastructure without manual labor and subject matter expertise. A Devops-as-a-Service of sorts. We at DuploCloud claim to solve this with our We at DuploCloud claim to solve this with our DevOps-as-a-Service software platform.
Top comments (0)