Build a Serverless Web Applicaion | Hacker News Reader

Build a Serverless Web Applicaion

aws.amazon.com

153 pointsmunns148 comments

Is anyone else slightly peeved by the popularity of this misnomer?

If you are paying for servers, your app isn't serverless. Real serverless to me means decentralized p2p and offline apps. I also consider p2p-routed apps with centralized control serverless as long as they continue to function in a read-only state when the control server is down.

No, I'm not peeved by the "misnomer". What is getting a bit annoying is every conversation about serverless being dominated by snarky comments about there being no such thing. As software professionals, we all know there is a server involved in responding to requests for our applications. But 'serverless' does accurately describe services like AWS Lambda, because the experience of development is such that you don't really have to think about servers, along with all the complexity of provisioning, configuring and managing them.

TL;DR: It's just a name. Get over it.

> But 'serverless' does accurately describe services like AWS Lambda,

Serverless means no server, which is false, because there is a server that runs your code.

> because the experience of development is such that you don't really have to think about servers, along with all the complexity of provisioning, configuring and managing them.

That sounds like you are talking about 'web hosting' or 'application hosting', which existed decades ago, don't see any point in inventing a confusing buzzword when we have perfectly fine terminologies already.

> TL;DR: It's just a name. Get over it.

It's a useless and confusing marketing buzzword that makes having intelligent conversations harder. I would love to understand your rationale for defending this confusing buzzword.

> It's a useless and confusing marketing buzzword

A marketing buzzword is something like "web scale", which might be used by a non-technical person to describe a technology, but has no real technical meaning. Serverless is not a buzzword because it is the name used for a collection of technologies, even if it isn't a specific product. "Software containers" also falls into this category.

Yes, serverless architectures involve servers. Well done for recognising this, you are very smart. In fact, you are smart enough to realise that the architectures we are talking about here are very distinct from traditional web hosting services. So, it's convenient to use a different name for them.

Finally, it doesn't really matter whether you like the term or not. It is the accepted term and it is here to stay. If you want to engage in conversations on the topic you will need to move past your misgivings.

> A marketing buzzword is something like "web scale", which might be used by a non-technical person to describe a technology, but has no real technical meaning. Serverless is not a buzzword because it is the name used for a collection of technologies, even if it isn't a specific product.

What collection of technologies does it name? And how is that different from "web scale" technologies that is also a group of technologies?

> Yes, serverless architectures involve servers. Well done for recognising this, you are very smart.

If you would have strong arguments, you wouldn't need snarkiness.

> In fact, you are smart enough to realise that the architectures we are talking about here are very distinct from traditional web hosting services.

That's the exact opposite of what I've said, if you look at it from a server management point of view, traditional web hosting and "serverless" are one and the same, both are used to run the code you upload and both are managed by someone else.

> So, it's convenient to use a different name for them.

It's not convenient, it's confusing.

> Finally, it doesn't really matter whether you like the term or not. It is the accepted term and it is here to stay.

Accepted by who?

> If you want to engage in conversations on the topic you will need to move past your misgivings.

If you want to engage in conversations on any topic with anyone, you should read what's on this website https://yourlogicalfallacyis.com/ and stop doing them.

Ad hominem comments are really unnecessary. Your statement "Serverless is not a buzzword because it is the name used for a collection of technologies" is not logically true. There are many buzzwords referring to collections of technologies, and "serveless" is just one of them.

"Serverless" is definitely not an "accurate description of AWS Lambda", because the work is done by servers. As the parent mentioned, it would be a much more accurate description of P2P services/protocols.

> the experience of development is such that you don't really have to think about servers, along with all the complexity of provisioning, configuring and managing them.

But didn't we get "The Cloud" to do that? I mean I'm fine with rebranding but this is a really fine line.

No. The Cloud is used to collectively represent all kinds different types of computing/storage/auxiliary services that can be managed on demand.

Notice how you didn't use the term server to describe "The Cloud"

I think something like "Server-nescient Web Application." Marketing departments should like a fun word like nescient.

Agreed, it is very annoying, maybe 'serverless' isn't the best name, but 'adminless' is no better. All the banal comments about the name have really impeded discussion about this topic.

I personally am angered at the 'everyone should be a sys admin' culture we've come into as a profession, it completely trivializes the role of sys admins who are critical to any product/company. Good sys admins bring a lot to the table, just like experienced DBAs.

Edit; wow either everyone really hates sys admins and dba's or prefer "adminless", any down voters care to explain?

In truth, I don't think the name 'serverless' will stick in the long term, there is just too much animosity for it. The useage here by AWS is the first time I've seen it in a couple of months. Anecdata, but I think most would admit it's not very common.

As with many positions, there's a middle ground. I don't expect people to be able to dive in deep in to the innards of MSSQL and understand all the nuance between types of indexes and how different hardware choices can impact said index types. However, when working with "sr software engineers" who are responsible for SQL, I do expect someone to be able to set up a local test database and create some tables with sample data to demonstrate an idea (in whatever tech they choose).

I would argue that "sys admins" - in the form of dedicated personnel - are not "critical to an product/company". I know plenty of smaller companies who are successfully bringing in profits, making payroll, etc, but do not have any sysadmins employed. At some point, they will need those skills (and probably stronger DB skills) but these aren't always critical to every project/company/org. Perfect is the enemy of the good.

EDIT: middle ground.

I've seen one team of devs in particular do a really nice job with their sql database, but more often than not dev teams trash their schema and databases, if they're using sql at all. They create rdbs that are not normalized, don't have foreign key constraints, too many indexes (index on every column to get this dashboard query to perform! I've seen this a sad number of times).

Yeah sure sys admins and dbas aren't critical, but if an organization values what they can do, they can multiply the productivity and effectiveness of the app and product teams.

Specifically, features are faster to implement because the schema is not jacked, the app is responsive and stable because the data is normalizesd and indexed for the access patterns, data is consistent. Customers are happy.

Similar for the network/server side for sys admins.

No doubt there's a potential for abuse, and there's middle grounds to be had. I've also caught hell from a PM for a project being 'late', even though I had 0 control over actually getting DB changes in, because the DBA was a) on vacation, then B) sick, then C) backed up on other work. But apparently, it was my team's fault that the project relying on a SQL database was not launched "on time" (a deadline I had no hand in making, nor did I agree to either).

The policy of "only DBA can make any changes to anything, and all schema changes have to be discussed, reviewed, vetted and approved by DBA" has benefits, in some situations, but also problems.

I had a DBA question why I needed pagination. "No one has ever asked for it before, and never needed it, and I think you're building your application wrong if you need that". After a few weeks of contentious meetings, we got hand-rolled stored procedures for each specific table/query, but they also took days to get to us.

But, hey, you know... at least the tables were normalized and we had "proper" indexes. We just took weeks to get done what should have taken a few hours to prototype (because, during the time we were building the tool, the team we were building it for ended up buying some third party service because we were taking so long).

We've all got war stories of incompetence on all sides (dba, dev, pm, whatever). This is why I advocate "middle ground". I trust a DBA who's actually done a bit of raw coding in their life. I trust a developer who understands the basics of SQL and DB workings (again, 'basics' are fine). I trust the estimates of a PM who is engaged with the team on a regular basis. I trust the views of a business analyst more if they actually show up to meetings and listen to the parties involved.

It's called serverless because, for all intents and purposes, you don't know or control:

* how many real or virtual servers are running your code.

* how the servers were provisioned or setup.

* how to access the servers (either via SSH or programmatically), either than through predefined APIs.

* what happens when the servers break.

* what causes the servers to disappear.

* etc.

The "server" concept has been abstracted out of the equation and you're no longer required to think in terms of servers. (there is one exception: RAM usage is still something you need to predict for AWS Lambda.)

Instead, you're thinking in terms of limitations and usage of the service.

With the above said, serverless has a bit of journey to make. The toolchain is growing and the workflow of local development, testing and deployment is still a work in progress. I feel like it's a great time to jump in because there is a lot of exciting work to do and a good foundation to build on top of.

If the goal is to have a black box that we just send apps to and they just work, I propose a new buzzword: "black cloud".

These were already the promises of "the Cloud" until everyone started calling their Raspberry Pis at home a "cloud".

Now the same thing has got another stupid name: Serverless. I wonder what the same stuff will be called two years from now.

Yes, services (such as AWS S3) that could be considered serverless have existed for some time now.

What has changed is that the suite of services now exist to fully enable an application to be (almost) completely serverless.

Similar to micro-services, people will overuse the word and it will seem like a fad. IMO, it's more than a fad. Once the toolchain is mature, it will become the default way of building applications.

S3 is not serverless. Just because the implementation details (i.e. how servers are provisioned) are obscured from the end user doesn't make serverless.

Web 3.0 is truly serverless because your application lives on a decentralized p2p cloud.

Ethereum/Swarm(or IPFS)/Whisper is an example of a serverless p2p stack.

You may as well call the service they're selling "managed", because that's what it is.

That's not how the term serverless is being used most places. See first comment I made. It's not being without server. It's about not thinking about the server.

That doesn't make the name any less stupid. It's exactly like calling automatic cars "gearless" because you don't need to manually change gears.

It was "web based" before that.

We still run and manage our servers and save a metric ton of money wrt. "cloud" offerings.

When "cloud" or "serverless" will be cheaper than managing your own dedicated servers, then it will actually be useful. Until then, it's just marketing.

In my experience a dedicated server will be cheaper most of the time. I'm using Hetzner for most of my customers (small & medium-size companies) and for several services offered by Amazon a dedicated solution is just cheaper. I always calculate the prices beforehand for several scenarios and self hosting scenarios are almost invariably cheaper (storage, computing etc.). This does NOT mean it's better. Hetzner's servers are in Europe, they're not infallible (but usually they replace the hardware within 30 minutes or so), you need more time for the initial setup than with AWS, and obviously you can't scale them up in the same way. However, they're cheaper.

Marginally cheaper? In the statistical sense - each one is physically cheaper. But if you count managing them yourself, backing them up, fixing them when they break? Count the room they take in your house/office? If you have enough, count the salary of the person hired to install/manage them as you expand?

My experience is that you need a competent person in each case - whether the data is stored in S3 or on a dedicated server, whether you use EC2 instances or doing the job on your own server. For something like 40€/month you get Core i7, 32 GB RAM, 2x4TB HDDs, 1 GBps port and 30 TB included. In this 40€ the cost of storing the server, cooling it, power, etc. is included: https://www.hetzner.com/dedicated-rootserver/ex41 When things break, they repair it. In my case, they usually break once a year - sometimes the PSU, sometimes a hard drive (no a problem with RAID 1 already in place). It all depends on your needs.

Yes, I was referring to Hetzner too.

Both "cloud" and "serverless" are cheaper if capacity needs are opaque (high growth or unpredictable swings.) If you have predictable capacity needs, I agree that dedicated servers are a better value.

It already is for some of the things I'm doing. I have a lot of data in s3 and process it with lambda, meaning I can run a bunch of things I want very quickly by starting 100+ concurrent processes with virtually no management time from me, and it's cheap.

It's interesting how most of the responses to this post agree that "serverless" isn't literally what's happening but agree to that name and say to get over it.

It's akin to someone saying it's "free" because you don't have to think about the money, e.g. you pay with a credit card.

Perhaps the name it should be called is adminless or backend as a service. In any case, there's probably not much one can do about the name at this point.

> Perhaps the name it should be called is adminless or backend as a service

What's odd is that we already have "infrastructure as a service", which is generally what this is. An entire infrastructure to run your code, without having to set it up (although you still need to configure logging to get useful data in most situations, it seems).

Reminds me of the following meme:

#define TRUE FALSE //Happy debugging

It actually has lead to confusion before when I assumed that someone I was talking to knew what this usage of "serverless" meant. And it was only 15 minutes of talking that we realized our conversation had wildly diverged and neither side knew it.

It's not only a misnomer but the term is not needed. We've had SOA, web services, microservices, now serverless. I'm not saying it's all hype. It's rather a steady, lasting a few decades, transition towards outsourcing by encapsulating complexity into services. For me we've just arrived to the point where web services are mature enough so they can be consumed directly from the browser.

Amazon goes to the extent to fully explain in the very first two sentences: "Serverless computing allows you to build and run applications and services without thinking about servers. With serverless computing, your application still runs on servers, but all the server management is done by AWS."

"Serverless" had no previous meaning - it's not like Amazon bastardized an existing term. The word will ultimately be defined once people expect it to mean something specific. Personally I like Amazon's use of the term here.

A recent similar example: the word "performant". The number of stubborn people who screamed "performant isn't a word!" was ridiculous. Everyone understands the intention behind the word "performant" without needing to have it explained to them. The introduction and wide adoption of a word is exactly how new words are folded into language. Language is fluid! Language has never been static and inflexible, and pouting because we have extended the dictionary over and over again for thousands of years is frivolous.

Not just peeved, but confused.

"With serverless computing, your application still runs on servers"

So it's not serverless? Why are you calling it serverless?

Because server has become a synonym for "Ubuntu pet machine that developers SSH into to paste random commands from Stack Overflow". People who do that are the target audience of "serverless".

Also people with different requirements. I like being able to drop a load of files on s3 and have a few hundred processes start automatically, run and store the results elsewhere without having to ever worry about disk space or managing a fleet of servers which I want running for no more than a couple of minutes.

The very first time I heard "serverless" I thought P2P, but even though I agree somewhat with what you said, think of it as serverless because you don't have to manage the servers yourself.

I am. But this is just another 'shiny new thing'. It's not that it doesn't have it's place or function, but it's not as 'special' as it's presented as either. Back when you delivered your stack of punchcards, you were practically serverless too. You didn't know how it was going to be loaded, who would do it, where the machine would be, of how to get in to do things yourself. It's just code in, results out.

This practically fits in the same boat as docker...

"Just-in-time server" would have been much more descriptive and accurate as a term.

I hear you, but to me this is like people getting upset over hoverboards ("But they don't hover!!!"). True, but it's convenient shorthand and pretty much everyone understands what is really meant.

Not peeved at all. Actually I find the persnickety language-lawyering far more irksome.

It is even specifically incorrect to claim that AWS lambda functions always run on servers; they have at least three distinct execution environments, one of which is IoT devices via AWS Greengrass another being inside the Cloudfront CDN. It's also a stretch to suggest that the primary execution environment for AWS Lambda is a server device; that is not AFAIK specified anywhere.

So, although the term itself may annoy you, the counter-claim that "it must be servers" is a demonstrably false assumption.

Agreed. When I first read the term, I thought it was about some P2P service.

Why not call it "hosted" or "virtually-hosted" instead?

Serverless term is a little bit confusing at the beginning, but it is the same thing as saying that WiFi is wireless.

WiFi can do without a wire where it matters.

A server cannot do anything without being a server.

A mesh network can be wireless ;-)

Serverless refers to your workflow & division of responsibility, not the literal stack. Personally I think there are enough things to be peeved about in the world without adding this.

I'm agreeing with you, and their own text does too

I quote: "Serverless computing allows you to build and run applications and services without thinking about servers."

Serverless clearly is not serverless.

down voted edit: LOL

Yes, i expected it to be something akin to a peer 2 peer client, where one user hosts it for another. Stopped reading when AWS showed up.

I am a believer in "Serverless" and that it will play a primary role in a large portion of developers' lives... in the future

My experience with servless is that while this may be true at a certain level:

> No server management

I feel like in Amazon's current toolset, you are MORE aware of "servers" than you ever have been before. It's just abstracted into a different layer (cloudformations, etc). The boilerplate for severless projects it's a complete mess, imo.

Besides that, the Develop/Test/Deploy/Manage lifecycle is really difficult to reason about. I would hate to be the one on call when a serverless service goes down and I have to figure out what's going on!

I look forward to Amazon releasing more tools (or cleaning up the ones they have) to make Serverless a breeze to work in.

[EDIT] clarification of a couple minor things

That future is being created, you're probably just less aware of it than you think.

Serverlessconf just announced their NYC conference, expected to be the largest yet. If Austin is any indicator, it will be huge. [1] Tim Wagner at AWS likes to spout the stat that billions of financial trades are already being processed per day on AWS Lambda. The "serverless" market is gigantic and growing rapidly.

And then there's companies like StdLib [2], where we've built an abstraction layer on top of serverless architecture that turns remote procedure calls (and APIs) into first-class citizens of your development environment with a single package and allows you to ship applications without ever worrying about infrastructure. We just closed a $2M seed [3] and are announcing some transformative partnerships shortly. We're tackling some of the exact issues you have problems with, and we're not the only ones.

The future is already here. It's just not evenly distributed. ;)

Disclaimer: I am the founder of StdLib. :)

[1] https://nyc.serverlessconf.io/

[2] https://github.com/stdlib/lib/

[3] https://techcrunch.com/2017/06/27/stdlib-just-raised-2-milli...

Oh, I know it exists, and I know tons of people are using it.

But like I said, I don't think that the tooling is there right now for mass migration (or anything like it). It's really difficult to test/debug. It's difficult to dianose issues. It's difficult to even set up a "Hello World" API Gateway that uses lambdas. It's painful... as are all new technoligies.

I guess what I mean to say is: I look forward when I just jump on AWS and start using it for a production app, and the boilerplate and amount of config files I have to maintain drops.

I'm also aware of the tool called "serverless" ( https://serverless.com/ ) which is also a step in the right direction.

Not trying to be spammy here, but I want there to be awareness that there are startups working on tools to address these gaps. Our startup, IOpipe[1] is working on one set of tools to ease development, debugging, and instrumentation for serverless applications. Aside from Stdlib and ourselves, there are others working in areas like security and CI/CD as well. These are early days, and tools will soon become abundant, but at least there are a handful to try out today.

[1] - https://iopipe.com

Never tried AWS Lambda but Google Cloud Functions was trivial to setup for HTTP triggers.

Why are posts like this being downvoted? Is t because it contains self promotional links? I think the post is informative and adds value.

dang, I think there should be a feature to add an optional anonymous and private comment to the person when you downvote something, to let them know why (but with no arguments).

As developers we're allergic to marketing. Well, most of it. So when I make comments like this every once in a while I anticipate a bit of blowback. This is also a really competitive space with a lot of new players that check HN frequently - so keep that in mind.

I can tell you it's pretty difficult as a founder to draw the line around self-promotion; on one hand, you don't want to be an ass, and on the other, you're genuinely excited and passionate about the future you're helping to create and have personally poured your blood and sweat into for thousands of hours.

I hope that "real recognizes real" at some point in the communication chain and we're able to maintain that with our developers. I appreciate your post here, definitely.

I don't know about other readers here, but personally I would _encourage_ self promotion. This is a YCombinator site after all. As long as it remains on topic (which your comment most certainly was).

I think the ease at which a VPS is configured (and scaled) is underrated. I mean you can literally install your tech stack with a few commands that you can copy-paste into the terminal and upgrade it with a few clicks.

Plus working with a command line just seems more "right" than clicking around in AWS backend.

In principle I really like this way of developing, and especially prototyping, but as it stands right now Google is doing a significantly better job with their tools than Amazon.

Amazon got the same guts, but their presentation of these tools is horrendous. It's aimed at the highly skilled developers who would get the concepts in a blink, with the only problem that these are the same people who can spin out servers with more pleasure and probably in the same amount of time.

Google meanwhile, with their purchase of Firebase, makes some really appealing tools that are not just easy to use, but also easy to understand. Besides, their dev outreach is quite stunning, and so is the email support.

Would love to see Amazon compete, but they have a long road ahead.</2c>

Firebase is fantastic and that's because they built their toolset and UI before being acquired by Google.

They recently Google-ified their website but it's still less of a mess than Google cloud console (which feels like navigating a helicopter's dashboard).

First impressions matter and I think Firebase nailed it. The website presents the value clearly while also allowing you to get into the weeds if you need to. They ought to put their design team in charge of the rest of Google's cloud platform.

Agreed. Google cloud console is a mess. In 5 years Firebase acquisition cost would be considered peanuts for the value they've added to Google.

The value in serverless is not the serverless itself, but the ecosystem. If you've already got petabytes of data in AWS, you're gonna use Lambda. It's true that Google will win the truly greenfield serverless applications, but I suspect those are few and far between.

In most cases people are trying to enhance what they already have which means needing access to what is already there.

> Would love to see Amazon compete, but they have a long road ahead

Amazon is absolutely dominating this space

> It's aimed at the highly skilled developers who would get the concepts in a blink,

Do you have any advice on how we could make this stuff more accessible to new developers?

When you say the presentation do you mean the overall marketing, the UX, or just the CSS?

All of the above. AWS is the Google Cloud right now, but it's missing the "Firebase" equivalent.

I know a ton of people who have no problem spinning out an EC2 instance to scrape the web for all their needs in a heart beat, and yet I don't know many who just want to make software for people, without all the complexity of setting things up.

Look at Firebase, they have "Authentication", "Database", "Storage", and "Functions". If I want to Auth users into my app, it's quite literally a one line of code. Meanwhile Amazon has "Cognito," which requires setting up identities, rules, connecting it to other AWS services ... head explodes.

That's a small example, but AWS is built for some serious enterprise business, and if you want to make something like Firebase, you need to repackage it all, and dumb it down to a simple use case. Run whatever 265 services are necessary in the background, but give the user 1 thing to worry about.

I fully understand that would be really hard to do, but that's the point. Gotta do the hard thing for the user, and they will come.

As far as UX/css/visual, it's all of it. Like another commenter mentioned, in order to make things pleasant you gotta move away from the AWS style guide and towards something unique and friendly. Right now the entire AWS website look like it's been built in a spare time by a sys admin (because it probably has been).

IMO it's okay to make "AWS Light" a stand-alone offering, like Heroku, but that means you need to commit to maintaining such a service, and from what I hear through the grapevine Amazon is quite happy to be the piping for the internet, without having to run the consumer side of things.

Thanks for all the insight!

Have you seen lightsail or codestar?

I think AWS needs a good UX designer. I find that using AWS can be overwhelming at first. Here's a few suggestions:

1. Take "Amazon" out of every product name. Have a look at this list for example: http://docs.aws.amazon.com/general/latest/gr/aws_service_lim... This adds nothing but clutter to the page.

2. Stop calling everything "Simple". If it's simple, people will be able to tell for themselves. Calling things simple potentially makes people feel dumb if they have a problem with it.

3. The sheer number of offerings (over 18 groups with multiple items) on the "Services" tab of the AWS management console is overwhelming. I'd have a designer see if there was a better way of organizing things.

Sorry what's new about this? Aren't all the pieces existing AWS services? They've just put it in a nice graphic with the architecture drawn out.

Not saying I don't like the architecture (actually think it's quite useful for many scenarios). Not sold on using DynamoDB (I'd rather use a traditional SQL store).

I really agree with you on this one, my acquaintances that have actually used this, use it for running bulk jobs that are triggered by S3 changes.

I wanted lambda for a bulk data processing task that would have been a nice use of it, but the 5 minute max on a process wasn't going to work for my use case. Maybe someday I'll find a use for it

Is the task not splittable?

I had to use lambda at work to import files from s3 ranging anywhere from a few megs up to 10-20gb. Ended up using two lambdas (one for creating byte ranges and another for processing those ranges).

Amazon Lambda is like Microsoft Windows was in its early stages. It's a fast-growing, closed/proprietary system for running apps.

I wouldn't be surprised if it achieves a near-monopoly for a while... But I think that eventually more flexible open source solutions will take over. Open platforms like Docker and Kubernetes will likely replace Lambda just as Linux replaced Windows on the server-side.

> I wouldn't be surprised if it achieves a near-monopoly for a while...

Are you serious? Every major player in the market has a more or less equivalent offering. They started appearing within weeks of AWS Lambda's launch.

https://cloud.google.com/functions/

https://azure.microsoft.com/en-us/services/functions/

https://www.ibm.com/cloud-computing/bluemix/openwhisk

There are also a number of open source projects emerging... to support migrating between providers to reduce lock-in, or to roll your own service:

http://openwhisk.incubator.apache.org/

https://github.com/spring-cloud/spring-cloud-function

Just because these others exist doesn't mean that Lambda cannot be a monopoly. Minix was around when Windows had a monopoly, but Minix never had any meaningful market share.

> Open platforms like Docker and Kubernetes will likely replace Lambda

I am not sure if Docker/Kubernetes are comparable with Lambda. But currently there are some attempts to develop an open source alternative to Lambda and other proprietary FaaS (Function as a Service) platforms like OpenWhisk for Cloud Foundry: http://openwhisk.org/

True, not directly. So it's not as clean a comparison as Windows vs Linux so I meant it more in terms of the ability of one to replace/supersede the other.

Thanks much for linking openwhisk, good to know about it.

I don't think Linux ever replaced Windows on the server-side. Rather, Windows never made serious inroads into the server-side.

Or perhaps I missed the point of your last sentence.

> I wouldn't be surprised if it achieves a near-monopoly for a while.

I wonder why Google is so passive in this regard; sometimes I think they have an aversion to honest money and real products.

They've had App Engine for many years. They're the pioneers in this field, if anything.

They have their own Function As A Service offering:

https://cloud.google.com/functions/

Is there any evidence other that actually backs the notion that you save money on a serverless architecture? As far as I can tell, it feels like once you use this kind of mechanism, you're tied to AWS for the foreseeable future.

I did this analysis in my (admittedly crappy and rushed) pycon web talk - in some cases you can save a lot of money. In other cases you'll pay more. Skip to the 20 minute mark. Also I work for AWS so general disclaimer that I'm biased.

https://m.youtube.com/watch?v=F8-y_d7l-2c

An interesting thing to note is that efficiencies in this space only increase. Which theoretically lowers prices. You also get some pretty rapid and massive parralellization when you need it. The pywren project has some insightful examples and benchmarks of teraflops of compute and 10s gigabits/s of data arriving as part of a single function call. It's a different paradigm that will transform a lot of workloads but not all.

It's hard not to get swept up in the frenzy around it.

Good talk! But how would you go about creating something like graphql on AWS lambda? Are you aware of any tutorials?

- watchout for latencies (multi-zones apps) time of your lambda functions.

- keep your lambda functions warmed up

- node has better warmup time than java lambdas (not sure of python)

- memory size impact of lambda functions (negligible in most cases)

- manage lambda timeouts

- dynamodb latencies are negligible

- api gateway typically does not introduce latencies

- multitenancy challenges with single store of dynamodb

> node has better warmup time than java lambdas (not sure of python)

Python and node are both sub-second, compared to Java's 10+ seconds.

> api gateway typically does not introduce latencies

I haven't checked my function thoroughly yet, but I think API gateway introduce quite a bit of latency (at least in my case). My maximum invocation time is 600ms, according to AWS Lambda monitoring tool, but network request takes around 1s (checked in chrome dev tools).

Also, worht noting is that my code is hosted in the us-east region and I'm based in Europe. I'm not sure how much latency this introduce.

>> Also, worht noting is that my code is hosted in the us-east region and I'm based in Europe. I'm not sure how much latency this introduce. Very much possible, if your regions are different.

Probably about 100ms or more on each request (to and from). Slower depending on location and network conditions.

Yes very much possible if you are requesting across zones. I did extensive testing within zone and couldn't notice anything more than 2-3ms.

Amazon wants to control markets by leading in with "convenience" factor but they will sheist you.

Buy stuff from Amazon... but for Pete's sake don't make them a core project dependency for your software projects. You only have yourself to blame when they start ratcheting up their prices.

AWS is the system architecture of the web, full-stop. Well, a system architecture, alongside Microsoft Azure and Google Cloud.

Avoid them at your own peril and detriment to your ability to execute as a business.

With the exception of a few masochists, we don't write software in machine code anymore. Same will be said for cloud infrastructure (actually, it's already there). Breathe and accept the future, focus on building what's next and / or adding value to your business.

Right now I spend $240-600/mo for 192TB of bandwidth. I just used AWS's calculator and they charge $38,876.48/mo for the same thing.

I don't subscribe to the theory that this is "the future".

Indeed. It's a big cost escalator. We have split architecture across two DCs we own and AWS. AWS is a bad deal when you get to our size. If we moved our DCs entirely into AWS we would literally triple costs overnight. On top of that, once it's in AWS, a lot of the services that they provide aren't portable. You're stuck and it's expensive to unstick these. The tooling isn't very mature either. You'd be surprised how difficult it is moving 22TiB of file storage to S3.

The future is bare metal IaaS with something non-provider specific that sits on that as that is 100% portable between Cloud/in house. Docker/openstack that sort of thing.

>You'd be surprised how difficult it is moving 22TiB of file storage to S3.

Really? I deal with this daily. Can you email randhunt@amazon.com - if you're genuinely having or had issues moving 22TiB to S3 please LMK as that's abnormal for our customers and I want to fix it for you and others.

Thanks have passed your details on to our expert in this space.

For the public record this was mainly down to the problem of client reliability and migrating data live when there are 8,000 people hammering it with reads and writes. We went for a read/write through system and background synchronisation. The latter we had real reliability problems with and the upload performance wasn't great.

Also ROI didn't stack up in the end versus our SAN so we canned it.

Ok, if you guys pursue something like this again definitely check out something like storage gateway. It can help reduce the load in a live migration scenario like this.

The people that run their own infrastructure long ago realized that holding the key to mass consumption is the key to the control of the web. That's the thing they're all actually competing on. Good luck competing with them on it when they're controlling your rates. Cheap in, expensive out.

Imagine what would happen to AWS if more companies practiced the Amazon Leadership Principles [0]

Frugality

Accomplish more with less. Constraints breed resourcefulness, self-sufficiency and invention. There are no extra points for growing headcount, budget size or fixed expense.

Because you know Leadership Principles aren’t just a pretty inspirational wall hanging.

[0]https://www.amazon.jobs/principles

Look at the cost a different way: your data is clearly important and you just saved having to hire an ops person to help manage it part-time.

I get that this isn't reality though. Once you provision something the amount of maintenance is minimum if done well.

The cloud will look different in the future. Adopting the locked in model puts all of your eggs in one basket. What you gain in ease you lose in flexibility and cost while increasing your risk

If you're a startup and use AWS, and face a competitor that isn't, chance is you're going to be blowing money on infrastructure 2-3 times faster than your competitor. For some companies that won't matter - if e.g. your hosting cost is dwarfed by your development cost - and then it may be worthwhile to pick them.

For others, e.g. if bandwidth is a large part of your cost, picking them will mean your competitors who go with other providers will be able to sell well below your cost and still have a healthy margin.

Avoiding them (and Google Cloud and Azure) is often essential if you want to survive.

That's just silly. The internet was supposed to have no single point of failure. Now the Big Five have centralized everything. Why do you need to build centralized services on giant AWS server farms?

Unfortunately life and economics have no concern about the initial intent of anything, only the current utility.

Systems, at scale, especially when run by biological processes (read: all man-made systems), have a tendency to centralize. Economies of scale dictate that this is just more efficient. We don't have to do anything. The "evolutionary reward" (i.e. your business thrives and moves quickly) of building on AWS far exceeds SPOF issues for small, medium, and most large players. Yes, we get fun references when S3 goes down [1], but it's not as bad as literal water pipes taking down your webservers like what happened with Stats Canada [2].

The fact that Azure and Google Cloud exist maintains a competitive market. I liken it to Darwin vs Linux vs Windows. Optionality, but fundamental components of the cloud.

[1] http://funender.com/wp-content/uploads/2017/03/amazon-aws-is...

[2] https://twitter.com/StatCan_eng/status/873285710094233603

>The "evolutionary reward" (i.e. your business thrives and moves quickly) of building on AWS far exceeds SPOF issues for small, medium, and most large players.

Very well put. Couldn't agree more.

Can't the same argument be made for statism, against anarchists and libertarians?

I've used AWS since pretty much the first year they offered EC2 instances, and in that time, I believe their costs have only gone DOWN over the years.

Not just EC2 - we use S3, Glacier, Elastic Beanstalk, IoT, DynamoDB, RDS, Lambda, VPC, CloudFront, CloudWatch, Polly, Rekognition ... and I don't think I have ever seen a price increase /hr or /Gb in all that time.

That may be true, but the only reason they're not increasing their prices is that their prices are insanely high to begin with. E.g. their bandwidth prices are about 40 times as high as what I'd pay if I ever reach the included cap for my servers.

Disclaimer: I work for AWS

Computing / storage tends to get cheaper - even adjusted for inflation.

AWS has decreased prices 62 times. I'm not aware of a time where their prices increased - (maybe mechanical turk)?

Are you?

In fact I'm not aware of any cloud vendor ratcheting up their prices (I don't consider Oracle a cloud vendor). I've seen misbillings / changing terms on google cloud that resulted, unfortunately, in a few specific types of workloads having increased costs... even then I'm pretty sure they addressed that responsibly... but I'm not aware of any vendor ever increasing costs... only decreasing them... over the past 10 years.

Is Amazon really a core project dependency for software projects that use them? If prices get jacked up, I don't see why a get obect from S3 couldn't be replaced the equivalent call to Azure/Google Cloud or even an open(3)? Yes, migrating projects is a pain, but there has to be a point where it makes financial sense, and if not, what's the problem?

Does that mean I shouldn't buy a car because they might decide to raise gas prices?

You might buy an EV because ICEs are worse for the planet.

Point being, you have a problem that needs solved (transportation, cloud hosting). You can pick options which mitigate downsides imposed by your personal values (environmentalism, cloud vendor lockin). You don't have to stop driving.

Yes. Well, either gas prices will rise or some other way of disincentivising private car use will appear, or we'll have runaway climate change, and it'll be your fault.

Mostly stoked about serverless because I won't have to deal with grumpy backend devs anymore

I'm stoked too, as it means frontend devs will finally understand why backend is grumpy about frontend.

they're still going to be grumpy about how to test and set up development

We're not all grumpy :)

Care to elaborate?

Typical front end dev drivel.

Am a backend dev. Feel the same way.

Isn't serverless just the present-day incarnation of timesharing?

There is very little "true innovation" in software these days, its usually a rehash of something from years ago, plus some fancy marketing.

Amazon has invalid 404 links to the tutorial sections on the main page.

"This workshop is broken up into five modules."

And most of those module links are broken too ;-)

Can only be viewed in a step-by-step mode.

Where are the 404s? I'll notify some folks to fix them. I'm not finding any but I'm also on mobile.

Modules in the list at the bottom of this page:

https://aws.amazon.com/getting-started/serverless-web-app/

are broken - but the links to the modules at the top of the page work OK.

This should be fixed now (shift + refresh)! The links went out missing the "modules" in the path. I think we're going to write a quick lambda function to test for broken links in any post. Anyway, I want to apologize for the poor user experience. We should have caught this!

It's great that AWS has a tutorial for serverless. Their docs can be a bit hard to get through.

If somebody is looking for an even more comprehensive guide to building full-stack apps with Serverless and React.js, I created http://Serverless-Stack.com.

It's open source and up to date with detailed screenshots and code samples.

I'm a little confused as to what the point of cognito is. Wouldn't users typically be managed by the application and data regarding the users typically be stored in the db? Why do we need another service for this?

In a microservice architecture, there's usually a users/authorization service. It makes it easier to have multiple services serve a single user pool. If you only have one public service then there's probably no point in having a separate service for users/authorization.

Has anyone used Zappa in production? What has your experience been like?

I have and I had no issues. Website had peak load of only a few hundred requests per second and was Zappa running flask. Not sure if you consider that production or not.

Disclaimer: I work for aws

Can I absolutely control my cost with AWS? I've read several horror stories about runaway costs for various reasons. Certainly the complexity of AWS, the fragmented nature of the service each of which seems a world unto itself make it hard to understand. Then there was a story about AWS changing a policy that ended up costing users $1000's. ????

AWS has pricing alerts so you can set limits to specific resources and it will notify you when it tips over. Not that it cuts off the service, you'll still be incurring charges, but at least you can know straight away that something happened.

There's free tier as well if you want to just try out without commitment

Has anyone used RDS from lambda? Don't want to use Dynamo but perhaps for some key Val store.

Hopefully we will see AWS release a managed serverless SQL db solution at re:Invent 2017. Like DynamoDB but for SQL.

> Like DynamoDB but for SQL

This would basically be the game-changer for building backends on lambda.

The absolute key and most valuable piece in most backends is the persistent datastore. I absolutely want to build functional stateless business logic on lambda, but I absolutely will not, no matter the gain from not having to manage servers, have my database be dynamodb or any other non-RDBMS, for any serious application in 2017.

Why not? Plenty of serious companies use DDB or MongoDb or plenty of other databases for their "serious applications"... this seems like a rule based on a bad experience. Would love to hear about it.

Why not? Well, a caveat: I will always use an RDBMS when the data is inherently relational. In a "serious application" (I realise the term serious is hyperbolic here and I shouldn't have used it) this is true most of the time.

If it weren't true, then of course I might consider using DynamoDB or similar. But I think these situations are few and far between.

I'm often wrong though and happy to learn about some counter examples if you have any / have my assumptions corrected.

There's Aurora which has scalable read replicas.

Yep, very easy with JDBC + APIs like JOOQ.

The "interesting" part is how to secure user credentials to login to the RDS instance, and manage connection pools etc, but it's not that difficult

> The "interesting" part is how to secure user credentials to login to the RDS instance, and manage connection pools etc, but it's not that difficult

You can run your RDS instances and your Lambda's in the same private VPC. It doesn't secure your credentials per se, but it does prevent anyone else from accessing your database with Lambda.

Sadly putting Lambdas in your dedicated VPC introduces cold start times of sometimes ~5 seconds. Yes, seconds.

The "problem" with putting Lambdas into a private VPC is that then you need to do NAT, which means permanent infrastructure (NAT gateways, failover, scaling...). It can be done but there are more headaches than with a pure serverless solution. Unless things have changed since the last time I looked at this stuff.

You just need a private subnet, not a whole separate VPC. You still need NAT to get outbound access, but instead of running a random EC2 instance for the NAT, AWS now has a NAT you can deploy with a click or API call. You still pay for it, but it's at least much easier to set up and there's no maintenance. I assume they have redundancy and failover and such built in also.

Not RDS, but we've had good results with KeyVal stores using RethinkDB running on a Micro EC2 instance from Lambda...

    > With serverless computing, your application still runs on servers,

...

Reply on news.ycombinator.com