Last week I had the pleasure to participate in a panel that talked about the future of DevOps. It was part of Transform!2019 Event that was in Munich, Germany. Fun fact, from the hotel I could see the Google office, which brought many good memories.
The main goal of the event was to let participants a way to experience what it means to change a company to become more “Intelligent”. The way to share the knowledge was by engaging in an open dialogue between industry leaders, start-ups in the DevOps world, executives and SAP experts. The event had few tracks and many options to network which was a great opportunity to learn from others.
When it comes to creating a business that can thrive in the digital age, the benefits of DevOps are clear. Faster deployment frequency and lower failure rates are proven to be some of the advantages of DevOps adoption. It brings more velocity into your (software) organization and enables you to add more value (faster) to your users.
The panel talked about the trends in the adoption of DevOps, challenges in the transformative journey and the latest and greatest in technology to help drive results (Psst… Check JFrog E+ if you want to see one good answer to the challenges).
The main question I addressed was about security and how it’s an impediment for DevOps adoption. What should be the trade-off in DevOps Solutions between velocity and security?
My answer was that there should not be a tradeoff where you sacrifice your velocity. Security should be baked into your DevOps in a way it is helpful for the developers and not slowing them. You wish to use a tool that put guardrails and not gates, so your developers keep themselves on the paved road and not spending the time to pass gates. I saw this approach both in Google and Netflix and it’s working for these companies quite well.
How to achieve that?
On the velocity perspective you wish to use a tool that is automated and suggesting solutions so it’s not just ‘FYI’ information. Anything that can be done manually should be automated. Moreover, the tool should be securing the pipelines from the development phase up to the deployment and later monitor everything that is in production (see below the details around each phase). You also want to minimize the false-positive alerts so your developers will gain more trust in the tool. In other words, it’s not just about quantity but also about the quality of the alerts.
In terms of the security aspects, we wish the tools to have wide coverage of vulnerabilities (think beyond NVD). It should have a way to integrate with IDEs so our developers could know what are the risks while they are building the software.
Last but not least, you want to tool not just to ‘tell’ you what is wrong with the current package but what are the actions you can take, right? So it should provide a clear path to remediation. For example, a way to do a precise matching between vulnerabilities and packages and offer the ones that are fixed (e.g. think about a case where you can’t use a certain version of openSSL but the tool let you know that another version is safe from these vulnerabilities.)
Another good question that I was asked was about a claim I made at the start of the discussion (don’t ask me why): “By 2020, DevOps will be the default in every organization.” What do you foresee as the plan of action to get there?
There is no one answer that will fit all here. In each company, there will be different gaps that need to be prioritized differently. We know that most companies care about: Innovation , security and cost reduction.
Innovation : It’s a critical success factor for any company that wishes to boost innovation and keep improving its product. The speed that you gain from DevOps best practices helps you increase the possibilities to build more innovative services.
Security : An important aspect to be able to find vulnerabilities as soon as possible in the development cycle and later to mitigate them as fast as you can from production. A great DevSecOps ability is critical.
Cost : It’s helping reduce cost (finding bugs as early as possible and/or removing vulnerabilities from production). Also, it’s a leverage point to your internal development team as they can reach users faster/better/cheaper.
But the plan to attack these goals will be different from company to company. Some best practices to think about in the context of your state, organization’s culture and needs:
Choose the right tools for the job and invest in research for the best tools that will fit your needs. For example, a binary repository that is able to include all the technologies you are working with and enabling you high availability, scaling options and security out of the box.
Try it (proof of concept) on a small scale or some side project and show the value internally. It good to have an internal case study that show the value of a new tool/process (data > opinions in most arguments).
Enable DevSecOps as part of the process without slowing down the pace. Check how Xray can help you on that front.
You wish to make the process of development to deployment frictionless. There are many tools that are fragmented and you need to fight the DIY culture or the false notion that ‘we can build it here over the weekend’. The efficient way to do it is by comparing the best tools out there and measure them according to the metrics you care. For example, what is the total cost of ownership for your CI? or what is the cost of a security risk that could be found during the dev-phase?
DIY as a culture bring you to a place where there is no economy of scale without a holistic view to solving the pain points. That is why you might want to consider platforms like E+
There were many other interesting topics we talked about like:
- How will DevOps evolve over the next few years?
- How are you addressing DevOps Transformation?
- What are the current challenges that prevent adoption, especially around monitoring and observability?
- How was life before DevOps?
I hope we will have the video recording soon so I could publish it here.
Until next time, be strong and good luck with your digital transformation to the world of DevOps.