December 29, 2018

Why isn't your website serverless?

Good morning, everyone! I've recently developed quite the passion for serverless applications and websites, and I'm wondering: why is your website still on a server?

You probably don't need it to be on a server, and you could save money if you moved it to an S3 bucket. Do you have any reservations that are holding you back?

I pay about $0.50/mo to $1.00/mo for my website in an S3 bucket compared to when I used to pay $5/mo for mediocre hardware, and now I have perfect pagespeed and checkbot scores -- things I couldn't achieve when I had a web host.

  1. 14

    My websites aren't serverless because I need them to actually do stuff.

    1. 2

      I can't think of anything a serverless website can't long as you are not making the website with any PHP code. API gateways, lambda functions, and relational databases can do everything.

      1. 4

        There's a couple of things servers can do over "serverless" setups:

        1. Have predictable costs

        That's a pretty big one. I've seen (and heard of more) setups done on serverless because it was quick and easy, until it had to scale. Credit cards are not infinitely scalable :)

        1. Be maintainable by individuals

        The whole point of "traditional server" applications is that you get to put all of the logic in one place. Sure, you could technically build out everything you need to run a complex system using a collection of lambda functions, but then try maintaining that with any sort of speed.

        And then a whole bunch of other things, like: Build applications with multiple dependencies that let you build much more capable systems. Module re-use that makes sense. The ability to test offline. The ability to repackage for on-premise deployment. Architectures that don't require you to understand a whole intermediate service layer just to get two bits of logic to communicate.

        Sure, "serverless" is great for functions that do very little (login, create profile, post comment), but is absolutely useless when it comes to complicated business applications where you're dealing with many interfaces, endpoints, API calls, backend integrations, file storage, queued jobs, etc.

        I, too, would build out hobby projects, static sites and simple membership systems using serverless functions if it made sense. But for the vast majority of my work it doesn't.

        1. 3
          1. If you use serverless correctly it is quite cheap.

          2. Serverless is easily maintainable. People are scared of new development processes... that's their problem and will be left in the dust in the coming years.

          I have been running serverless for several enterprise SaaS companies over the past 3.5 years.

          1. 2

            People are scared of new development processes

            Not scared. But learning new things takes time and for those of us who have already functioning websites it is hard to see why we should sink several months of work into learning and porting the existing code for.. which benefits exactly?

            If I would get started in dev right now I would immediately jump on serverless. But if you port your existing projects to new tech all the time you can hardly do anything else.

          2. 2

            Doing IoT, right? Serverless is great for that use case, since everything your devices do will be simple profile updates that need to come in at scale.

            Less so if your workload is converting between proprietary formats or integrating with large ERPs for compliance purposes, which is more of the sort of stuff I do.

            For instance: There is no cloud serverless vendor that will let me meet the security requirements of the IT departments for which I create bespoke data integration products. Or for the procurement departments where pricing information is commercially sensitive. Or financial services companies that handle confidential portfolio information.

            Serverless absolutely has its place, but it's also not the be-all and end-all of network applications.

            1. 1

              Yeah I'm doing small db stuff on serverless and it's great. Some have brought up the idea of storing clinical trial data and patient record data... and I'd have to completely gut my current setup and move to something more HIPAA compliant, I think.

              Could a serverless setup ever be HIPAA compliant? I'm not sure, and there's not a whole lot of info about it anywhere

              1. 1

                Potentially, yes. Ultimately "serverless" is just a short way of saying "we built a shell for your functions and will charge you to run them". Whatever laws, regulations, SLAs and certifications apply to the servers running your "serverless" code should make the regulators happy.

                Chances are you're not going to get that on the public retail side though - you'll probably have to talk to the vendors to get isolated environments set up, like how AWS offers GovCloud.

            2. 1

              I'm doing IoT now. But before that, I was doing data pipelines and processing for utility companies... that does require pretty stringent security requirements and we were able to do that all on AWS.

              But I will cede serverless isn't perfect and it isn't the best tool for all use cases.

        2. 1

          Serverless has predictable costs. It’s called API gateway. You can assign a usage plan to a user account and leverage that in an API gateway authorizer. What this mean is that no lambda functions will be invoked beyond the quota and/or rate limits you define. I’m doing this now and it works great.

  2. 6

    so for $4 you get vendor locked in, risk of getting a huge bill if you get a DDOS attack, worse performance due to cold starts and because you have to open a db connection from every function, have use a centralised logging service, also no idea how to do e2e tests unless you run your local api gateway.

    but you seem to be talking about a static website, for which there are free hosts as netfly.

    1. 3

      Yes, he's describing a static site.

      To your point, there's plenty out there to prevent vendor lock in, $ due to DDOS, and cold starts...

      I personally like to use a combination of Heroku, Digital Ocean, and AWS. Right tool for the job, sort of thing.

    2. 1

      So for less than $4 a month I get to just focus on writing code and not worrying about my infrastructure, I get low latency, hardware that is exactly all that I need at any point in time, I don't pay for idling, I don't have to plan for growth besides the efficiency of my code. Even for a static website, AWS wins with CloudFront for global distribution.

    3. 1

      Vendor lock-in? You can just set it up using serverless.js and move from one vendor to the other pretty easily.

      Huge bills? I think not. I pay a lot less for my use cases using serverless.

      Cold-starts really aren't a problem anymore... you are harping some old MVP serverless issues.

      There is really very little latency connecting to the DB... also Dynamo is just an HTTP request anyway

    4. 0

      You can prevent DDOS impacts to your bill on AWS by using API Gateway Usage plans.

  3. 5

    In short: because I don't care.

    I don't care to learn a new tech for something that works and I don't believe that the price would be lower for me in the end.

    1. -3

      This comment has been voted down. Click to show.

      1. 5

        HTML, CSS and Javascript are all 20+ years old and are doing just fine :)

        New isn't automatically better, nor necessarily useful for all use-cases. While the tools, libraries, frameworks and languages may evolve, the principles are basically all the same - and if you have a good grasp of software development principles, you don't really need to chase after every new hype train.

        No matter how far you think you can go with serverless functions, I can guarantee you that the developers building the intermediate stack on which your functions run, can go even further. That will always be the case when relying on tools that abstract away the difficult stuff.

        1. 1

          False. Cloud Native is gradually making the things you get out of an MVC framework like Rails, Sails, Express, DJango, Spring Boot, and ASP.NET MVC pieces you get cheaply and simply without the use of a Framework. I’d recommend continuing to advance your skills by learning how to deploy static SPA’s which leverage CORS to interact with a Serverless API

          1. 2

            So your recommendation is to move more computing and data transmission workload into a less secure domain, by having crucial application functions run on client-side browsers, with data being exchanged between domains as a design default?

            That's a bold strategy, Cotton!

            For my sins, I still prefer MVC frameworks. They make logical sense - all the routing, views, data models and decision-making lives in one codebase, one language. There's no need to think about cross-domain policies when everything lives under the same roof, and lots of optimization is done for you - getting you far more performance out of your existing hardware every year. (I can't wait for preloading in PHP!)

      2. 2

        Over the years, I have seen so many languages and frameworks come and go. Just because something is new and shiny doesn't mean it has a future on the planet.

        It seems only a few short years ago that everyone was hyperventilating about Angular. Now? Barely a mention. And it is not alone in its current day obscurity.

      3. 1

        At least it's not correct to claim that.

        First of all, you don't know the future,

        secondly, to say that is the same as to say "if you don't become your project open source you will be in the dust in about 5 years".

      4. 1

        Without knowing me or the future I can only write to your claim: ha ha.

  4. 3

    I don't know that you are making a great case for serverless. There is an established structure to server-side apps and websites that are time-tested. Asking a question as you are can come off as academic. The negatives people are listing are quite enough to keep me from checking into serverless and I love progressive tech. But I also like predicitve results from services I am using and spending money on.

  5. 2

    It’s funny that everyone’s concerns about serverless seem to trend toward concerns about predictability and costs. We use the serverless framework at my employer (FinTech Company), half million to a million invocations week and our costs are ~250.00 a month. Can you imagine how cheap they are if you run them for a 50-100 customer bootstrapped app. I get the angst because change is scary. But let’s call it what it is. You’re not ready to invest in learning something new. And frankly, I get it. If you use your classic frameworks or approaches and it works don’t change it. It has to move the needle to be worth the time.

    Good article from the engineers at Etsy on the topic of choosing new technology:

    1. 3

      half million to a million invocations week and our costs are ~250.00 a month

      Testing my Elixir/Phoenix app at 1/3 of its max load on a $5 a month Digital Ocean droplet, it serves a million requests in one hour. As a back-end MVC framework written on a very high level functional language, it's also much more productive and testing is dead simple.

    2. 1

      This thread turned into a giant stink about "serverless is too complicated/scary/useless to learn more about it". Thanks for the good read. I love bootstrapping without a traditional server...the cost of my stack is almost free.

    3. 1

      1 million invocations/week at an average of 500ms/invocation (just guessing) is 2 million seconds of CPU time per month. Or, 23.1 days of a single core.

      For 250/month (USD?) you're buying capacity that could likely be replaced by a $15/month DigitalOcean droplet. $40 if you want to set up a floating IP and loadbalance between 2 droplets for HA.

      The added expense between a basic VM and your serverless functions is the intermediate orchestration layer: The bits that let you plug in your Javascript/Python/whatever and slot them into the larger REST frameworks, then the bits that measure execution time, and so on. On every call, you're spinning up a lot of other code to make your code work.

      Now, sure, I imagine that the cost difference between $40 and $250 is not significant enough for a fintech company to rebuild their serverless functions into a regular old REST API. It's a different consideration at the $100 vs $2500 level though. At some point, serverless just gets too expensive.

      1. 1

        DigitalOcean isn't going to handle the spikes in usage that serverless could. Now with that being said, I have ~1 mill invocations a month and it costs me less than $80 / month. That's Api Gateway/AWS Lambda/Dynamodb/Cloudwatch/S3/Cognito. And about 1/2 of that cost is cloudwatch... if I disabled logging, it'd be more like $40 / month. My usage tends to flow with USA daylight hours.

        As someone who's used AWS Lambda and Azure functions in production apps, including handling HIPAA compliant ones, I'm starting to question whether you have any serverless experience.

        1. 1

          So for $80/month you can string together a set of services that effectively let you: Put an endpoint on the internet, run functions, store data, store files, generate log entries and log users in. I can guarantee you the same is possible on a pair of DO droplets.

          Spikes can go one of two ways. Either they overload your stack and your site goes down temporarily (used to call that the slashdot effect), or your stack can autoscale to handle it and drive up your cost. Depending on what you care more about (cost control with fewer 9's of uptime vs HA regardless of cost), you'll select accordingly.

          HIPAA: I'm starting to question whether you've read everything in this thread :) HIPAA, like any other regulation, mostly just requires you to process, store, encrypt and secure access to data in certain ways. I worked with a cloud BI vendor who's stack was both entirely-AWS and HIPAA-compliant, so I know it's possible to achieve that - meaning that I'm not sure why your ability to deploy HIPAA-compliant solutions should result in questioning my experience with serverless technology.

  6. 2

    Right question would be, why my app should be on serverless ?

    1. 1

      Yours might not need to on serverless it really depends on the use-case... but these days there is also AWS Fargate which can easily account for most other use-cases.

  7. 1

    When you have a hammer, everything starts to look like a nail

  8. 1

    This thread is going the direction of any other internet discussion about development design patterns/architectures.. there are some reasoned arguments on both sides, but also those proclaiming that serverless is the way of the future and that if we don't see that then we just don't understand it.

    This is the same argument we had about the cloud, and there are still good reasons to host things on-prem. It's the same argument we had about microservices, and there are still good reasons to build a monolith.

    Serverless is interesting, and that architecture works well in a lot of cases, but it also has some disadvantages where something else would be better suited.

    I've been around long enough to see various technologies come and go, and I can only be sure of one thing.. there is no 'right way'.

  9. 1

    Maybe the better question is, for those who've used serverless and then choose to go away from it, why did you go away from it?

    It seems like a lot of people are shooting it down for invalid reasons. They think it's more limited than it is.

  10. 1

    As far as I understand it, serverless is a bit of a misnomer. You make API calls to deploy someone else’s server. However it is dressed up, serverless is only a vendor-locked abstraction. At the end, there is still a physical machine grinding away as ever it did.

    God help you if the vendor goes bust or, as with all the Google graveyard products someone posted here a few weeks ago, simply loses interest.

    My way? My code; my databases; my backups. If my web host goes down, simply bundle everything up and set up somewhere else.

    1. 3

      I've always seen "serverless" as a clever marketing term, and a way to introduce newcomers to the wonders of value-based pricing for individual executions. And it's not even the invention of the current-day giants - PiCloud did it many years before:

      There's a very specific set of use-cases where "serverless" makes sense, but it's almost entirely stuff that can be achieved through single HTTP calls, or where you're performing isolated steps on chunks of data you're receiving (like GCP's Dataflow). To build actual applications, with big ERD graphs and ACL-dependent actions and external integrations, you're gonna have a hard time.

      1. 2

        In a "hard to define, don't push me to quantify my uneasiness" sort of way, you've pretty much described my instinctive reaction to serverless technology.

        For a short while, I subscribed to a YouTube channel which was devoted to the "new" serverless technology and, for the life of me, I could not see what the benefits were compared to a standard set-up. I simply did not know what I was getting that made learning the new terms and changing my mindset worthwhile.

        1. 3

          I'm putting that "hard to define" feeling down to depth of understanding. I'm guessing that you've done enough software engineering to know that (a) history repeats itself (b) people keep reinventing the same tools and (c) the same principles have endured for decades, but since they're "old" they're automatically disregarded as irrelevant.

          It's really just the benefit of experience, I suppose? A lot of these newfangled tools and concepts seem aimed at people who have just learned how to write Javascript in the last year or two, and who haven't yet had to design an application to fit into the constraints of a limited hosting environment. Fitting things into disk, RAM or I/O is wasted mental bandwidth if you can just throw more credit card at the problem.

          1. 2

            Pretty much what you just said!

    2. 2

      You can bundle everything up and ship on the other vendors as well... AWS, Google, Azure, IBM... they all do about the same stuff. Vendor-lock-in shouldn't be a concern for young companies that probably won't last a decade.

      1. 3

        I suppose my question would be: do they all do the same stuff in the same way or would I find myself re-writing API calls or similar?

        1. 3

          Just as Microsoft and Google have philosophical disagreements over how to build browsers, it seems they have the same disagreements with serverless functions.

          Azure signature:

          Google signature:

          Moving between the two would require you to make changes to your functions, for sure. Setting them up on either system will have a different set of options for triggers, how they're mapped to API gateways, etc.

          So while migration is possible, the cost of migration looks like it may be equivalent to the cost of the initial build, meaning you really need to justify the effort.

          1. 2

            I could have put good money on your answer being something along those lines!