VuiLenDi

Conceptual Overview

Serverless Function

Serverless functions are designed to focus on Event-driven architecture with auto-scaling capabilities. Users don’t need to care about the server because they’re abstracted server management. 

Edge Function

Edge functions are serverless computing that enables organizations to run code at the network’s Edge, closer to the end-users. Edge functions are designed for low latency based on geography-specific processing.

Core Differences

• Serverless functions run on cloud-based infrastructures, but Edge functions allow data processing and analysis to happen where the data is generated.
• Edge functions claim lower latency and improved performance compared to traditional Serverless functions.
• Serverless functions automatically scale up and down, but Edge functions need manual intervention.
• In Serverless functions, cold start boot times average from 50-500ms, but in Edge functions, cold start average from 50-200ms.

Technical Deployment

Serverless Function Deployment

Typically, Serverless functions deploy from a Git repository into an environment that can scale up or down as needed. When no one accesses a serverless function endpoint, a function or endpoint should consume no resources. That means Serverless functions can effectively “scale to zero.”

Most cloud providers have serverless computing, such as AWS Lambda, Azure Functions, and GCP Cloud Functions. These serverless functions integrate strictly with their cloud services, so it is hard to mix these functions. Besides that, we can use CI/CD and versioning workflow to manage Serverless Functions.

Edge Function Deployment

Edge functions deploy at “the edge,” so they’re closer to visitor sites around the globe. There’s a general process for deploying Edge functions:

• Create an Edge function: Write a Javascript or TypeScript and store it in your Edge functions directory. Using TypeScipt and JavaScript, you can modify network requests to localize content, serve relevant ads, authenticate visitors, A/B test content, and much more.
• Test locally: We can use CLI to test edge functions locally before deploying them to providers. For example, we can use Netlify CLI to test edge functions locally.
• Deploy: We can use the CD process or CLI to deploy your edge functions, such as Netlify CLI, to deploy your edge functions.
• Invoke and Monitor: After deploying your code, you can invoke and monitor your edge functions.

Serverless Functions Use Cases

• Auto-scaling websites and APIs
• Event Streaming
• Image and Video Manipulation
• Processing Events and SaaS
• Hybrid Cloud Applications
• Multi-language Applications
• Continuous Integration and Continous Deployment (CI/CD)

Edge Functions Use Cases

• A/B Testing
• Geolocation: Redirect
• Virtual Waiting Room (Queue-it Integration)
• Data Protection and Privacy Compliance
• Dynamic Website Personalization
• Traffic Manager: Allowlist
• Device-Based Personalization
• Search Autocomplete

Security and Compliance

The 12 Most Critical Risks for Serverless Applications

• SAS-1: Function Event Data Injection
• SAS-2: Broken Authentication
• SAS-3: Insecure Serverless Deployment Configuration
• SAS-4: Over-Privileged Function Permissions & Roles
• SAS-5: Inadequate Function Monitoring and Logging
• SAS-6: Insecure Third-Party Dependencies
• SAS-7: Insecure Application Secrets Storage
• SAS-8: Denial of Service & Financial Resource Exhaustion
• SAS-9: Serverless Business Logic Manipulation
• SAS-10: Improper Exception Handling and Verbose Error Messages
• SAS-11: Obsolete Functions, Cloud Resources, and Event Triggers
• SAS-12: Cross-Execution Data Persistency

(Refer: The 12 Most Critical Risks for Serverless Applications | CSA (cloudsecurityalliance.org))

Download: The 12 Most Critical Risks for Serverless Applications 2019

Edge Functions Security Considerations

As you know, the edge function processes data at “the edge,” so we must consider data residency and privacy laws. Besides that, as the network security layer, we must consider TLS and secure connections at the Edge. However, the Edge functions can help us mitigate the Distributed Denial of Service (DDoS) attack.

When implementing the Edge functions, we have some security considerations:

• Custom Authentication: We must sign requests to custom origins that enforce access control or configure viewer token authentication.
• Bot Detection: Some Edge function providers, such as Lambda@Edge, provide us the logic to detect bot access that helps our site improve the security of content delivery.
• Security Headers: Adding HTTP Strict Transport Security (HSTS) or Content Security Policy (CSP) headers can help us so much to enhance security.
• Origin Independence: Managing the authentication and authorization for origin requests can be crucial for securing access to your content.

Conclusion

The big question is when we should use Serverless functions and when we should use Edge functions. Regardless of your choice, Edge functions are the modern case of Serverless functions that allow developers to choose between scale capabilities or performance. In some of the use cases above, we can understand how to leverage their strengths to implement our applications.