Serverless promises and the persistent need for critical alerting

Why serverless computing doesn’t end the need for security or alerts

Serverless computing provides the advantage of taking away the problem of managing servers. For many small start-ups, this is a huge advantage as the cost of purchasing, maintaining and scaling servers is a real pain point. Serverless also holds forth the prospect of ending the need for Ops as we know it, ending the need for security worries and ending the need for being on-call. But, while this modern-day DevOps marvel known as serverless might seem like a panacea, serverless computing needs to come with a healthy dose of reality.

The reality of serverless

In an article I recently posted to DZone entitled How Smart Is Serverless, I question how smart it is to outsource your security concerns to a third party like AWS. As I note in the article, you cannot abstract security without facing some pretty scary consequences. Amichai Shulman, CTO of Imperva, says this best when he notes:

“[B]usinesses act on the misconception that when they put data into the cloud they somehow transfer responsibility and liability to the cloud provider, and this is simply not true.”

While AWS guarantees the physical framework of the information on its property, it doesn’t provide security for anything beyond it. That means all the information in transit is not protected. And there is no provisioning to make sure that you don’t store security or other sensitive information into your code that could be seen in transit.

Furthermore, the servers used by AWS can and have been hacked. CodeSpaces and Ashley-Madison are real examples. The larger a target becomes the more enticing they become to hackers, whether the target is on AWS or on their own servers.

So by embracing serverless and thinking you are entering a NoOps fairy tale world, you still need to have Ops or a Dev team member trained in Ops to run scripts against the software, test for security and (importantly) monitor the logs. Charity Majors writes it best when she notes:

“I’ve seen what happens when application developers think they don’t have to care about the skills associated with operations engineering. When they forget that no matter how pretty the abstractions are, you’re still dealing with dusty old concepts like “persistent state” and “queries” and “unavailability” and so forth, or when they literally just think they can throw money at a service to make it go faster because that’s totally how services work.”

Clearly, doing away with Ops and jumping headfirst into serverless because you think you can avoid all those components of operations you don’t enjoy, is lunacy. Worse, it leads to really bad outcomes.

Critical alerting won’t go away

Dev in a serverless world still requires concern for deployment, security, networking, debugging, monitoring and system scaling. According to Mike Roberts who writes on Martin Fowler’s website, “These problems all still exist with Serverless apps and you’re still going to need a strategy to deal with them.“ As such, you still need critical alerting platforms to sit on your logs coming out of AWS or other serverless providers to notify you how things are going and when they are heading south.

OnPage’s incident alerting platform is ideal for this purpose as it alerts based on emails so anything that can send an email can integrate with the OnPage platform. OnPage will notify for events such as failed deployment, security issues or unusual traffic patterns. By integrating OnPage with log tools such as Logz.io which will monitor your logs for incidents you identify, you can:

• Create persistent alerts that last for up to 8 hours, ensuring you never miss a critical alert
• Tailor alert settings for high-priority messaging (think DNS attacks) as well as for low priority, casual messaging. If an alert is a 401 error, you can set it as a low priority alert so you don’t need to wake up for it in the middle of the night
• Include information on the alert specific to the log error so that information arrives with context
• Send messages between OnPage IDs. That is, one person with the app can send a message to another person with the app
• Enable global coverage so your teams down the block or across the globe can be notified

Conclusion

So while serverless has many advantages that will help start-ups such as providing significant cost savings or reduce Ops as well as the use of servers, companies should be careful to fully understand the hazards they face by moving to serverless. Critical alerting has been and will be a feature that Devs will need whether they have zero servers in house or a 100.

Read our blog on NoOps and critical alerting.