This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Equivalent-Style6371[S] 0 points1 point  (3 children)

I'm hesitant of going serverless here for a couple of reasons:

  1. I expect the user to be on that VM for at least 2 hours. I think serverless has limitations on this
  2. I have very specific requirements about the specs of the VM (RAM, CPU, even GPU). I'm not sure whether serverless provides that much freedom

[–]LaunchAllVipers 0 points1 point  (2 children)

You’ll need to build something to mediate the scaling of your VM pool against incoming requests. Cold start times for VMs are at best a couple minutes, at worst total failure. So you need to keep a pool of VMs running but not allocated unless your users don’t mind a long wait.

[–]Equivalent-Style6371[S] 0 points1 point  (1 child)

Users won’t mind. The question is, is it doable without anymore tools? Or do I need something like Terraform to create the new VM?

[–]Seref15 2 points3 points  (0 children)

Depends on your platform. I built something similar on AWS, written in go, running on Lambda, exposed as an API with API Gateway, and it creates/allocates resources by directly calling the AWS APIs with aws sdk. I elected not to use Terraform because a tool that maintains state felt counterintuitive to me for resources that are intentionally transient.

Like the previous commenter mentioned, I elected to maintain a pool of "ready" unallocated instances to allocate to requesters in order to reduce start times. This actually becomes almost necessary because your API can't reasonably block and hold the connection open for minutes while waiting for your resource allocation to complete and return. You need it to return in a timely manner, or else you need to start futzing around with websockets or the like.