4 ms·
What are some of the pitfalls of this approach over the regular 24/7 Apache/Nginx server approach?
by phantom_oracle 11y ago
What are some of the pitfalls of this approach over the regular 24/7 Apache/Nginx server approach?
- Eridrus 11y agoThis is not from first hand knowledge, so it may be wrong, but my understanding of the downsides: Tooling sort of sucks; this helps python, but deploying other Lambda apps is not very nice. I have no idea how you debug these services either, which is related to the fact that... You have no access to the underlying host, so you can't install software, configure the kernel, etc Startup latency can be up to 10s, so they recommend having a scheduled task that keeps your servers warmed up, which will reduce your cost savings by having some parts always-on, but you'll still run into the startup latency when you run out of capacity on your existing lambda VMs. You will need to architect your app differently for lambda vs normal servers, e.g. lamba has an enforced maximum run time, but also where your data lives; keeping local databases for things like MaxMind isn't an option any more, you'll need to access all of your long lived data from other servers and have a cache. So, unless you actually need the fast scaling capability (10s vs 10m) or you need autoscaling, but don't want to build it yourself, the only potential reason to use this is cost, and at the low end it's not much in savings (I pay $16/month for a few small servers 24/7 in AWS) and will cost you more in your own time.