May 28, 2024
Travis McPeak
The Rise of Cloud and DevOps
The last 20 years of computing have seen huge shifts, driven by the availability of cloud infrastructure and services. From the first days of S3 in March 2006 to thousands of flavors of infrastructure and software as a service, the major cloud providers have flipped the industry on its head. Traditional barriers to entry that once existed (access to computing and software) have crumbled.
With entry costs lower than ever, tens of thousands of founders joined markets that were previously prohibitively expensive to challenge. These small, scrappy startups (some of which have now scaled up) introduced entirely new ways of organizing, building, and collaborating - all based on the availability of infrastructure and software as a service.
For companies building software products, adaptation to these changes has been rapid in many areas. Development practices, product management, infrastructure operations, data management, and analytics: all have introduced new, efficient ways of working based on access to cloud services. One area that has noticeably lagged is security, having been dragged into the future by our developer counterparts. DevSecOps embeds security into development, adapting DevOps practices for security configuration. It has not lived up to its promise.
In this three-part blog series, I will explore the rise of DevSecOps, its early demise, and what the future looks like for security in a world of cloud services that is reaching maturity. If you’re a visual or auditory learner (like me), you can watch the video version of this series on our YouTube channel!
In the before times (pre-2006), every company was using on-premise servers and storage, managing their own physical devices (or paying someone else to). Before the rise of the Cloud, there were three iterations of security: nothing, an IT-owned security function, and eventually a dedicated security team responsible for things like threat modeling, security reviews, etc.
Pre-internet, the only security considerations were physical: access control, and preventing the wrong people from accessing the wrong computers/servers.
Post-internet, businesses started to move online. Amazon ushered in big commerce, and security was mostly focused on networking: firewalls, routers, switches, etc. There were several notable worms, and Y2k dominated the zeitgeist.
Between 2006 (the founding of AWS) and 2015, an explosion in cloud services meant that industries once considered stable could be disrupted by newcomers - you no longer spent millions to buy servers and maintain them. Instead, IaaS and SaaS meant that companies could create MVPs for a low cost, prove an idea, take venture funding (1), and scale while amortizing their costs into the future. Investors recognized this model as profitable in a portfolio, resulting in an explosion of VC dollars and even more funded startups entering new markets.
In previous eras, on-premise infrastructure required infrastructure operations teams to be involved with deployment. With the broad availability of hundreds of cloud services, large organizations and newcomers alike began to take advantage of the flexibility by pushing infrastructure operations onto development teams. This was the beginning of DevOps, which came to maturity during this period as teams realized the flexibility of the cloud.
Security, once owned by IT, was now a standalone organization that mirrored the old waterfall model. With the explosion of cloud availability came an exponential increase in attack vectors & surface area. This era was the beginning of targeted hacks and hacker groups, where financial information and PII was being stolen and breaches became commonplace. As a standalone function, security teams wanted to prove that investing in them was worthwhile, so they did what anyone would do: spent a lot of money, and created a lot of processes & procedures.
By the end of 2015, almost every major company was partially on cloud. DevOps adoption was growing rapidly, and as penetration of cloud services reached a critical mass, it became evident that something needed to change with security teams: they were siloed, working on a waterfall model, and holding up development. The perception of security at this time was at an all-time low.
Forward-thinking organizations like Google, Netflix, and Etsy began to reconfigure security teams and shift their responsibilities. Instead of explicitly being responsible for every security decision, they were instead responsible for security principles and best practices. The mandate: push security decision-making to the left, empowering others to make implement security in an agile model.
Who was the new security practitioner you might ask? You might have guessed already - the developer. Starting around 2014 (see the Intuit talk on DevSecOps at re:Invent in November 2014), organizations began to embed security into their DevOps practices and a whole new world appeared: DevSecOps.
What could possibly go wrong with making software engineers responsible for security? In part 2 of our 3-part series, we’ll cover DevSecOps in detail - the good, the bad, and the ugly.
