James Nguyen

The hidden cost and technical debt of running huge Serverless service on production

• Tech is constraint by vendors. Node version is only available when AWS supports them. Meaning certain features can only be used if the vendor allows. Services will be superseded with a better version of its own requiring business to migrate for better performance/maintenance (AWS SWF < AWS SF). Also, Cloud Service developers must also stay up to date with service updates from the vendor. Rarely but possible that one service may deprecate its API and not acknowledging that would cause interruptions.
• Managed services are not always 100% managed. Production database still requires capacity revision, to estimate the required capacity. Database provision and load balancing despite automated provision, still require capacity calibration to choose the relevant config. Choosing bigger DB instance could be overkill for low traffic while too small instance / no load balancing could not serve high traffic. Multi-region is made easier by Multi-AZ but still, the delay in data replication is still considerable.
• Vendor lock-in and exclusivity: It is not easy to have a multi-vendor setup. Despite the fact that it is achievable with Serverless framework, it is only achievable to a certain extent. For big application that require many use cases: API, Analytic, Log processing, IoT, Workflow automation, Queueing, Cold storage, hot storage etc, it is trivial that one would choose a single vendor that support all use cases. After all, internal support and linking between one vendor's services are much more convenient than the flexibility of multi-vendor. On the cost side, consolidating services to fewer vendors makes it easier to reach volume discounts.