Remember my triumphant declaration of a server for thee but not for me in my second post about the bus app, migrating from Google Firebase to my own hosted instance?

Building a better bus arrival app
Bus App V2! In this installment, we are rewriting the app in Node and React.

Yeah, about that.

I was happily revelling in my newfound power of managing a cheap server:

  1. Monthly fight clubs with bots attempting to overwhelm my SSH port. I see you 124.131.2.1, and I raise you a ban for that whole IPv4 address range.
  2. Trying to remember how I set things up. Wait how did I set up https again?
  3. Updating and maintaining the server. Look at me. I'm the sudo now.

Unfortunately, the last straw came when my preferred cloud provider sent me a nice email informing me that the prices would be raised. Again. For a second time this year.

"What?" I sputtered, grabbing my calculator. "You want to charge me... let's see here... the price of one more cup of coffee a month$^1$?"

Nice email from my cloud provider

Yes Scaleway, why? Digital Ocean and Linode both continue to offer per month pricing at reasonable rates: it was \$5/month three years ago, and it is still \$5/month now. Unfortunately, while Scaleway had the best price + performance on the market when I started out (~\$3/month), the prices have been continually rising each year.

It isn't clear how it prevents spot pricing and reserved instances as well. After all, it is really on how you manage billings. And monthly capping is still relevant to me! I think the subtext is: we're not making enough to continue providing this service, so we are raising the prices, and that is fair enough reason. I just wish they had just put it out there.

So I decided to migrate my applications off a standard server and instead focus on a whole new world of serverless applications! In a way I'm grateful for the push.

For the three of you that are using it, don't worry, it will not affect your usage.


Migration

Migrating the code to Google Cloud Functions turned out to be relatively painless. Because the application was written in NodeJS, and since most serverless offerings can run NodeJS, all I had to do was made some minor tweaks to adapt the code:

  1. Remove app.listen because it is now a function and there is no need to start a server.
  2. Set NodeJS runtime to v10 in order to use async function * used in got.
  3. Make the main application route more explicitly async by adding the async and await keywords when requesting the api.
  4. Change app.get to app.use, converting the function to a piece of middleware.

The great thing about serverless functions is that there is no need to manage the security aspects other than that relating to your application. Since I am using a mostly standard NodeJS runtime, I don't need any strange configuration tweaks that might require control of the server instance. Also, since my application is not called that often, it definitely has a lower cost than running a full server instance.

This was definitely less painful than I expected.

Until I wake up to a \$200 bill$^2$.


[1] This is how developers count costs.

[2] No cloud provider lets you set a hard limit on your spending!

[3] Big Cloud (Like Big Oil) consists of Google, Amazon Web Services (AWS) and Azure (Microsoft). 'Big Cloud' is not a thing but I'm trying to make it a thing.

References

  1. https://stackoverflow.com/questions/15601703/difference-between-app-use-and-app-get-in-express-js
  2. https://stackoverflow.com/questions/60646437/syntaxerror-unexpected-token-when-use-gotnpm-in-firebase-functions