
The Serverless Revolution Will Make Us All Developers - jonbaer
https://www.nextplatform.com/2017/09/25/serverless-revolution-will-make-us-developers/
======
nameless912
As a developer at a company that's trying to shove Lambda down our throats for
EVERYTHING...AWS needs to get better at a few key things before
Lambda/serverless become viable enough that I'll actually consider integrating
them into my services:

1\. Permissions are a nightmare. You have to give both users trying to run
lambdas and the lambdas' service accounts some crazy permissions sometimes in
order to get anything to work. This is especially true with a lot of the "make
serverless easy!" libraries out there, which seem to want an IAM user with all
sorts of access that's against our normal security policy.

2\. Networking is equally nightmarish. We operate with lots of VPCs connected
to on-premise hardware and network infrastructure via DirectConnects, and the
only path out to the internet is through our corporate data center (again,
security requirements). Most Lambda-centric tools seem not to like this
arrangement, and often barf when there isn't an internet gateway attached to
the VPC. Moreover, especially in development environments we use relatively
small subnets, which Lambda can consume nearly instantly if a large volume of
requests come through. Finally, there's some secret sauce to running Lambdas
in VPCs that I still don't quite have down-it seems to only work half the
time.

3\. If the future of compute is serverless, then Lambda, Google Cloud
Functions, and whatever half-baked monstrosity Azure has cooked up are going
to have to get together and define a common runtime for these environments. I
refuse to invest in serverless until I know that I can run the same code on
minikube on my laptop as I can in <insert cloud provider here> because vendor
lock in is real and will bite you in the ass one day.

/rant

With reference to this article specifically, please, please chop off my hands
and pull out my eyeballs if cloud computing becomes yet another workflow
engine. I though we killed those off in the 90s.

~~~
alexasmyths
+10.

Lambda's are the unattainable Chalice.

The API Gateway that you have to go through is byzantine.

Then Route53, CloudFront, yada yada - AWS has become such a massive
bureaucracy - it changes so fast, documentation incomplete.

The other issue is the inability to keep Lamda's 'hot' \- as they often take
several seconds to load.

And of course easy shared memory and persistent file access.

Lambda's are simply not designed for use web-app folks - they are designed to
to back-end dev-ops and IT tasks.

I think it's been like 5 years now and they are still a mess, I really want to
use them, but I wont.

~~~
gaius
_Lambda 's are simply not designed for use web-app folks - they are designed
to to back-end dev-ops and IT tasks._

Absolutely. I see people trying to serve websites out of cloud functions.
Reminds me of the mid 90s when people ran httpd from inetd!

~~~
alexasmyths
Yeah - but I think there is a 'massive' business case that Amazon is missing
out on.

Are you PM's reading this?

Give us:

\+ Lamdas without the clumsy API Gateay (or at least a simple 'pass thru'
mode.

\+ Support direct integration with Express or whatever, so we don't have to
create Lambda-specific code

\+ Allow us to keep them 'hot' so latency is low.

\+ Give us a way to access some kind of persistent file storage with 'fs'.

\+ Same thing for shared memory.

If this were true, I would see a massive flood of people moving to Lambda's.

Nobody likes to have to manage Linux instances. We'd all rather something more
manageable and easy to use.

I feel we are on the cusp of this and I still can hardy believe nobody has
'got it right' just yet.

~~~
BoorishBears
\+ Lamdas without the clumsy API Gateay (or at least a simple 'pass thru'
mode).

You can call AWS Lambdas directly through the AWS SDK (or dozens of other
event sources like SQS, Timers, etc.)

\+ Allow us to keep them 'hot' so latency is low.

You can keep lambdas "hot" with periodic invocations, it's not standardized,
but it's a thing

\+ Give us a way to access some kind of persistent file storage with 'fs'.

There's also access to 500mb of data on /tmp. It's not always cleared after
each invocation of your function, especially if it's invoked multiple times in
succession, so you can use it as a "scratchpad" that provides some soft
caching under high load.

S3FS works if you just want to expose S3 through an 'fs' interface.

~~~
alexasmyths
That's helpful, thanks, but none of those are full solutions.

Even if they are accessible via a javascript api, we need them accessible via
regular HTTP for so many reasons.

'Periodic invocations' my gosh man, that seems like a big hack, requiring yet
another service.

I get that there is /tmp - but it's not guaranteed to be persistent. I wish it
were.

Anyhow - my main point is ... Lambda's don't seem to be designed for us in
mind :)

Thanks for the pointer on S3FS, I will definitely check that out.

------
fusiongyro
The same tired argument has been made every decade since the 70s, with mostly
the same cast of characters: artificial intelligence, English somehow being
used to specify the behavior, stock libraries of code, etc. I think we're
about as far from it today as we were when Prolog was a big deal.

The amount of incipient complexity in programming has been growing, not going
down. What's more complex, "hello, world" to the console in Python, or "hello
world" in a browser with the best and newest web stack? Mobility and
microservices create lots of new edge cases and complexity—do non-programmers
seem particularly well-equipped to handle edge cases to you?

The problem has never really been the syntax—if it were, non-programmers would
have made great strides with Applescript and SQL, and we'd all be building
PowerBuilder libraries for a living. The problem is that programming requires
a mode of thinking which is difficult. Lots of people, even people who do it
daily, who are trained to do it and exercise great care and use great tool
tools, are not great at it. This is not a syntax problem or a lack of decent
libraries problem. We have simple programming languages with huge bodies of
libraries. What's hard is the actual programming.

~~~
taneq
> What's hard is the actual programming.

I agree. There's a never-ending stream of things (remember Klik & Play?) meant
to make programming "easy for everyone" and they never manage to actually do
so, because it's not possible to take away difficulty without taking away
flexibility.

~~~
dropit_sphere
Well it's hard to tell; I didn't learn to code until college, but it seemed
pretty natural to me because years ago I'd used KnP and Logo. It's hard to
tease the causes apart---was programming easy to pick up because I had KnP, or
was I only able to benefit from them because I was that kind of person?

------
alexasmyths
"For example, seldom do we see brand new web applications delivered with a
traditional, server-based, single-codebase model. Increasingly, they are
single-page applications, using APIs and front-end frameworks, such as Angular
and React, to tie together functionality."

What?

I'd argue that most new startups launch something resembling a 'monolithic
back end' (granted probably on the cloud and leveraging other services).

Moreover, this has nothing to do with 'single page apps'.

------
jbb67
They call this 'serverless' and yet it's all about running thing on ...
Servers.

I think it's safe to say that if any individual or company uses the word
'serverless' they are either stupid or have been taken over by marketing and
can safely be ignored and ridiculed

~~~
plq
I've developed some resistence against marketing people talking nonsense over
the years but this serverless thing is ... some next level bullshit.

Just because I'm not maintaining my car's engine doesn't mean my car's
engineless! Just call it "managed cloud" or something -- calling it
"serverless" is nothing short of a blatant lie!..

~~~
zimpenfish
It's more like you're renting a car rather than owning a car - you'd be well
within your rights to call yourself "carless" then, no?

~~~
ben-schaaf
You wouldn't call someone renting a house homeless, or houseless. I wouldn't
call someone with a rented car carless. And I certainly wouldn't call a
service running on servers with an abstraction layer inbetween serverless :)

~~~
zimpenfish
> You wouldn't call someone renting a house homeless, or houseless.

I'd say "houseless" was an acceptable description. "homeless", ok, that
definitely doesn't work for a renter.

~~~
dragonwriter
> > You wouldn't call someone renting a house homeless, or houseless.

> I'd say "houseless" was an acceptable description.

“Houseless” would be a very strange description of someone with a legal
possessory interest in a house.

~~~
zimpenfish
> a legal possessory interest in a house.

I'm not sure renting gives you any "possessory interest" in the house, does
it? Can you cite some sources for that?

~~~
dragonwriter
> I'm not sure renting gives you any "possessory interest" in the house, does
> it?

Yes.

> Can you cite some sources for that?

[https://www.law.cornell.edu/wex/possessory_estate](https://www.law.cornell.edu/wex/possessory_estate)

~~~
zimpenfish
Cornell on US law doesn't really help me in the UK (not that you were to know
that) but there might well be something similar here.

Ta.

------
keithwhor
I mean... this is essentially our core thesis at StdLib [1]. We took a look at
"serverless compute" and asked, "what's next? Where does this model of compute
get us? How can this make the average developer's life easier?"

The easy answer was "serverless" represents the first step in enabling the
ability to turn remote function calls into first-class citizens of your
development environment. Since these "functions as a service" are auto-
scaling, self-healing, and you only pay for what you use, you can treat them
as disposable and regard them with the same level of utility as locally-run,
JIT-compiled functions.

The issue was, and still is, how the hell do you get there? Every provider has
a different implementation strategy (different runtimes, function signatures,
etc.), different platform offerings, and different business incentives for
pushing serverless compute. "Serverless", as it currently stands, is not
synonymous with "effortless" \- you must still understand nearly all of the
underlying HTTP infrastructure to configure it. To the vast majority of
software developers, the abstraction of "serverless" compute is just an
exercise in incidental complexity to save $$ on overprovisioning.

I don't think the real story of "serverless" compute is about cost savings to
avoid over- or under- provisioning. That's what I think this article gets
right. The story that (hopefully) will eventually be told is one where this
revolution, driven by cost-savings, was reshaped and reformed to allow
developers to attain mastery over the cloud as if it were merely an extension
of their local development environment. To get there we need rigidly enforced
Gateway standards, better ways to build, document, deploy and integrate the
functions we're building, and a hell of a lot more. We've taken the first step
towards this vision of the future with FaaSlang [2], our open spec for type-
safety, error-handling etc. around Functions as a Service - but there's still
a lot more to do.

[1] [https://stdlib.com/](https://stdlib.com/)

[2]
[https://github.com/faaslang/faaslang/](https://github.com/faaslang/faaslang/)

~~~
gizzlon
_" The issue was, and still is, how the hell do you get there? "_

Hm, too me personally it's: Why would I want that? My computer is fast enough
to for 99.9% of the stuff I want to run.. and for the last 0.1% it's not
_that_ hard to spin up a vm.

What am I missing?

~~~
keithwhor
You're missing that (1) this is about shipping code that other people can run,
or a company can run for others and (2) that 99% of the software developers in
the world just want their code to do a thing and not have to worry about
anything else.

It's not "that hard" to spin up a VM in the same way it wasn't that hard to
visit Blockbuster video. You shouldn't have to know how to drive or know
somebody who does to rent a movie. It doesn't hurt, it's a good skill to have,
it's fun to get out and practice, but if you just want to watch a movie, why
is it necessary? Think about building web services in this way.

A majority of developers we talk to agree that web development has gotten too
complex. It's too hard to solve simple problems. Problem is that it's
_everybody else_ that has made things too complex. In the same way you become
noseblind to a strong perfume, developers become techdebt blind to old
technologies they're the most familiar with, then complain about the smells
other people layer on top and around them.

The true innovations around serverless tech are coming from the ground up; at
StdLib, for example, we've reimagined web services as essentially JIT-
compiled, type safe, remote procedure calls. It means we're throwing out the
need to even understand HTTP or REST to build a webservice, but opens up all
kinds of neat opportunities and a new programming model.

Anyway... I could go on, but tl;dr is try StdLib out for yourself if you get
the chance. Our number one piece of customer feedback is, "I never thought it
[web dev, serverless functions, APIs] could be this easy."

~~~
gizzlon
Ah, it's basically an easier way to do FaaS? I read _" first-class citizens of
your development environment"_ to mean it's purpose is run your code on
another machine for your own benefit.

It's interesting. (I don't like JS for backend work so I'm not your target
market.)

------
flor1s
> Doug Vanderweide is a Microsoft Certified Solutions Developer: Cloud
> Platform and Infrastructure and a Microsoft Certified Trainer who currently
> serves as an Azure course author and subject matter expert for Linux Academy
> and Cloud Assessments. Follow him on Twitter @dougvdotcom.

Sounds like the author of the article has a conflict of interest.

------
hasa
Heavy futurism, well said, even bullshit. Mechanisms which would make the IoT
pieces work together do not exist. There is no "evolution" of internet which
would make this happen in the long term. Everything is designed by humans by
now. When robots are in charge on this planet, then I believe this could
happen.

------
CSDude
We use AWS lambda, and when our lambdas fail, and they are triggered by AWS
services asynchronously (i.e CloudWatch logs, S3 events), AWS does not care a
limiting at all, and calls our lambdas in a recursively increasing fashion and
it causes hundreds of parallel execution, which DDOS'es our internal servers
and we reach the concurrenct execution limit for Lambda, and all other our
lambdas suffer from one single failing function. Just a heads up before you
make use of "unlimited scaling" of lambda.

~~~
mankash666
Well - isn't this technically a bug in your lambda? If this were running on a
traditional server managed by you, it might still do bad things to your
service.

~~~
CSDude
Yes, but I could add a rate limiter, and If I try to do the limiting myself,
it would contradict the serverless approach

------
recursive
This kind of hand-wavy futurism never quite seems to actually happen.

~~~
theprotocol
The pie in the sky is really just a mirage worshiped by cargo cultists. I'd
much rather focus on more pragmatic and less pseudo-ideological approaches.
Don't deliberately try to change the paradigm just for the sake of it; just
focus on improving things that work, or finding new things that work (without
preemptively patting yourself on the back and calling your solution
revolutionary).

The apparent pressure to deliver a revolution seems inorganic and forced. It
looks like ambition, but I think it's more like hype.

------
z3t4
> All it’s going to take is the AI that can parse that statement and turn it
> into a workflow.

Or you write your own glue code. You would be surprised of how much can be
done with just copy pasting and gluing code together. The interacting API's
needs to be much simpler then today though. This is why I like Node.JS, here's
an example:

    
    
      // Siri, I want to make a web photo gallery 
      var photoGallery = require("photo-gallery");
      
      // Use pictures from Instagram with the hashtag #ashley30
      var instagram = require("instagram");
      instagram.getPictures({hashtag: "#ashley30"}, function gotPictures(err, pictures) {
        if(err) throw err;
    
        photoGallery.addPictures(pictures);
        photoGallery.listen({port: 80}, function serverStarted(err, conf) {
           if(err) throw err;
           console.log("Photo gallery now running on port " + conf.port);
        });
      });

------
codeonfire
Yes, imagine all my devices, home, car cell phone all sending my data back to
Satya. No thanks. Microsoft doesn't even try to hide it desire to put spyware
in everything. They are the spyware company now. Yes valuable insights will be
found...for Microsoft and partners to pound me for money.

~~~
willyyr
What makes you say that? Have you had a look at e.g.
[https://microsoft.com/trust](https://microsoft.com/trust) ? We* are not in
the business of selling your data. *I work at Microsoft

~~~
__warlord__
By that rationale, everyone should believe what politicians say then. I'm not
saying that Microsoft is doing something "wrong" with the data they collect,
the problem is the way they collect the data and their response (or lack of)
in open source communities when they enable telemetry even at the language
level.

------
singularity2001
computers generally being able to parse complex instructios as in the example
is akin to strong AI. Which is at least one or two decades way as others have
commented.

HOWEVER I do share the sentiment of the autor that some Revolution is in the
air and something is possible today. Maybe an assisted parser, where a human
and a computer co-operate to transform the mentioned instructions into some
kind of standard code.

That's why we are experimnting with the angle programming language [1]
"debuggale applescript for python that actualy works".

[1] [https://github.com/pannous/angle](https://github.com/pannous/angle) (lisp
for siri)

------
retox
Other people's servers.

