Cyber Security Practitioner Series brought to you by Reverb Advisors
In this week's interview for the Cyber Security Practitioner Series, we talked with Tom McLaughlin from CloudZero about serverless architecture.
Tom talks about what serverless architecture, how it is utilized, the risks it poses as a security issue, and why it is still worth it in the end.
Tom McLaughlin, CloudZero
Tell us about yourself, your background, and how it pertains to serverless architecture.
I’m an operations engineer by profession, which in lay terms translates to, “I make the cloud run.” While software engineers are writing the products that we use, I’m the person who’s been responsible with ensuring that these engineers are able to deliver features and ensuring a stable and reliable service so users (or customers) are able to use those features. Your killer product feature is useless if customers can’t access it reliably.
These days I do developer relations (DevRel) for an early stage startup, CloudZero, that is building a site reliability platform on an AWS serverless architecture. I engage with our market as an engineer peer to discuss the issues we’re solving, like site reliability and serverless, and learn from those engineers how we can solve their problems better. The work is (and I’d argue if it’s going to be done right) should be a mixture of Engineering and Product functions with Marketing strategy and tactics mixed in.
What exactly is serverless architecture and why does it matter?
“Serverless” is currently one of the most nerd-rage inducing terms; in a tie with “observability”. (We’ve grown tired of arguing what “DevOps” is and fortunately new terms have come along.) We call it “serverless” because because the host layer (server) has been abstracted away from us and is entirely handled by the cloud provider. We have no responsibility for host maintenance in this model. The general maintenance tasks we’re used to, e.g. OS patching, performance monitoring, debugging is handled by the cloud provider and opaque to us. This is a good thing because it forces us to focus our effort on technology that advances our core business. More resources can be spent on developing the product features that increase adoption than patching your hosts. No one buys your product because of your internal patch management strategy. They buy your product becuse it does something useful.
What differentiates this from a PaaS is the execution model of the technology. With PaaS platforms you’re paying for hosting and you’re whether people are using your product or not. This is not the case with serverless platforms. With serverless you pay when your service is actually used. A serverless system costs you nothing if no one is using it. Your bill has gone from a capacity based model (paying for resources to support a theoretical load) to a capacity based model (how many people are actually using my service.)
What has adoption been like for serverless architecture?
Serverless adoption is still in the early phase. Think of maybe where containerization (eg. Docker) was 3 or 4 years ago or even AWS public cloud 7 or 8 years ago. Serverless is I think still the domain of the early adopters. I joke that much of the leaders in the serverless ecosystem can all be found at the ServerlessConf events. Think of that, a single event can still draw most of the leaders in that space. I had severe FOMO missing this past one in NYC. My twitter timeline was filled with the people whose twitter and blogs I follow and along with people I regularly engage with on a dedicated serverless Slack group.
The organizations I’ve found to be adopting serverless are quite diverse. They range from large companies like Nordstrom, to sizeable companies like iRobot, and finally early stage startups like CloudZero. Because of the leap serverless provides over microservices (which containerization doesn’t provide) I think you will begin to see many organizations come to a fork in the road as they look to modernize their software stack and IT services delivery; go primarily containerization or go primarily serverless. More aggressive organizations may decide to leapfrog over containerization and directly into serverless. While moving applications to containers may be easier up front than re-architecting them for serverless, containerization comes with the overhead of maintaining container management platforms. AWS provides ElasticBeanstalk where you can host your Docker containers but people will still need platforms like Kubernetes to handle large scale container deployment. Contrast that with serverless where you’re making a conscious decision to offload the platform management to your cloud provider. If you’re no longer trying to operate a containerization platform you can perhaps redirect those engineering resources towards your application re-architecture efforts.
For some people this time may be too early for them to care about serverless. For others this is exactly the right time. The architecture changes bring so many new opportunities and questions that are waiting to be solved.
What potential security risks does this technology pose? Do you feel the rewards outweigh the potential risks? Why?
With every new layer of cloud abstraction you have to ask yourself how comfortable you are with outsourcing a part of your security. There are people who believe they can provide physical security to a data center better than public cloud providers. There are people who believe they can provide better security at the virtualization layer (eg. preventing cross VM or cross container attacks) better than the public cloud providers. The same questions arise for serverless. Underneath AWS Lambda is a container that AWS manages. Do you feel you can keep engineer a more secure container that is patched appropriately better than Amazon? And is your time spent on that a better use of time than addressing other issues? You have to ask yourself these questions and provide realistic answers. Just because you own and control something in no way means you can do it better. I legitimately trust public cloud providers to do a lot of this work better than me. They hire specialists for this work for for me I’m at best a generalist.
If you make the jump to serverless a positive I see coming is increased focus on application layer security. Ask yourself at what maturity a company starts doing application security and pen testing. Ideally they start doing it when they have the time and resources and have addressed other lower hanging fruit and more damaging issues in their environment.
If you’re no longer managing and patching OS vulnerabilities, redirect you time to patching application dependency vulnerabilities. A service like Snyk is I think poised to make a major impact in the serverless space. It’s an easy to use service that for me, as a non-security specialist, can get started with.
If you’re no longer worried about ensuring that your NoSQL platform is properly patched and not exposed to the internet, refocus your efforts on ensuring your AWS S3 buckets aren’t publicly exposed. Or better yet, focus on application pentesting earlier. I would love a service that constantly probed my infrastructure for vulnerabilities. It’s not that I didn’t want it before, it’s that with serverless architecture I now have time to potentially make use of the data the service found.
By allowing your public cloud provider to address more of the security of your stack you can focus on the more sophisticated security issues earlier. This is a good thing for security so long as people recognize the opportunity to fill this new space.
Is there anything that you have not gotten to talk about that you feel is important for people to know?
I just want to reiterate that serverless really is different and represents a major jump in cloud computing compared to what we’ve seen with containers. The architecture is so different from what we’re used to that it’s mass adoption leads to so much potential disruption. You can look at almost every area of cloud technology and given enough thought and time see endless possibility. The shift from capacity to consumption based billing I think will lead to the measurement of cost more closely with how we measure performance. In fact, I think cost will more directly factor into performance choices. We’re still building management tools that are configuration file based, but I can see a trend towards more graphically oriented design. The opportunities are endless in this area if you take the time to rethink ideas instead of just implementing what we’ve been doing. If you’re having a hard time coming up with ideas, I touch on some areas in my presentation “Serverless Ops: What do we do when the server goes away?”