1. 10
  1.  

  2. 3

    deno and fly are fantastic, but lambda can also be exceptionally easy. the ideal lambda zip contains two files:

    • main (go binary, or other pl single binary)
    • index.html.gz (webapp with inlined js)

    example: https://github.com/nathants/aws-gocljs

    automation: https://github.com/nathants/libaws

    container lambdas, or containers on fly, are also fine, just make them small. cold starts are way worse with massive containers.

    fly and deno have some very cool advantages being at edge. their egress pricing is identical to aws though.

    cloudflare workers + r2 is an interesting target, free egress!

    the nice thing about using aws is you get the rest of it: ec2, s3, sqs. moving to edge is a fair trade to give up those things, depending.

    personally i’m sticking with aws and moving egress heavy components to cloudflare. keeping a close eye on deno and fly, they are just so cool!

    1. 1

      Inlined JS probably means you need a lax CSP which isn’t a great idea

      1. 2

        thanks for bringing up csp!

        i’ve updated the build so inlined js gets hashed and added to csp. i should have been doing this all along. smh.

        https://github.com/nathants/aws-gocljs/commit/125196626dbb237c180d4d587bf51261d9a75746

        https://gocljs.nathants.com/

        1. 1

          it probably depends on the threat model.

          the model i’m most interested in is where the infrastructure is untrusted. the client manages all secrets. this means a different provider needs to serve the html with inlined js, as it would be trivial for the first provider to change and own.

          then we need to hash the html with inlined js, and verify that easily somehow. ideally saving it offline, and updating purposefully.

          would csp be of benefit in this model? i’m honestly not sure.

        2. 1

          When Lambda was new I shied away due to the pricing. We had a workload that was not so easily predictable and it wasn’t some core thing that directly benefitted from lambda so in the end we ran with a normal VM and 4 processes on it. Quick enough and the 10 or 20 bucks per months were negligible. (it was a workload that was potentially running 24/7 with breaks).

          Ever since it’s been a bit of a solution in search of a problem - especially with state. (Do I really want to connect to a DB from lambda?) But yeah, these things I mentioned would probably run just as well on Lambda - the IP tool more so. Rare, quick requests. On the other hand if it’s on the internet someone might find it’s a cool idea to hit it once per second on hundreds of machines and then I have my weird AWS bill.

          1. 1

            my favorite use cases for lambda are:

            • scale to zero for low/sporadic traffic services. their cost approaches zero.

            • cron scheduled tasks managing ec2 and other aws infra. lambda will always be the most reliable part of your stack. things like autoscaling groups and cloudformation pale in comparison to lambda with an aws sdk.

        3. 2

          They tell you to run flyctl deploy but for some reason insist on building the image from your Dockerfile themselves (but on your local machine)

          They don’t build in on your local machine, but rather in a temporary VM on their servers. You don’t even need docker installed locally.

          1. 1

            The docs say “if you have Docker installed it builds locally, if not then they’ll take over” and this seemed to be the case.

          2. 1

            I totally feel your “pain” regarding fly.io’s “Deploy with Dockerfile” use case and the rare documentation. Still I am quite sold to the ease of use after wrapping your head around the docs. I have a rust backend application with postgres and this fully runs in fly.io. For DB migrations I especially like the deploy.release_command (https://fly.io/docs/reference/configuration/#run-one-off-commands-before-releasing-a-deployment).

            1. 2

              Nice tip, thanks. I hadn’t seen that but I actually didn’t look into anything I didn’t need yet.

              Also currently I’m wondering if the buildpacks are actually worth learning (and then relying on them to never break or not upgrade anything weird) if you know how to use a Dockerfile and deploy your app (say, written in Go) with a distroless container where you control 100% of everything. Maybe it’s down to convenience for people who have not used Docker for years…

              1. 1

                For now, I stick with a Dockerfile, but idk what you mean by a „distroless container“? I build the image with gitlab-ci and directly push it to the fly container registry. I tried multiple times to build (remotely) using flys builders but it somehow always hung while setting up the docker remote context. Not sure about the buildpack thingy for now. Open for advice though ;)

                1. 3

                  Distroless would either use a FROM scratch final stage, or something like https://github.com/GoogleContainerTools/distroless

                  1. 2

                    If you have a static binary (most often Go) without dependencies you can usually run it in a very stripped down container that doesn’t really contain an OS, like, say a Debian base image. https://github.com/GoogleContainerTools/distroless is one but I don’t think they invented this.