Harness CTO: Where shift left goes wrong

Shift left, where developers take on more responsibility for tasks such as security and cost management, is burdening developers beyond reason.

That's according to Harness.io's field CTO Nick Durkin, who claims there's an easier way to balance speed and agility with security and reliability in software development: use artificial intelligence and machine learning to reduce the burden of tasks such as security management and container orchestration.

GitOps -- an approach to deployment that automatically updates applications and infrastructure configurations based on code stored within the popular, open source version control system Git -- can also help developers spend less time orchestrating deployments and infrastructure and more time coding, according to Durkin. Harness's GitOps-as-a-service product, released last week, adds security and scalability features for enterprises along with AI and machine learning components.

In this Q&A, TechTarget Editorial asked Durkin about GitOps-as-a-service, the trouble with container orchestration, and the failings of shift left.

Why should developers consider using GitOps as a service?

Nick Durkin

Nick Durkin: A lot of folks don't even know where to start when getting into GitOps, and it becomes arduous to set up and configure and get it going. With GitOps as a service, you don't have to know how to operate Argo, how to install things, how to get it configured, how to set up role-based access control, [how to] set up security measures -- all that is built into the platform.

If you ask anyone whose favorite thing is babysitting deployments, I've never had one person raise their hand unless it was a joke. Why not let a machine take over? Let's allow [developers] to focus on the things they're phenomenal at and not these other menial tasks.

What would you say to developers who are concerned about using AI?

Durkin: Our goal is to remove the worst part of your best engineers' jobs. That's what we use AI and ML for: a massive amount of machine learning and a tiny bit of AI to go and think about things like your best engineers.

Sometimes when people hear the word AI, it causes fear. In our world, when we hear 'AI' and 'ML,' it's a benefit, because we're doing it in the right way. I'm not creating an AI to steal your open source repositories and then share with the rest of the world. There are things to do that very well, and it becomes quite scary.

Instead, I'm using AI and ML to benefit people. If I'm sitting there Friday to get code into deployment and something went wrong, I wouldn't be spending my weekend figuring it out. Why not have a system that knows what you deployed on, what is going on which infrastructure, with which configuration, that can get you right back to where you were before you started -- without writing code?

Is Kubernetes contributing to the developer burden?

Durkin: If we look at any container orchestrator, the benefit is portability. What we have gained from it is that now I can create a container … and that container network can freely be deployed in any infrastructure, in any architecture. And I, as the developer, don't have to care. That's the goal. Where I think people have messed up is we've talked about shift left way too long. We burden the engineer with everything, and I think that's a sin.

If we look at recent studies, we've all been spending about three hours per day writing code. The rest is doing plumbing. I think what we should be doing is empowering engineers to write phenomenal code and leverage the systems to be able to get it to where it needs to go.

So you're not a shift left proponent?

Durkin: I think shift left shouldn't be about moving the workload, because if you've read what a full-stack developer needs to do today, it's a joke. Plus [employers] want 20 years of Kubernetes experience, which doesn't exist. Instead, what should be happening is providing the information all the way left as fast as we can -- getting it to the right people at the right time.

We burden the engineer with everything, and I think that's a sin.

For instance, today, I build my artifacts and whatever I need to put the code into production. I get security tests. Why wouldn't I be doing the testing as I'm committing code? Why wouldn't I be getting my container scan right then, and why wouldn't it be aggregated? Why wouldn't it be deduplicated? Why wouldn't security know which ones I've already done? And I should know automatically by giving me that information now -- when it's valuable. Shift left is about the information, and that's what we did wrong.

What should we be doing instead?

Durkin: What we should be doing is shifting the information so [engineers] can make the best decisions. [If] we trust our engineers, they will do what's best for the company. But they can't make decisions on price of cloud infrastructure if we don't provide them that information. They can't make decisions on the best way to size things; they can't make decisions on security or scans if we don't provide it to them. If we do, I guarantee you they will do what's best for the company. It's extremely important that we shift all the information left. Use AI and ML information to let your best and brightest make a decision on it.