Watch the video below or listen to the audio on SoundCloud.
For this episode, Hillel and Tal from Protego were joined by Ben Kehoe, a cloud robotics research scientist at iRobot and an AWS Serverless Hero.
Ben explained, “iRobot, we’ve been making the Roomba since 2002. In 2015, we launched our first connected Roomba. We had a business that was at scale making devices, so we had to have a cloud application for connected devices that would easily scale up to our business scale and keep the risk of that as low as possible. In my opinion, serverless enabled us to essentially leapfrog the scalable cloud technology learning that we would have needed if we went with a traditional architecture. Instead, we’re using fully-managed services from AWS that allow us to focus on providing features to our customers rather than focusing on the scalability of the technologies that we’re using. That’s being handled all by the service provider.”
When asked to elaborate on benefits iRobot has experienced, Ben elaborated, “I feel that it has kept us extremely lean in our cloud teams for both development and operations because we’re essentially primarily writing business logic rather than having to solve technology problems before we can get to our business problems. That’s given us faster time to market, more agile teams, and the challenge is that we’ve been doing serverless since it was very nascent, and so we’re very familiar with all of the rough edges that weren’t solved and have been solved in the past couple years, and all the ones that are still not solved. We’ve found that, despite the challenges inherent in going all-in on serverless, it’s completely worth it.”
The group next discussed recent headlines, including general availability of Azure Functions 2.0, and an announcement from SAP about their cloud platform functions. Hillel asked, “How relevant of these other cloud providers? Do they solve a need that is missing? Is there a reason why some organizations leveraging AWS solutions such as Lambda and Dynamo would move over or augment their tech stack with other cloud platforms?”
Ben replied, “I think for heavy, advanced users of AWS there aren’t many reasons to use basic building blocks from other providers like Functions, like a NoSQL database from a different provider other than AWS. For advanced, very high-level and very specialized services, I think that can sometimes be more compelling. But I think, in general, especially with more enterprise-oriented companies like SAP, providing functions as-a-service offerings that can integrate with their platforms, there are a lot of companies that are out there using SAP for one thing or another. The ability to expand on that or to script capabilities that customers are interested in achieving. You enable those customers to accomplish that with a minimum of fuss in a sort of self-service way. I think that can be really powerful for those users of those technologies. Then for all the big providers, it’s in their interest for their companies that are moving into the cloud and selecting providers for a whole host of things. At that point, it is useful to compete with AWS on that front. They’re only worse off if they don’t have serverless offerings.”
Hillel elaborated, “Some of the AWS direct competitors, Azure and Google, can take steps to make sure they have offerings for their customers and move people to use their technologies, but you’re also pointing out that some of these other platforms like SAP, which maybe have a more specialized purpose for their customers are also figuring out how functions are an important part of what they do for their customers and how people want to evolve the way they write workloads, even on top of these more specialized cloud platforms, right?”
Ben stated, “It’s probably possible to use Lambda against an SAP API, but it’s going to be much more complicated for the average business to do that than to write something inside the SAP ecosystem.”
Hillel asked, “Was there anything new there or is this really kind of business as usual when it comes to security with Azure?”
Tal added, “Actually, I haven’t seen any major changes in Azure 2.0. Definitely we’re going to hear about SAP security for their functions. Different people are going to investigate that as well as we do. Let’s see what they came up with.”
Hillel said, “Let’s switch gears to cost savings, my favorite topic to not talk about. A couple headlines I saw recently, one from a company, a startup, Cloud Forecast, which is doing some really cool work about how they, as a startup, leveraged using Lambda to save a lot of money. At the same time, there was an article from IBM that talked more about cost savings and larger enterprises using the cloud and using functions rather than containers or VMs. Ben, is cost savings a big factor to a company like iRobot?”
Ben explained, “Cost is definitely a very important factor in our cloud solutions because our current cloud functionality doesn’t require a subscription. When you buy a Roomba, you pay us once for it, and then we pay the cloud cost for the lifetime of the device, which means that I like to joke that the better the mechanical and electrical engineers do their jobs and the longer the robot lasts, the more the cloud folks cost the company.
“We’re definitely very sensitive to that. At the same time, we look at the total cost of ownership for the cloud. It’s not just what is our AWS bill in a given month? We look at how many operations FTE does it require? How much maintenance is it? All of those factors to figure out the true cost rather than just looking at one number, because there are ways in which Lambda is more expensive per compute cycle than EC2, but if it requires three times the amount of people on operations, that cost has to be figured in.”
Hillel added, “I think we’ve seen a lot of companies who maybe even got in initially thinking, ‘I can save some compute bill,’ but really found that the big savings were in the operations people as well as the velocity they could achieve. They could move faster, do more with less development resources, and also have fewer operations people. I agree that you have to definitely look at the TCO and not just the cost savings of compute. There are probably plenty of use cases where your cloud bill might go up, but you’re still better off making that move.”
Ben added, “It definitely depends on, if you have a legacy system, how good you are at utilization. If you’re really, really good at it, your cost may go up when you switch to serverless. Most people aren’t that good at it, and it’s not really in your interest to get good at it. You should just switch to serverless and make being good at utilization somebody else’s problem.”
Tal added, “Actually, security is also something that you should calculate the cost for. Look at it that way. If you can just, as Ben said, you can just write up business logic and don’t deal with all the security around it, so operation systems and patches and updates and security controls, then you save a lot of money, also, on that. You can put your money into writing a cool application that deals with security and pay less for security. Also, for security operations, I think there is a change in terms of if before what we knew before serverless and cloud, the security people just had their niche of taking care of all the security for the environment. Here, for serverless, it’s more code-driven, so there are things that you should take care of when you move to serverless.”
Tal continued, “In terms of the security advantages, security is microservices, if we call it that, allows you to actually get the understanding of what each code or each function should do or each resource’s task in the whole ecosystem, and then build your defenses around it. If you know that it’s much easier to understand a specific function has to just write to a certain table or just download from a certain storage, you can literally limit that both in permissions and in your code only to that, so that can really refine your security in serverless.
“I’ve just been to The Serverless PDX conference, and I met some guys who were founding startups and they went all-in from the beginning with serverless. I also know of other security solutions built in serverless. People believe in the security of serverless.”
Ben mentioned, “AWS released a very important update to IAM called ‘Permission Boundaries.’ Previously, when you gave a developer permissions to create a Lambda that involved creating IAM rules and policies associated with them, there was no way to restrict the policies that they could create. Therefore, you essentially gave them sort of pseudo-permissions inside the AWS account where they were developing that Lambda, which was a big problem. You couldn’t really restrict what they could do with that Lambda. With permission boundaries, you’re able to put limits on what they can and sort of what IAM permissions they can give to things that they create.
Hillel said, “One of the early features of Protego was the ability to not just detect where your IAM configurations were suboptimal would tell you, “Hey, here’s the policy statement. Go put it in the right place and you’ll be optimal.” But we actually had this flow where you could just click on a button and it would go manage all those permissions for you, but the big challenge was you had to give us all or nothing on IAM management, which was this huge ask. You really had to put a lot of trust in a small startup.
“Whereas permission boundaries are now letting us redeploy that feature in a way where we can scope down much more carefully, ‘Hey, what can we manage?’ We can enable a situation where we are able to, on your account, manage a set of roles that we create and assign them to functions, but we have no ability to touch any of the other roles in your account or suddenly give some user crazy permissions they’re not supposed to have or things like that. You can also use permission boundaries to scope down what we can give to a function. You can say, ‘How do I make sure that Protego can manage all these roles for me, but there’s no accidental way where they give some permissions I really don’t want out there to my functions?’ It’s been a really great feature for us.”
Tal stated, “I gave a talk about serverless security at the Serverless PDX Conference. It was very nice to see so many people interested in the new technology and all the talks were great at covering a variety of aspects. How you integrate that in a company and how you do more visualization in your accounts and other great talks. I think the security was a good finale because I was last, so it was a good finale.
Hillel said, “I was recently at OWASP AppSec Conference in Israel, which is not a serverless conference. I spoke about serverless security, but I was really happy to see that I was not the only one talking about serverless, so I think that’s a good indication that people who are in the application development space or the AppSec space and looking for solutions are interested in serverless, which means we see serverless creeping into the mindset of a lot of organizations.”
On October 30th, Ben will be speaking at Serverless NYC, then at re:Invent.
At the Rochester Security Summit, Tal will be speaking on the OS security track about serverless security and OWASP top 10, which is a new project that tries to get information from the world, from companies, from the industry about what are the 10 most critical security issues in serverless and how to mitigate them. We just launched the first post talking about the first event of the top 10.
The only reason that kubernetes seems to have more traction than serverless is that it’s harder, so there is more money to be made for consultants.
— Paul Johnston (@PaulDJohnston) October 2, 2018
Hillel liked Paul Johnston’s tweet and stated, “I’m always good for a little snarky, funny dig at containers and Kubernetes, but maybe also highlighting an issue. I don’t know. What do you think, Ben?”
Ben replied, “I think it’s hyperbole. I think that there is a lot of snark in the serverless community about Kubernetes, and I am definitely guilty of that, but I think when we’re serious and we’re talking thoughtfully, the same people who do snark about it will tell you that there is a place for Kubernetes and it’s for people who are building technology as a product. The people using technology to deliver some other features to their clients that aren’t fundamentally in the technology business are going to want to be serverless in the long term and that running Kubernetes is not generally going to be of value to them. But somewhere down in the stack, someone is going to be managing servers, and they are probably going to be using Kubernetes.”
Use a service whenever possible because services are almost always cheaper than people
— Paul Johnston (@PaulDJohnston) September 27, 2018
Ben also liked a Paul Johnston tweet, and said, “This goes to the notion, well, a couple of things, which is one, always keeping your eye on the total cost of ownership and not getting distracted by subcomponents, cost of one thing versus the other, and secondly, the fact that people, in general, undervalue their own time. They often look at, ‘If I do this, I can create something that costs less.’ But they don’t consider how much of their time is being spent and the opportunity cost of that when they could be creating business value instead of working on a technology problem. That fundamentally, the freeing up time and resources to focus on your business problems is really what serverless is all about, rather than any particular technology or architecture.
— John Demian (@JohnDemian) September 9, 2018
Tal chose a funny tweet by Jon Demian and Hillel quipped, “Is this going to cue up another war about there really are servers? Where are the servers? I’m a little nervous now.”
Ben replied, “It’s ironic, right, because Lambda runs a giant fleet of servers. I am thankful that they do because it means that I don’t have to.”