X
Business

Serverless: applications only when you need them - no more, no less

Serverless takes cloud to the next level. But the security equation changes.
Written by Joe McKendrick, Contributing Writer

The sharing economy has delivered dominant business models that have swept through a number of industries, such as taxi services and hotel accommodations, providing these items on a short-term, temporary basis. It's fitting, then, that IT services also are seeing their own version of a "sharing economy" business model, with applications and systems also delivered on a short-term, temporary basis -- the essence of serverless computing. 

clouds-over-lake-galena-dam-bucks-county-pa-by-joe-mckendrick.jpg
Photo: Joe McKendrick

To better understand the implications of serverless computing for today's enterprise architecture, we heard from Marc Feghali, co-founder and VP of product management for Attivo Networks.

Q: How does a serverless architecture differ from a traditional IT architecture -- whether on-premises or already cloud-based?

Feghali: Traditional IT architectures use a server infrastructure, whether on-premises or cloud-based, that requires managing the systems and services required for an application to function. The application must always be running, and the organization must spin up other instances of the application to handle more load which tends to be resource-intensive. Serverless architecture focuses instead on having the infrastructure provided by a third party, with the organization only providing the code for the applications broken down into functions that are hosted by the third party. This allows the application to scale based on function usage and is more cost-effective since the third-party charges for how often the application uses the function, instead of having the application running all the time. 

Q: How should the existing or legacy architecture be phased out? Is it an instant cut over, or do you recommend a more gradual migration?

There are specific use cases that will still require existing legacy architecture, but where practical a serverless infrastructure can provide capabilities for those that don't. Serverless computing is constrained by performance requirements, resource limits, and security concerns, but excels at reducing costs for compute. That being said, where feasible, one should gradually migrate over to serverless infrastructure to make sure it can handle the application requirements before phasing out the legacy infrastructure. 

Q: What kinds of services and solutions should managers and professionals turn to build and support their serverless architecture?

There are many solutions that are available to offer dynamic provisioning and on demand service to applications. The one however that every organization must factor in is security. With the new service or solution, security frameworks need to be evaluated to see what new gaps and risks will present themselves. They will then need to reassess their controls and processes to refine them to address these new risk models.

Q: How do security protocols and processes differ in a serverless environment?

Application owners focus on securing the application layer, code, dependencies, configurations and any cloud resources their application requires to run properly. However, their attack surface is much larger as attackers can leverage every component of the application as an entry point. There is no OS to worry about securing, but there is no way to install endpoint- or network-level detection solutions such as AV or IDS/IPS. This lack of visibility allows attackers to remain undetected as they leverage vulnerable functions for their attacks, whether to steal data or compromise certificates, keys, and credentials to access the organization. This lack of visibility and control has steered organizations adopting this technology towards also adopting deception technologies as a way understand when security controls are not working as they should, detect attacks that have by-passed them, and for notification of policy violations by insiders, suppliers, or external threat actors. 

Editorial standards