Leaving serverless led to performance improvement and a simplified architecture (unkey.com)

Article summary

The company Unkey switched from a serverless architecture using Cloudflare Workers to a stateful Go server architecture, resulting in a 6x performance improvement and a simplified architecture. The serverless approach had limitations, including caching issues and the need for multiple auxiliary services, which led to complexity and latency problems. The new architecture allows for self-hosting, platform independence, and improved developer experience. The company plans to launch its own deployment platform, Unkey Deploy, to enable customers to run Unkey anywhere they want.

Main themes

• Serverless architecture
• Performance optimization
• Cloud computing
• Architecture migration
• Stateful vs stateless
• Cloudflare Workers

What commenters say

• Serverless architecture is not suitable for applications that require low latency and high throughput due to its inherent limitations.
• The choice between serverless and traditional architecture depends on the specific use case and requirements, with serverless being more suitable for infrequent workloads and simple request/response patterns.
• Serverless architecture can lead to increased complexity and cost due to the need for auxiliary services and workarounds, which can outweigh its benefits.
• The use of containers can provide a middle ground between serverless and traditional architecture, offering more control and flexibility while still providing some of the benefits of serverless.
• The decision to use serverless or traditional architecture should be based on the specific needs of the application and the trade-offs between complexity, cost, and performance.
• Some commenters argue that serverless is not inherently more complex than traditional architecture, but rather it is the implementation and choice of services that can lead to complexity.
• Others argue that serverless can be a good choice for connecting cloud services to each other, but it may not be the best choice for API services or entry points.
• The importance of considering the cold start problem and latency when choosing between serverless and traditional architecture is highlighted by some commenters.