One of the things I have a huge issue with in the industry today, is the insistence on pushing a shift left approach.
According to the CNCF glossary, Shift Left is the practice of implementing tests, security, or other development practices early in the software development lifecycle rather than towards the end.
While this sounds good in theory, it fails nearly always in practice. Shift left in my mind is a buzz word with no clear definition, which means something completely different to every persona in every company. Some think about testing, others think about IaC, some think about security, while others think about application deployment, and others think about observability, and so on and so forth with every area of the SDLC. The only common denominator is that we increase the cognitive load of our developers and they end up focusing less and less on their actual domain of expertise which is writing code.
The most common area people try to shift left is security. The best explanation of the issues with this approach is like often the case via a great quote from Kelsey Hightower:
“I think we are asking developers to do too much by shifting everything left including security. While it should be a collaborative effort, the idea that developers need to become security experts, in addition to everything else, just isn’t sustainable.”
Shift left was introduced to try and help solve key challenges such as early bug detection, improving software quality, faster time to market, cost efficiency and removing IT and operations from being the blocker of innovation.
While that all sounds great in theory, the approach has serious challenges which from what I see in the industry are mainly, Skill Gaps, Increased initial workload, Cultural resistance, Bad balancing of speed vs quality, lack of separation of concerns, and tools and integration challenges due to many tools being built with different personas in mind.
‘The best analogy for the challenge of Shift left in my approach can be understood through the following story:
“Hey, Mr. Plumber, you’re pretty good at installing pipes in the unfinished walls of our new houses. But it’s kind of hard to schedule the drywall guy to show up the moment you’re done and sometimes the delay causes schedules to slip, so we’re thinking it’d be better if you’d just do the drywall too. And maybe while you’re at it, you can add a coat of paint or some wallpaper, since you’ll be at the wall anyway. That way we won’t have to wait for the painters either. Don’t worry, you’ll still have the same amount of time per job that you had when you were just doing the pipes, and you’ll still get paid the same.”
With these challenges in mind, I have started to push a new concept over the past year which i have termed “Shift Down”.
Shifting down to the platform addresses the challenges that shift left was created to solve but does so in a transparent and seamless way increasing developer productivity, without cognitive overload, and with maintaining a clear separation of concerns.
This approach in my mind is the essence of a successful platform engineering journey a company must embark on too truly advance their SDLC and DevEx.
Some key tools in the industry can be of huge assistance when trying to implement this approach including both OpenSource software as well as commerical products.
Lets examine a few of the main tools which help push this idea into practice:
•KubeScape – Automated VEX Document generation
•Harbor – Automated Image Scanning in the registry on push
•Snyk – Code Scanning in git with PR generation with security fixes
•Backstage – Central visibility for all elementes of the SDLC and runtime information
•Software Templates – custom application starters with security and standards integrated
•Kpack – Kubernetes native build system using Cloud native buildpacks
•ScaleOps – automatically fine tune resource requests based on realtime data
•Pixie – Auto instrumentation and observability for your applications
•Crossplane – Define custom APIs and abstractions above any resource or API
While this is still a new and evolving area, I believe that shifting down to the platform is the only true way forward. for a more detailed and lively explanation of what this approach entails heck out the recording of my talk on this exact topic from DevConf Boston 2024 earlier this year.
One Reply to “”