12 ms·

I don't understand the knee-jerk opposition people have to serverless architectures. I recently developed a service[1] with the serverless framework and it was

by paulgb 8y ago

I don't understand the knee-jerk opposition people have to serverless architectures. I recently developed a service[1] with the serverless framework and it was the first time I enjoyed developing server-side code since the era of PHP on shared hosts, where you could just upload code and refresh the page. There's something freeing about never having to think about the server process or what happens if the server is power cycled. So congrats on the funding, I hope you can convert some haters :) [1] obligatory plug: https://notify.run https://notify.run

skohan 8y ago
I just hope the API has stabilized. I worked on a project a couple of years ago using serverless, and we sunk a ton of time into fixing breaking changes after updates.
rawrmaan 8y ago
I think a lot of people have tried “serverless” and found it to present more challenges than it solves. How, for example, do you connect to a Postgres database from Lambda/Cloud Functions? As far as I can tell, the answer is: You don’t, you use a different database. No-worries devops experiences are nothing new. See Heroku.
- wahnfrieden 8y ago
  It’s still the early days so there are pain points, but Amazon already announced a solution to this: Serverless Aurora. It’ll be some time still until it’s public and Lambda-friendly though. And MySQL comes before Postgres.
- ryanworl 8y ago
  You connect the same way as you do in a regular app. Which is to say, you open the database connection outside of the request handling method (for example, as a global) and then use it from within the request handling method. When your app wakes up again for another request, the database connection is still open and you just use it.
  - qudat 8y ago
    As far as I know this works but more as a hack not as a robust officially supported solution.
    - scarface74 8y ago
      How is that a “hack”? You create your DB and you get a connection string to a publicly accessible database or you create it inside a VPC and you configure your lambda to run inside a subnet within your VPC and you configure your security group. This can all be configured within the console.
      - nrb 8y ago
        The main issue with this approach is that running your lambda in a VPC results in painfully slow cold starts, on AWS at least.
        paulddraper 8y ago
        IDK why the parent mentioned VPC. It's not necessary.
        scarface74 8y ago
        Without a VPC, how do you not expose your Aurora cluster to the world? https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/AuroraPostgreSQL.Security.html https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Auror... Aurora DB clusters must be created in an Amazon Virtual Private Cloud (VPC). To control which devices and Amazon EC2 instances can open connections to the endpoint and port of the DB instance for Aurora DB clusters in a VPC, you use a VPC security group. These endpoint and port connections can be made using Secure Sockets Layer (SSL). In addition, firewall rules at your company can control whether devices running at your company can open connections to a DB instance. For more information on VPCs, see Amazon Virtual Private Cloud (VPCs) and Amazon RDS.
- yoran 8y ago
  I think the example you give is more because there's a mismatch between technologies, rather than the "fault" of serverless. In serverless, your endpoints become infinitely scalable. This doesn't go well when they're backed by technologies where there is a hard limit on the number of connections, for instance SQL servers or a Redis server. I think therefore that SQL database technologies have to adapt to the serverless paradigm rather than dismissing serverless "because it brings so many other issues". I think AWS has already started that with Amazon Aurora. That aside, I agree that there are a lot of secondary concerns that are important when running things in production but that aren't available out-of-the-box when you run something on AWS Lambda. I'm thinking about error monitoring, performance monitoring, logging,... All those things need to be set up and that's quite time-consuming. However, I think that's more due to serverless being relatively new and not as mature as the traditional way of doing. I don't think it will take long before we'll have the equivalent for serverless of adding `gem 'newrelic_rpm'` to your Gemfile and magically having performance and error monitoring across your app.
  - rantanplan 8y ago
    > I think therefore that SQL database technologies have to adapt to the serverless paradigm rather than dismissing serverless Empty statement that means nothing. SQL/RDBMS is backed by computer science and robust engineering examples that make the world spin. Alternatives are usually full of fanfare and false promises. > I think AWS has already started that with Amazon Aurora. Just in time when we were talking about fanfare. Spend 10-20 minutes searching on the Internets to see what actual experiences people have with it. Its 3X write increase? Bollocks. Usually the performance is worse than when you administer your own DB(Postgresql/MySQL). You might(or not) see some read-performance increase, which... well everyone can scale on reads so I don't see the point. I suspect it has other goodies pertaining to administration/provisioning, but performance/scaling is not one of them.
    - athenot 8y ago
      >> I think therefore that SQL database technologies have to adapt to the serverless paradigm rather than dismissing serverless > Empty statement that means nothing. SQL/RDBMS is backed by computer science and robust engineering examples that make the world spin. Alternatives are usually full of fanfare and false promises. Traditional relational databaases have indeed solved many issues that some newer datastores struggle with. But the flip side is that it is non-trivial to design traditional databases that are not Single Points Of Failure. Storing data is surprizingly hard in a cloud environment, and involves trade-offs. Reaching a comprehensive solution (fast, HA, consistent, easily recoverable, scalable volum, evolvable schemas...) is hard no matter what technology you pick.
- brylie 8y ago
  I may misunderstand your comment. That said, where I work (MaaS Global) we have a production PostgreSQL database hosted on AWS Relational Database Service (RDS): https://aws.amazon.com/rds/postgresql/ https://aws.amazon.com/rds/postgresql/ We connect to the AWS RDS instance in our lambda functions using an ES library called knex.js and some environment variables to store the DB credentials: https://knexjs.org/ https://knexjs.org/
  - joecot 8y ago
    How do you deal with the 10+ second cold start times for Lambda when using it in a VPC? Are you pre-warming your lambda functions? Did you open up your RDS instance to the world so you could connect to it from a public lambda network? I know you had to pull some magic, because I've been down that road. It's been a problem for years and there's been no sign of a solution. Example article from last month: https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-latency-killer-5408323278dd https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-lat... These are the sorts of problems that turn people off from using serverless architectures.
    - kauju 8y ago
      Your right that the cold start times are not ideal. But you get a huge free request load per month. Put an uptime pinger on it and keep it warm. Or do what I do and write your functions in golang. My average cold start time is around 4 seconds. For the DB connection you put the lambda in the same vpc that the RDS exists in. Then you open the connection pool and reuse it if its active. Not that a new connection is a big overhead over leveraging an established socket. Wonder where all this misinformation is coming from on lambda DB access issues.
      - sbov 8y ago
        I know uptime pingers are easy and obvious solutions (I use them myself), but everytime I have to resort to this sort of hack it reminds me of how immature serverless is.
- dpeck 8y ago
  That’s really what’s keeping me from developing stuff with it. I can get the job done with dynamodb but I’m really looking forward to building something with Postgres in a “serverless” context.
- all_blue_chucks 8y ago
  > How, for example, do you connect to a Postgres database from Lambda/Cloud Functions? Exactly the same way you would with an EC2 instance...
  - tango12 8y ago
    Might not be that easy because only postgres can take a few hundreds of connections which won't work out if you have a few thousands of serverless functions? No persistent connection pools.
    - somebodythere 8y ago
      Well, just put the connection logic outside of the main handler so it's shared between invocations! Wait, oops, you have state now.
      - rhlsthrm 8y ago
        Realistically could you do this with Redis or something similar? Not sure about security implications of this though...
  - GordonS 8y ago
    How do you handle database connection pooling?
- ac360 8y ago
  imo, the most interesting data point is how in demand serverless architectures are WITH these issues. Imagine how compelling serverless will be once these issues are solved.
- ironjunkie 8y ago
  I fully agree with you. Based on my experience, Lambda is perfect if you only want to perform some relatively standalone task (such as a compute intensive rendering). As soon as it needs to connect to 3rd party entities, it becomes very slow and loses some of its benefits. Connecting Lambda to an AWS DB for example is challenging to say the least. It also takes a couple tens milliseconds just to setup the DB socket and connection, that on a normal server can simply remain open and wait for the next request. Serverless is nice, but the ecosystem of serverless tool is really missing today IMO
  - scarface74 8y ago
    Connecting Lambda to an AWS DB for example is challenging to say the least. Why does this keep getting repeated? You get a publicly accessible host and use the same drivers you use on prem or you put both the lambda and the database inside your VPC.
- dhdersch 8y ago
  Umm, for AWS, you place the Lambda function into a VPC and open a db connection the same way you would from another server?
  - spullara 8y ago
    I think what they are referring to is that Postgres and most other databases were built in the before time, the long long ago when every connection was a process and you limited concurrency of connections in the configuration file. If you have a 1000 concurrent calls on lambda you aren't going to be able to have them all talking to the same database at the same time. You'll run out of connections and the application will crash. Same reason you see this happen to PHP web applications when HN or Slashdot is pointed at them and they say they can't connect to the database. They have hit the concurrency limit. Connection pooling solves this problem but currently requires another layer between the application and the database.
- nodesocket 8y ago
  With Google Cloud Functions (they got the name right), you can simply link with a Cloud SQL instance using a special local socket interface provided by Google Cloud[1]. Their documentation provides complete examples as well on how to use global connection pools for MySQL and PostgreSQL. [1] https://cloud.google.com/functions/docs/sql https://cloud.google.com/functions/docs/sql
  - rawrmaan 8y ago
    Okay, that's a great solution. I actually had no idea that was possible.
- scarface74 8y ago
  What do you mean, how do you connect? The same way you connect on prem. Using, the Postgres drivers. You can either have a publicly accessible Postgres instance with a DNS entry (not recommended) or you can run both the DB and the lambda inside of a VPC.
- bmilleare 8y ago
  As others have pointed out, connecting to RDS from Lambda is actually pretty trivial by having them run in the same VPC. We actually came up against an issue where our Lambda function needed access to RDS but also to the outside World which meant some extra hurdles to jump [1] but overall our experience with Lambda has been a positive one. I don't think we'll be considering a fully serverless architecture anytime soon due to cold-start times, but it's awesome for anything outside of the user request/response loop or internal microservices where response time is perhaps not such of a problem. [1] https://aws.amazon.com/premiumsupport/knowledge-center/internet-access-lambda-function/ https://aws.amazon.com/premiumsupport/knowledge-center/inter...
matte_black 8y ago
Lack of connection pooling for database connections means serverless architecture will never be used for serious data heavy apps.
- whistlerbrk 8y ago
  not necessarily into this serverless thing but that doesn't seem like a valid complaint, use a global connection pooler like pgbouncer
  - patrickg_zill 8y ago
    Does e.g. Amazon's offering have a way to do that? Or is there still a cold start time? Where do you run the pgbouncer that is always running?
    - gazarsgo 8y ago
      in AWS Fargate, of course...
  - matte_black 8y ago
    Try it.
- wahnfrieden 8y ago
  AWS already solving this with Serverless Aurora.
na85 8y ago
I think it's due to the fact that the terminology seems intentionally misleading at worst, and like a marketing buzzword at best. Every technical person understands there's still a server there. So it seems like a marketing tactic intent on misleading clueless CEOs.
- dragonwriter 8y ago
  > I think it's due to the fact that the terminology seems intentionally misleading at worst, and like a marketing buzzword at best. Originally it was a marketing buzzowrd designed to make Amazon's FaaS offering seem like a bigger deal than it was, and somewhat misleading in that role because FaaS of the type it was applied to aren't any more serverless (even from the perspective of what the customer needs to manage) than common PaaS offerings. OTOH, I kind of like the way Google seems to have adopted it as a blanket term for cloud services where the customer is not concerned with physical or virtual servers as such; it seems the term.is being wrestled into being descriptive and non-deceptive. > Every technical person understands there's still a server there. So it seems like a marketing tactic intent on misleading clueless CEOs. The non-existence of servers isn't what it communicates, only technical people who also lack any sense of what matters to business world think that. (It's also targeted more to CTOs/CIOs than CEOs).
- paulgb 8y ago
  > Every technical person understands there's still a server there. Everybody also knows that a wireless vacuum has wires inside it, the value prop is that the wires never get in your way. And so with serverless.
manigandham 8y ago
Because it should really just be called Functions-as-a-service, and they are great for single-focus reactive/connective processing and 1-off tasks but are not a replacement for everything as people try to use it for.
- k__ 8y ago
  As far as I know, serverless isn't just FaaS. As you pointed out FaaS is to connect things, nothing more. For me serverless is pay-as-you go pricing, no over- or under-provisioning and last but not least, no server-management. Lambda, DynamoDB, S3, AppSync, Device Farm, Aurora, etc. are all serverless.
  - castlecrasher2 8y ago
    > Lambda, DynamoDB, S3, AppSync, Device Farm, Aurora, etc. are all serverless. Yep. Lambda may be functions-as-a-service, which is a great name for it, but the whole shebang is more than that. Thus, serverless.
  - detaro 8y ago
    How would you distinguish it from "PaaS"?
    - k__ 8y ago
      The "serverless" model frees you of more tasks than PaaS, like capacity planning and scaling, also it's more flexible and fault tolerant.
- staticassertion 8y ago
  Why shouldn't it be called serverless? As a consumer, I essentially get to treat it as such - there is no server I need to manage. In AWS-land this is a big differentiator over a system I have to manage, such as EC2, that just executes containers (meeting FAAS). Now I have FAAS and I don’t have to manage the infra, which is huge because AWS will be far better at meeting a patching SLA than I will be. Yes, obviously there is a “server”, but I don’t have to think about it.
everdev 8y ago
I think the biggest knock against serverless is the same as microservices: your points of failure grow significantly.
- moduspol 8y ago
  The points of failure you are responsible for maintaining decrease significantly, though. And the ones you aren't responsible for are ones that the rest of the world uses every day at 1000x the scale you do.
- staticassertion 8y ago
  I don't see how. Your points of failure were always there, but at most they're more explicit since "service failure" conflates with "network failure" - something I think is beneficial, since you always had to handle "service failures" but they were implicit. That is - a piece of code in a monolith may fail, and a piece of code in a microservice may fail, but I've already written the code to handle network errors for the microservice case, which means I've also implicitly handled the "bug in code" case.
  - SahAssar 8y ago
    That assumes that a local function call has the same failure rate as a remote function call to a microservice, which in my experience is very much not true. If I have a local function in the same language I can pretty much assume that a call to that function will actually call that function. With a remote call over HTTP or whatever I can't, so that is an additional failure I need to handle.
    - staticassertion 8y ago
      I'm not sure I understand. Why would an RPC call a different function than what you expect? I'll grant you that there is more complexity in this approach, but I believe that fault tolerance is something you improve with microservices, not something you regress on.
chx 8y ago
Serverless is a buzzword for a distributed system you can't SSH into.
- paulgb 8y ago
  I can't tell if that's meant to be a pejorative, but a distributed system I can't (and don't need to) SSH into makes my life easier :)
  - lowercased 8y ago
    can't and not needing to are two really different things. the 'not needing to' just being shifted to having to use proprietary environments for doing stuff essential to debugging (like looking at log files) is, for most people, not a net win.
  - old-gregg 8y ago
    The comment above probably meant to say that any environment becomes "serverless" as soon as you stop managing instances/servers manually and interact with it strictly via an API endpoint, which of course has always been possible but required fairly in-depth knowledge of AWS APIs (or other cloud provider's). Look, there's nothing dirty about re-framing the conversation every once in a while. It may feel like BS at first but over time we attach new meaning to old words and it becomes easier to communicate capabilities.
nostalgeek 8y ago
> I don't understand the knee-jerk opposition people have to serverless architectures because it's purely a marketing concern, it means nothing from an architectural standpoint, it"s a buzzword, like 'cloud', 'nosql', 'web 2.0' or 'the blockchain'.
- wnsire 8y ago
  > because it's purely a marketing concern, it means nothing from an architectural standpoint Serverless computing is an system architecture design that focus emphasis is abstracting the entirety of the infrastructure to let developers focus solely on code. Per say , with AWS Lamba + API Gateway + S3 developers can create Web Application that usually required EC2 Servers and web framework like Spring , Laravel etc... Apps hosted on AWS with EC2 requires strong knowledge in system architecture and system design . They also are quiet complex to scale , monitor and manage. Serverless abstract all this and lets you focus only on code. AWS Lambda is self healing meaning when a function crash , only that function crash not the entire server , API Gateway is managed by AWS it won't crash ( or very unlikely ) S3 , as i'm concerned , as never let me down. Meaning I could author an entire application similar to Hacker News without any "Server" logically speaking, technically speaking there is always a server just like NoSQL doesn't mean "NO SQL" but "Not Only SQL" and is not buzzword :)
  - deleted 8y ago
    [deleted]
Zelphyr 8y ago
It feels like a giant step backward from a development standpoint. It's as bad or worse than the days when I had to make a change, save it, FTP that file to the server, refresh, lather-rinse-repeat. Want a debugger? Nope. Want log files? Gotta get them from a different service that frequently has a lag of 30 seconds or more[1]. Don't get me started on the massive vendor lock-in inherent with a Serverless Architecture[2]. Don't get me wrong; from a resources management and scaling perspective it's great. But that doesn't outweigh the massive pain during development that it creates. We're in the process of rebuilding a project to move everything out of a Serverless Architecture. After six months of building it on serverless we finally all agreed it was a big mistake. [1] That's our experience with AWS. May be different with other providers. [2] I recognize that Serverless Framework helps mitigate this but that's just yet another abstraction on top of abstractions in my opinion.
- matchagaucho 8y ago
  Serverless architecture certainly benefits from a localhost-first environment with mock data and unit test feedback prior to deployment. But then... any architecture benefits from localhost-first.
  - jjeaff 8y ago
    Localhost first is ideal. But not always possible.
    - eyjafjallajokul 8y ago
      Can you explain why?
      - Zelphyr 8y ago
        Why its ideal or not always possible? Ideal because it's faster development time. And free since I'm not paying Amazon compute time to run my code while I write it. Not always possible because I don't have AWS's services locally. As mentioned elsewhere, there are emulators but, by virtue of their emulation, may not always perform like the real thing. That's a debugging ball of wax that I personally hate having to untangle.
rightbyte 8y ago
Serverless in this context is Server-aaS. It's doublespeak. That's why I "knee-jerk". Instead of a couple of servers you have thousands of small virtual servers running on real server and call that serverless. It's comical. I wonder what hell this approach will be for legacy serverless systems where there is stuff running everywhere and no one got a clue where to pull the plug or patch stuff.
gaius 8y ago
I don't understand the knee-jerk opposition people have to serverless architectures It’s the name. It infuriates people because obviously there still really are servers. But I think of it like WiFi - there still are wires, you just don’t see them.
- laumars 8y ago
  Except there literally isn't any wires in WiFi. Unless you're talking about power cables on access points or other unrelated tech used on devices that have ethernet / whatever AS WELL AS WiFi?
  - pvg 8y ago
    All-caps italics is an interesting choice. Is that both emphasized AND shouted?
    - deleted 8y ago
      [deleted]
    - laumars 8y ago
      Haha yeah on reflection it does look a bit silly. I was intending for it just to stand out against the camelcase of "WiFi" but the caps was a poor choice in hindsight.
  - gaius 8y ago
    Except there literally isn't any wires in WiFi. You think WiFi connects your laptop directly to the server in the datacentre? Interesting.
    - laumars 8y ago
      > Except there literally isn't any wires in WiFi. > You think WiFi connects your laptop directly to the server in the datacentre? Interesting. The way you've selectively quoted one sentence out of what is a very short post anyway just so you can imply that I'm oblivious to other infrastructure - even when my very next sentence describes other infrastructure - is in very poor taste. Plus you're still failed to prove point. Yes ethernet over cat5e/6 cables and fibre exist, but they're not WiFi. Neither is 4G, Bluetooth, nor FM radio despite actually being wireless (unlike cat6 / fibre). What you're arguing is beyond nonsensical; it's like saying "I drive to the railway station every morning therefore the train I then catch is also classified as a car." The daft thing is if you'd talked about the wireless radio's antenna then you might have had a genuine point. Yet you went the "network cables are WiFi as well" argument instead. Go figure.
pbreit 8y ago
I don't think it compares to the move to the cloud. The cloud was a lot easier to setup than dedicated and the end result was basically the same...you got a server. Serverless is quite a different paradigm and the benefits are less obvious.
tenaciousDaniel 8y ago
I help run a Node server, and we have some jobs that aren't run through CRON, but instead are set up using in-memory intervals. So I'm considering using a serverless setup to offload the work. In your opinion, it easy to differentiate between dev/prod environments for development? How about logging?
- qudat 8y ago
  Logging by default sucks for Lambdas. Because lambdas are not "servers" they do not have an external IP address, which means that if they want to communicate with the external world, you need to setup a NAT for it. Differentiating dev/prod is not too bad, everything is labelled based on your naming scheme for serverless. Having said that I think lambdas are a great use case for cron jobs.
Yver 8y ago
I can't say much about its technical merits but I find it misleading that an application be described as "serverless" when in actuality it very much uses servers. The "serverless" moniker comes from the Serverless Framework, produced by Serverless, Inc. "Serverless" is the name of a product and should be capitalized accordingly.

by paulgb 8y ago

skohan 8y ago

I just hope the API has stabilized. I worked on a project a couple of years ago using serverless, and we sunk a ton of time into fixing breaking changes after updates.

rawrmaan 8y ago

I think a lot of people have tried “serverless” and found it to present more challenges than it solves. How, for example, do you connect to a Postgres database from Lambda/Cloud Functions? As far as I can tell, the answer is: You don’t, you use a different database. No-worries devops experiences are nothing new. See Heroku.

wahnfrieden 8y ago
It’s still the early days so there are pain points, but Amazon already announced a solution to this: Serverless Aurora. It’ll be some time still until it’s public and Lambda-friendly though. And MySQL comes before Postgres.
ryanworl 8y ago
You connect the same way as you do in a regular app. Which is to say, you open the database connection outside of the request handling method (for example, as a global) and then use it from within the request handling method. When your app wakes up again for another request, the database connection is still open and you just use it.
- qudat 8y ago
  As far as I know this works but more as a hack not as a robust officially supported solution.
  - scarface74 8y ago
    How is that a “hack”? You create your DB and you get a connection string to a publicly accessible database or you create it inside a VPC and you configure your lambda to run inside a subnet within your VPC and you configure your security group. This can all be configured within the console.
    - nrb 8y ago
      The main issue with this approach is that running your lambda in a VPC results in painfully slow cold starts, on AWS at least.
      - paulddraper 8y ago
        IDK why the parent mentioned VPC. It's not necessary.
        scarface74 8y ago
        Without a VPC, how do you not expose your Aurora cluster to the world? https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/AuroraPostgreSQL.Security.html https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Auror... Aurora DB clusters must be created in an Amazon Virtual Private Cloud (VPC). To control which devices and Amazon EC2 instances can open connections to the endpoint and port of the DB instance for Aurora DB clusters in a VPC, you use a VPC security group. These endpoint and port connections can be made using Secure Sockets Layer (SSL). In addition, firewall rules at your company can control whether devices running at your company can open connections to a DB instance. For more information on VPCs, see Amazon Virtual Private Cloud (VPCs) and Amazon RDS.
yoran 8y ago
I think the example you give is more because there's a mismatch between technologies, rather than the "fault" of serverless. In serverless, your endpoints become infinitely scalable. This doesn't go well when they're backed by technologies where there is a hard limit on the number of connections, for instance SQL servers or a Redis server. I think therefore that SQL database technologies have to adapt to the serverless paradigm rather than dismissing serverless "because it brings so many other issues". I think AWS has already started that with Amazon Aurora. That aside, I agree that there are a lot of secondary concerns that are important when running things in production but that aren't available out-of-the-box when you run something on AWS Lambda. I'm thinking about error monitoring, performance monitoring, logging,... All those things need to be set up and that's quite time-consuming. However, I think that's more due to serverless being relatively new and not as mature as the traditional way of doing. I don't think it will take long before we'll have the equivalent for serverless of adding `gem 'newrelic_rpm'` to your Gemfile and magically having performance and error monitoring across your app.
- rantanplan 8y ago
  > I think therefore that SQL database technologies have to adapt to the serverless paradigm rather than dismissing serverless Empty statement that means nothing. SQL/RDBMS is backed by computer science and robust engineering examples that make the world spin. Alternatives are usually full of fanfare and false promises. > I think AWS has already started that with Amazon Aurora. Just in time when we were talking about fanfare. Spend 10-20 minutes searching on the Internets to see what actual experiences people have with it. Its 3X write increase? Bollocks. Usually the performance is worse than when you administer your own DB(Postgresql/MySQL). You might(or not) see some read-performance increase, which... well everyone can scale on reads so I don't see the point. I suspect it has other goodies pertaining to administration/provisioning, but performance/scaling is not one of them.
  - athenot 8y ago
    >> I think therefore that SQL database technologies have to adapt to the serverless paradigm rather than dismissing serverless > Empty statement that means nothing. SQL/RDBMS is backed by computer science and robust engineering examples that make the world spin. Alternatives are usually full of fanfare and false promises. Traditional relational databaases have indeed solved many issues that some newer datastores struggle with. But the flip side is that it is non-trivial to design traditional databases that are not Single Points Of Failure. Storing data is surprizingly hard in a cloud environment, and involves trade-offs. Reaching a comprehensive solution (fast, HA, consistent, easily recoverable, scalable volum, evolvable schemas...) is hard no matter what technology you pick.
brylie 8y ago
I may misunderstand your comment. That said, where I work (MaaS Global) we have a production PostgreSQL database hosted on AWS Relational Database Service (RDS): https://aws.amazon.com/rds/postgresql/ https://aws.amazon.com/rds/postgresql/ We connect to the AWS RDS instance in our lambda functions using an ES library called knex.js and some environment variables to store the DB credentials: https://knexjs.org/ https://knexjs.org/
- joecot 8y ago
  How do you deal with the 10+ second cold start times for Lambda when using it in a VPC? Are you pre-warming your lambda functions? Did you open up your RDS instance to the world so you could connect to it from a public lambda network? I know you had to pull some magic, because I've been down that road. It's been a problem for years and there's been no sign of a solution. Example article from last month: https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-latency-killer-5408323278dd https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-lat... These are the sorts of problems that turn people off from using serverless architectures.
  - kauju 8y ago
    Your right that the cold start times are not ideal. But you get a huge free request load per month. Put an uptime pinger on it and keep it warm. Or do what I do and write your functions in golang. My average cold start time is around 4 seconds. For the DB connection you put the lambda in the same vpc that the RDS exists in. Then you open the connection pool and reuse it if its active. Not that a new connection is a big overhead over leveraging an established socket. Wonder where all this misinformation is coming from on lambda DB access issues.
    - sbov 8y ago
      I know uptime pingers are easy and obvious solutions (I use them myself), but everytime I have to resort to this sort of hack it reminds me of how immature serverless is.
dpeck 8y ago
That’s really what’s keeping me from developing stuff with it. I can get the job done with dynamodb but I’m really looking forward to building something with Postgres in a “serverless” context.
all_blue_chucks 8y ago
> How, for example, do you connect to a Postgres database from Lambda/Cloud Functions? Exactly the same way you would with an EC2 instance...
- tango12 8y ago
  Might not be that easy because only postgres can take a few hundreds of connections which won't work out if you have a few thousands of serverless functions? No persistent connection pools.
  - somebodythere 8y ago
    Well, just put the connection logic outside of the main handler so it's shared between invocations! Wait, oops, you have state now.
    - rhlsthrm 8y ago
      Realistically could you do this with Redis or something similar? Not sure about security implications of this though...
- GordonS 8y ago
  How do you handle database connection pooling?
ac360 8y ago
imo, the most interesting data point is how in demand serverless architectures are WITH these issues. Imagine how compelling serverless will be once these issues are solved.
ironjunkie 8y ago
I fully agree with you. Based on my experience, Lambda is perfect if you only want to perform some relatively standalone task (such as a compute intensive rendering). As soon as it needs to connect to 3rd party entities, it becomes very slow and loses some of its benefits. Connecting Lambda to an AWS DB for example is challenging to say the least. It also takes a couple tens milliseconds just to setup the DB socket and connection, that on a normal server can simply remain open and wait for the next request. Serverless is nice, but the ecosystem of serverless tool is really missing today IMO
- scarface74 8y ago
  Connecting Lambda to an AWS DB for example is challenging to say the least. Why does this keep getting repeated? You get a publicly accessible host and use the same drivers you use on prem or you put both the lambda and the database inside your VPC.
dhdersch 8y ago
Umm, for AWS, you place the Lambda function into a VPC and open a db connection the same way you would from another server?
- spullara 8y ago
  I think what they are referring to is that Postgres and most other databases were built in the before time, the long long ago when every connection was a process and you limited concurrency of connections in the configuration file. If you have a 1000 concurrent calls on lambda you aren't going to be able to have them all talking to the same database at the same time. You'll run out of connections and the application will crash. Same reason you see this happen to PHP web applications when HN or Slashdot is pointed at them and they say they can't connect to the database. They have hit the concurrency limit. Connection pooling solves this problem but currently requires another layer between the application and the database.
nodesocket 8y ago
With Google Cloud Functions (they got the name right), you can simply link with a Cloud SQL instance using a special local socket interface provided by Google Cloud[1]. Their documentation provides complete examples as well on how to use global connection pools for MySQL and PostgreSQL. [1] https://cloud.google.com/functions/docs/sql https://cloud.google.com/functions/docs/sql
- rawrmaan 8y ago
  Okay, that's a great solution. I actually had no idea that was possible.
scarface74 8y ago
What do you mean, how do you connect? The same way you connect on prem. Using, the Postgres drivers. You can either have a publicly accessible Postgres instance with a DNS entry (not recommended) or you can run both the DB and the lambda inside of a VPC.
bmilleare 8y ago
As others have pointed out, connecting to RDS from Lambda is actually pretty trivial by having them run in the same VPC. We actually came up against an issue where our Lambda function needed access to RDS but also to the outside World which meant some extra hurdles to jump [1] but overall our experience with Lambda has been a positive one. I don't think we'll be considering a fully serverless architecture anytime soon due to cold-start times, but it's awesome for anything outside of the user request/response loop or internal microservices where response time is perhaps not such of a problem. [1] https://aws.amazon.com/premiumsupport/knowledge-center/internet-access-lambda-function/ https://aws.amazon.com/premiumsupport/knowledge-center/inter...

matte_black 8y ago

Lack of connection pooling for database connections means serverless architecture will never be used for serious data heavy apps.

whistlerbrk 8y ago
not necessarily into this serverless thing but that doesn't seem like a valid complaint, use a global connection pooler like pgbouncer
- patrickg_zill 8y ago
  Does e.g. Amazon's offering have a way to do that? Or is there still a cold start time? Where do you run the pgbouncer that is always running?
  - gazarsgo 8y ago
    in AWS Fargate, of course...
- matte_black 8y ago
  Try it.
wahnfrieden 8y ago
AWS already solving this with Serverless Aurora.

na85 8y ago

I think it's due to the fact that the terminology seems intentionally misleading at worst, and like a marketing buzzword at best. Every technical person understands there's still a server there. So it seems like a marketing tactic intent on misleading clueless CEOs.

dragonwriter 8y ago
> I think it's due to the fact that the terminology seems intentionally misleading at worst, and like a marketing buzzword at best. Originally it was a marketing buzzowrd designed to make Amazon's FaaS offering seem like a bigger deal than it was, and somewhat misleading in that role because FaaS of the type it was applied to aren't any more serverless (even from the perspective of what the customer needs to manage) than common PaaS offerings. OTOH, I kind of like the way Google seems to have adopted it as a blanket term for cloud services where the customer is not concerned with physical or virtual servers as such; it seems the term.is being wrestled into being descriptive and non-deceptive. > Every technical person understands there's still a server there. So it seems like a marketing tactic intent on misleading clueless CEOs. The non-existence of servers isn't what it communicates, only technical people who also lack any sense of what matters to business world think that. (It's also targeted more to CTOs/CIOs than CEOs).
paulgb 8y ago
> Every technical person understands there's still a server there. Everybody also knows that a wireless vacuum has wires inside it, the value prop is that the wires never get in your way. And so with serverless.

manigandham 8y ago

Because it should really just be called Functions-as-a-service, and they are great for single-focus reactive/connective processing and 1-off tasks but are not a replacement for everything as people try to use it for.

k__ 8y ago
As far as I know, serverless isn't just FaaS. As you pointed out FaaS is to connect things, nothing more. For me serverless is pay-as-you go pricing, no over- or under-provisioning and last but not least, no server-management. Lambda, DynamoDB, S3, AppSync, Device Farm, Aurora, etc. are all serverless.
- castlecrasher2 8y ago
  > Lambda, DynamoDB, S3, AppSync, Device Farm, Aurora, etc. are all serverless. Yep. Lambda may be functions-as-a-service, which is a great name for it, but the whole shebang is more than that. Thus, serverless.
- detaro 8y ago
  How would you distinguish it from "PaaS"?
  - k__ 8y ago
    The "serverless" model frees you of more tasks than PaaS, like capacity planning and scaling, also it's more flexible and fault tolerant.
staticassertion 8y ago
Why shouldn't it be called serverless? As a consumer, I essentially get to treat it as such - there is no server I need to manage. In AWS-land this is a big differentiator over a system I have to manage, such as EC2, that just executes containers (meeting FAAS). Now I have FAAS and I don’t have to manage the infra, which is huge because AWS will be far better at meeting a patching SLA than I will be. Yes, obviously there is a “server”, but I don’t have to think about it.

everdev 8y ago

I think the biggest knock against serverless is the same as microservices: your points of failure grow significantly.

moduspol 8y ago
The points of failure you are responsible for maintaining decrease significantly, though. And the ones you aren't responsible for are ones that the rest of the world uses every day at 1000x the scale you do.
staticassertion 8y ago
I don't see how. Your points of failure were always there, but at most they're more explicit since "service failure" conflates with "network failure" - something I think is beneficial, since you always had to handle "service failures" but they were implicit. That is - a piece of code in a monolith may fail, and a piece of code in a microservice may fail, but I've already written the code to handle network errors for the microservice case, which means I've also implicitly handled the "bug in code" case.
- SahAssar 8y ago
  That assumes that a local function call has the same failure rate as a remote function call to a microservice, which in my experience is very much not true. If I have a local function in the same language I can pretty much assume that a call to that function will actually call that function. With a remote call over HTTP or whatever I can't, so that is an additional failure I need to handle.
  - staticassertion 8y ago
    I'm not sure I understand. Why would an RPC call a different function than what you expect? I'll grant you that there is more complexity in this approach, but I believe that fault tolerance is something you improve with microservices, not something you regress on.

chx 8y ago

Serverless is a buzzword for a distributed system you can't SSH into.

paulgb 8y ago
I can't tell if that's meant to be a pejorative, but a distributed system I can't (and don't need to) SSH into makes my life easier :)
- lowercased 8y ago
  can't and not needing to are two really different things. the 'not needing to' just being shifted to having to use proprietary environments for doing stuff essential to debugging (like looking at log files) is, for most people, not a net win.
- old-gregg 8y ago
  The comment above probably meant to say that any environment becomes "serverless" as soon as you stop managing instances/servers manually and interact with it strictly via an API endpoint, which of course has always been possible but required fairly in-depth knowledge of AWS APIs (or other cloud provider's). Look, there's nothing dirty about re-framing the conversation every once in a while. It may feel like BS at first but over time we attach new meaning to old words and it becomes easier to communicate capabilities.

nostalgeek 8y ago

> I don't understand the knee-jerk opposition people have to serverless architectures because it's purely a marketing concern, it means nothing from an architectural standpoint, it"s a buzzword, like 'cloud', 'nosql', 'web 2.0' or 'the blockchain'.

wnsire 8y ago
> because it's purely a marketing concern, it means nothing from an architectural standpoint Serverless computing is an system architecture design that focus emphasis is abstracting the entirety of the infrastructure to let developers focus solely on code. Per say , with AWS Lamba + API Gateway + S3 developers can create Web Application that usually required EC2 Servers and web framework like Spring , Laravel etc... Apps hosted on AWS with EC2 requires strong knowledge in system architecture and system design . They also are quiet complex to scale , monitor and manage. Serverless abstract all this and lets you focus only on code. AWS Lambda is self healing meaning when a function crash , only that function crash not the entire server , API Gateway is managed by AWS it won't crash ( or very unlikely ) S3 , as i'm concerned , as never let me down. Meaning I could author an entire application similar to Hacker News without any "Server" logically speaking, technically speaking there is always a server just like NoSQL doesn't mean "NO SQL" but "Not Only SQL" and is not buzzword :)
- deleted 8y ago
  [deleted]

Zelphyr 8y ago

It feels like a giant step backward from a development standpoint. It's as bad or worse than the days when I had to make a change, save it, FTP that file to the server, refresh, lather-rinse-repeat. Want a debugger? Nope. Want log files? Gotta get them from a different service that frequently has a lag of 30 seconds or more[1]. Don't get me started on the massive vendor lock-in inherent with a Serverless Architecture[2]. Don't get me wrong; from a resources management and scaling perspective it's great. But that doesn't outweigh the massive pain during development that it creates. We're in the process of rebuilding a project to move everything out of a Serverless Architecture. After six months of building it on serverless we finally all agreed it was a big mistake. [1] That's our experience with AWS. May be different with other providers. [2] I recognize that Serverless Framework helps mitigate this but that's just yet another abstraction on top of abstractions in my opinion.

matchagaucho 8y ago
Serverless architecture certainly benefits from a localhost-first environment with mock data and unit test feedback prior to deployment. But then... any architecture benefits from localhost-first.
- jjeaff 8y ago
  Localhost first is ideal. But not always possible.
  - eyjafjallajokul 8y ago
    Can you explain why?
    - Zelphyr 8y ago
      Why its ideal or not always possible? Ideal because it's faster development time. And free since I'm not paying Amazon compute time to run my code while I write it. Not always possible because I don't have AWS's services locally. As mentioned elsewhere, there are emulators but, by virtue of their emulation, may not always perform like the real thing. That's a debugging ball of wax that I personally hate having to untangle.

rightbyte 8y ago

Serverless in this context is Server-aaS. It's doublespeak. That's why I "knee-jerk". Instead of a couple of servers you have thousands of small virtual servers running on real server and call that serverless. It's comical. I wonder what hell this approach will be for legacy serverless systems where there is stuff running everywhere and no one got a clue where to pull the plug or patch stuff.

gaius 8y ago

I don't understand the knee-jerk opposition people have to serverless architectures It’s the name. It infuriates people because obviously there still really are servers. But I think of it like WiFi - there still are wires, you just don’t see them.

laumars 8y ago
Except there literally isn't any wires in WiFi. Unless you're talking about power cables on access points or other unrelated tech used on devices that have ethernet / whatever AS WELL AS WiFi?
- pvg 8y ago
  All-caps italics is an interesting choice. Is that both emphasized AND shouted?
  - deleted 8y ago
    [deleted]
  - laumars 8y ago
    Haha yeah on reflection it does look a bit silly. I was intending for it just to stand out against the camelcase of "WiFi" but the caps was a poor choice in hindsight.
- gaius 8y ago
  Except there literally isn't any wires in WiFi. You think WiFi connects your laptop directly to the server in the datacentre? Interesting.
  - laumars 8y ago
    > Except there literally isn't any wires in WiFi. > You think WiFi connects your laptop directly to the server in the datacentre? Interesting. The way you've selectively quoted one sentence out of what is a very short post anyway just so you can imply that I'm oblivious to other infrastructure - even when my very next sentence describes other infrastructure - is in very poor taste. Plus you're still failed to prove point. Yes ethernet over cat5e/6 cables and fibre exist, but they're not WiFi. Neither is 4G, Bluetooth, nor FM radio despite actually being wireless (unlike cat6 / fibre). What you're arguing is beyond nonsensical; it's like saying "I drive to the railway station every morning therefore the train I then catch is also classified as a car." The daft thing is if you'd talked about the wireless radio's antenna then you might have had a genuine point. Yet you went the "network cables are WiFi as well" argument instead. Go figure.

pbreit 8y ago

I don't think it compares to the move to the cloud. The cloud was a lot easier to setup than dedicated and the end result was basically the same...you got a server. Serverless is quite a different paradigm and the benefits are less obvious.

tenaciousDaniel 8y ago

I help run a Node server, and we have some jobs that aren't run through CRON, but instead are set up using in-memory intervals. So I'm considering using a serverless setup to offload the work. In your opinion, it easy to differentiate between dev/prod environments for development? How about logging?

qudat 8y ago
Logging by default sucks for Lambdas. Because lambdas are not "servers" they do not have an external IP address, which means that if they want to communicate with the external world, you need to setup a NAT for it. Differentiating dev/prod is not too bad, everything is labelled based on your naming scheme for serverless. Having said that I think lambdas are a great use case for cron jobs.

Yver 8y ago

I can't say much about its technical merits but I find it misleading that an application be described as "serverless" when in actuality it very much uses servers. The "serverless" moniker comes from the Serverless Framework, produced by Serverless, Inc. "Serverless" is the name of a product and should be capitalized accordingly.