Frankly Speaking, 5/12/20 - SecOps and TechOps in a Cloud-Native World
A biweekly(-ish) newsletter on random thoughts in tech and research. I am an investor at Dell Technologies Capital and a recovering academic. I am interested in security, AI/ML, and cloud.
If you were forwarded this newsletter, you can subscribe here. For more regular updates, please follow me on Twitter!
I’ve officially moved my newsletter from Mailchimp to Substack! The Substack tool allows me to focus more on content because it’s easier to use, and it’s overall a better fit for the type of content I write — blog posts that are sent out as a newsletter. Finally, it’s a much friendlier way to get someone to subscribe and not make it feel like subscribing to a marketing email.
The switch is already showing dividends as I’ve had a big increase in the number of subscribers. Because of that, I decided to write this blog post out of cycle. Thanks everyone for the support!
As usual, please forward this newsletter to anyone who you think would enjoy it.
LET’S BE FRANK
In the last few newsletters, I’ve been discussing how the public cloud is changing IT and security. I talk about how the public cloud is more session-based and how just using the cloud doesn’t make a company cloud-native.
A key point in the last newsletter is that the public cloud has shifted the bottleneck of application development from infrastructure to the developer’s ability to deliver. I wanted to expand on that more, so let’s start from first principles. Say I’m a startup building my first product. Before the public cloud, I would use my laptop or maybe raise enough money to build my own physical infrastructure. At some point, I would need scale to run my application, test it at scale, or both. So, product development required infrastructure development, resulting in the need for an IT team.
One thing to note is that it would typically take at least 2 years to build a product this way and of course high capital expenditure. Now, with the public cloud, I’ve seen startups build products with low operating expenses in 6 months. This fits into the broader trend that the public cloud has sped up application development. One way to think about this is the ability to cook food without having to grow the ingredients first.
However, the teams in these worlds look very different. In the pre-cloud world, a company would need a sizeable IT team to maintain the infrastructure. However, in the cloud world, many times, companies don’t even have their own infrastructure until they are at a substantial scale, like Dropbox or Netflix. The IT team manages laptops, routers, etc. that enable a developer to access the cloud.
So, what happened to the infrastructure/datacenter manager? Well… it’s been outsourced to cloud providers like AWS, Azure, and GCP. Of course, with anything that’s outsourced, you need someone to “interface” with them. Enter TechOps! TechOps, also known as site reliability engineers (SREs), is the transformation of the traditional systems administrator. A good way to think about an SRE is a developer who is tasked with managing infrastructure and operations. For example, what happens when an infrastructure issue, such as a network issue, occurs? There’s no “system” because development is so deeply tied into the cloud infrastructure. A developer has to go and fix the problem. The “who” and “how” of operations and infrastructure management is very different in a cloud-native company. More specifically, the public cloud has re-defined the system administrator! Security should be no different, yet it feels the same.
This gets us back to the reason I started these series of newsletters — public cloud has fundamentally changed security. I believe we haven’t figured how security should be done. Here are some open questions I hope to explore in future newsletters:
Do security operation centers (SOCs) still make sense?
How do we do incident response in a cloud world? What is the persona doing incident response?
What is important in public cloud security given it’s more session-based? It seems the concept of a perimeter needs to evolve and change.
What kind of security products should we expect from cloud providers? How do we manage security in a multi-cloud world?
What does prevention look like? How much should it be emphasized?
Honestly, I have yet to see a good solution for the public cloud outside of Redlock and the container security companies. However, they are the first wave and doing only the basics of public cloud security.
Hopefully, I’ve convinced people that we need to re-think what security means in the cloud-native and public cloud world. I hope to answer some of the questions above, but with all answers, more questions will emerge.
TWEET OF THE WEEK
How can I be helpful?
