GDPR and IT Systems — Technical Preparation for the Regulation

Serverless promises a world without servers — you pay only for actual compute time, no infrastructure management, automatic scaling to infinity. In 2018, we have two dominant platforms: AWS Lambda and Azure Functions. After a year of production operation on both, we share our experiences.

What serverless is and what it isn’t¶

Serverless doesn’t mean servers don’t exist — it means you don’t manage them. The provider manages the infrastructure, you supply code in the form of functions. Each function processes one event — HTTP request, queue message, database change.

Serverless isn’t suitable for everything. Long-running processes, WebSocket connections, or applications requiring consistent low latency are better candidates for containers. Serverless excels at event-driven workloads with unpredictable traffic.

AWS Lambda — the serverless veteran¶

AWS Lambda started the serverless revolution in 2014. In 2018, it offers:

• Runtime: Node.js 8.10, Python 3.6, Java 8, Go 1.x, C# (.NET Core 2.0)
• Memory: 128 MB – 3 GB (CPU scales proportionally)
• Timeout: max 5 minutes (sufficient for most use cases)
• Integration: API Gateway, S3, DynamoDB, SQS, SNS, Kinesis, Step Functions

Lambda’s biggest advantage is the ecosystem. Every AWS service can trigger a Lambda function. Step Functions enable orchestration of complex workflows. SAM (Serverless Application Model) simplifies deployment.

Azure Functions — Microsoft in the serverless game¶

Azure Functions entered the market in 2016 and are quickly catching up:

• Runtime: C#, JavaScript, F#, Java (preview), Python (experimental)
• Durable Functions: stateful orchestration — Lambda doesn’t have this natively
• Binding model: declarative input/output bindings save boilerplate code
• Hybrid: Azure Functions runtime also runs on-premise (Kubernetes)

// Azure Functions — Durable orchestration
[FunctionName("OrderProcessing")]
public static async Task RunOrchestrator(
    [OrchestrationTrigger] DurableOrchestrationContext ctx)
{
    var order = ctx.GetInput<Order>();
    await ctx.CallActivityAsync("ValidateOrder", order);
    await ctx.CallActivityAsync("ChargePayment", order);
    await ctx.CallActivityAsync("ShipOrder", order);
    await ctx.CallActivityAsync("SendConfirmation", order);
}

Cold start — the elephant in the room¶

Cold start is the main pain point of serverless. When a function hasn’t been invoked for a while, the provider must start a new container. We measured:

• AWS Lambda (Node.js): 150–400 ms cold start
• AWS Lambda (Java): 3–8 seconds (JVM startup)
• Azure Functions (C#): 500 ms – 2 s (Consumption plan)
• Azure Functions (C#): ~0 ms (Premium plan — pre-warmed instances)

For API endpoints where users wait for responses, cold start is a problem. Solutions: warm-up pinging (CloudWatch scheduled events calling the function every 5 minutes) or switching to provisioned concurrency (Lambda) / Premium plan (Azure).

Pricing — actual costs¶

Both providers charge per-invocation + per-GB-second:

• AWS Lambda: $0.20 / million invocations + $0.00001667 / GB-s
• Azure Functions: $0.20 / million invocations + $0.000016 / GB-s
• Free tier: both offer 1M invocations + 400K GB-s monthly for free

For low to medium traffic, serverless is dramatically cheaper than EC2/VM instances. Our API backend processing 2M requests monthly costs $12/month on Lambda. An equivalent EC2 instance would cost ~$50/month.

Watch out for high-throughput scenarios — at 100M+ invocations monthly, serverless starts becoming more expensive than dedicated containers.

Monitoring and debugging¶

Serverless changes how you debug applications. You don’t have SSH access to servers, you don’t have local logs. You need:

• Distributed tracing: AWS X-Ray, Azure Application Insights
• Structured logging: JSON logs with correlation ID to track requests across multiple functions
• Alerting: CloudWatch Alarms / Azure Monitor on error rate, duration, throttling

Vendor lock-in — a real risk?¶

Serverless Framework (serverless.com) abstracts provider-specific details and enables deployment to AWS, Azure, and GCP. In practice, however, most of the value of serverless comes from provider-specific integrations (API Gateway + Lambda, Event Grid + Functions). Portability is therefore more theoretical.

We recommend: write business logic as pure functions without dependencies on provider SDKs. The handler (entry point) is a thin layer you can replace. Core logic remains portable.

Serverless is production-ready — with caveats¶

For event-driven workloads, API backends with variable traffic, and data processing pipelines, serverless is an excellent choice in 2018. Avoid it for latency-sensitive applications and long-running processes. AWS Lambda has a broader ecosystem, Azure Functions offers better developer experience for .NET teams. The choice depends on your existing cloud provider.