
Serverless Takes DevOps to the Next Level - nlolks
https://www.infoq.com/articles/serverless-takes-devops-next-level
======
bpicolo
My real problem with serverless (right now) is that it just destroys your
ability to have an efficient development workflow. Unless you want to use the
really specific nodejs serverless framework, you're really in trouble. (As far
as I can tell, [https://github.com/dherault/serverless-
offline](https://github.com/dherault/serverless-offline) is the only offline-
API-gateway).

If AWS really wants to drive adoption of their more-proprietary cloud tech,
they're going to have to drive harder on local dev workflows. Google is doing
better here (e.g.
[https://cloud.google.com/functions/docs/emulator](https://cloud.google.com/functions/docs/emulator)
and
[https://cloud.google.com/pubsub/docs/emulator](https://cloud.google.com/pubsub/docs/emulator))
As someone who cares greatly about productive developer environments (it's a
reasonable portion of my day job), I wouldn't touch serverless right now.
Things slow down way too drastically if you have to push to the cloud to test
what you're building.

I looked into starting a new app using serverless tech just yesterday. I don't
really want to use nodejs on the backend (as I can use any language on the
backend, and JS is not the pick of the litter), so that left me totally
optionless unless I want to build up a bunch of infrastructure on my own (and
sometimes I enjoy that, just not my goal right now).

As usual, the death of devops is greatly exaggerated, the role will evolve
like any other. As the boring stuff gets easy, application complexity will
grow. There's really still a lot of boring stuff that isn't automatically
solved for you.

~~~
jt2190
> [Development] slows down... drastically if you have to push to the cloud to
> test what you're building.

This is accidental complexity, not essential complexity: We can keep our
source in the cloud and edit it there. We can move change sets between
servers, not whole files. (I get it that my current process, and probably
yours, rely on working locally, but that's just an artifact from a different
time.)

Amazon recently bought Cloud9, which is a browser-based IDE that edits remote
files. [1] It's also possible to to use an old-fashioned remote-session. (It
tickles me that eventually this will feel exactly like editing files in place
on the production server.)

[1] [https://c9.io/blog/great-news/](https://c9.io/blog/great-news/)

~~~
dbg31415
> I get it that my current process, and probably yours, rely on working
> locally, but that's just an artifact from a different time.

You say this, but... it's more of situation, "Do I trust all time and
experiences to date, vs. something relatively new?"

Every dev has a local, with current setup. So, does ever dev need an instance
of Lambda? It'll get crazy expensive to work on a team. We still need various
environments for code review, QA, content entry, hardening, UAT, etc. All
we're cutting out with Lambda is performance testing, right? (We trust AWS
will be perfect and if it's not perfect we call them instead of trying to do
anything about it ourselves.)

Dev, QA, Prod... those are your three basic levels everyone is familiar with
for every project. Seems like AWS just found a way to bill me for all three...
Hooray! =P Said mostly tongue-in-cheek...

I like the concept... but I'm hesitant to switch clients over to serverless
until it's a little more mature. I pay for the cycles, right? What if one of
the functions I upload to dev is just a poorly written loop? Whereas the dev
would catch that on his local, now I think I have to catch it in my monthly
bill... we still need tools to be able to verify the code we are putting out
before it hits the cloud.

~~~
bpicolo
> What if one of the functions I upload to dev is just a poorly written loop

Fwiw, timeouts are at least partly a solution to this already. Seems right now
you pay for invocations (at least on lambda), and lambdas are capped at 60s

~~~
dbg31415
Fair... still what about unintentional loops? I meant to update one record,
but oops now I'm churning through the entire DB?

A lot of tools out there are great... I think WordPress, and HubSpot, and
Marketo are great for what they do... but they all have an element of "use
this and you won't need a dev!" And it's just wrong. The number of just
horribly setup sites and email campaigns and personalization options that were
set up by non-devs that just don't work... or worse, sort of work but then
break in catastrophic and unrecoverable ways... I think this number is still
pretty high when people fall for the "we don't need a dev" line.

Anyway I mostly dislike the title of this post... DevOps won't be going
anywhere, we'll still need people who intimately know the systems and services
in order to achieve enterprise-grade performance. Small businesses can dive in
and think they are saving money... maybe it'll work for simplistic stuff, but
realistically you'll still need technical folks for any edge case situation or
scale.

Another small story... once I had one hour to meet with an angel investor, a
guy out in West Texas who had a bunch of oil wells. He wanted to meet at a
coffee shop near his house... Bunch of pickup trucks out front, no wifi, and
poor cell signal so I couldn't really use my phone hotspot. If I didn't have a
local instance, "Hey sorry it's all choppy and junky, it's the connection I
swear..." I wouldn't want to say that.

------
holydude
Say goodbye to mediocre programmers; ai is around the corner to write your avg
crud app.

Serverless is going to significantly reduce costs that were needed to make
mvp, prototype and so on. No sane business is going to rely on a single
solution hosted by gce or amazon. Yes you can be fearless you can try it and
maybe you can succeed but 90% of other businesses will still need to integrate
with thousands of components and infrastructure parts. Devops is not going
anywhere. In fact the demand will only increase.

~~~
FLUX-YOU
>Say goodbye to mediocre programmers; ai is around the corner to write your
avg crud app.

Oh yes, somehow only terrible and/or very large companies only manage to hang
on to very old technologies and projects. I mean, there are virtually no sites
using vulnerable frameworks and ancient password storage techniques any more.
Those were killed off as they were introduced, and the programmers who did it
the old way were sacrificed to some god or another. Mediocrity is apparently
the bleeding edge.

~~~
aries1980
AI was around the corner when I learnt LISP and analogue processor arrays 20
years ago. Still not here.

~~~
linsomniac
That's because they considered AI a nearly solved problem, so the brightest
minds stopped working on it. I can't find a reference to that statement, but I
recall reading it from someone credible.

~~~
mee_too
Complete nonsense. I've worked for the Pentagon since the middle 80's, it was
and still is by far the biggest consumer of AI. The brightest minds of the
80's just couldn't deliver a working AI system, despite the government
investing billions in LISP and Ada projects.

The same happened in Japan and Europe, their best CS people failed to deliver
the promised Prolog AIs.

------
zitterbewegung
No this should be: say Hello to ServerlessDevOps. From what I have seen with
disruptive technologies you basically start retraining or hiring people that
can manage both onprem and cloud. Serverless is just another strategy but most
blogs attempt to say "Oh this is a DevOps Killer". I remember heroku and
google app engine were supposed to do this and so far its just another tool.

But as a tool you can really do great things with it. It is a great match for
voice interfaces or notifications or even mobile backends. Also, inference for
deep learning networks.

~~~
intrasight
You are correct - Serverless DevOps.

Serverless actually makes DevOps fun and challenging - and especially if you
work on multiple cloud platforms.

------
obulpathi
With Google Cloud, Serverless has been a reality from 2015! And welcome to
Serverless to those coming from AWS.

Here is how Google Cloud achieves serverless. Ingesting Data: PubSub. Scales
to millions of messages instantaneously, no need to spin up and spin down the
capacity/shards (like as in Kinesis), exposes RESTful interface for ingesting
messages from anywhere (web/mobile ... ). If you want a high-performance
interface, you get gRPC as well. With RESTful interface to consuming messages,
you can connect PubSub to anything you want or trigger Cloud Functions / write
to storage / ingest to Stackdriver (Monitoring system) using managed services.

Querying Data: Big Query. No need to spin up a single server. Just write your
query in SQL and watch the magic of a thousand servers being spun up to serve
the query in a fraction of second and process a petabyte of data in a couple
of minutes. btw ... you can ingest data into Big Query in real-time and
analyze results within in seconds.

Process Data using Dataflow: For workflows that are more complex than SQL
queries to ones that need to be running continuously on streaming data.
Dataflow is the serverless version of Spark. No more running our of memory
errors, much fewer hassles with hotkeys, no more manual performance tuning of
buffers, no more cleaning up log folders. If you are using Spark, but have not
tried Dataflow, you are missing some serious magic.

Google Cloud ML for Machine Learning: Cloud ML is a hosted solution for
running TensorFlow jobs. No more manual hyperparameter optimization, no more
spinning up GPUs, no more scaling up the cluster size. It's all taken care for
you.

Container Engine: Hosted version of Kubernetes. I am sure, everyone is aware
of what K8 is and its capabilities.

I am from a Data / Analytics / ML background. The above was my reality of
Serverless since 2015. Google Cloud has serverless options for Web (App
Engine) / Mobile (Firebase), and other purposes as well.

Having done PhD in Cloud Computing and Big Data and I don't find
Infrastructure/Big Data a sexy problem anymore. To a large extent, it's a
solved problem. Building a data platform with a team of 3 people that can
handle 10+ petabytes of data is easy. What is on the horizon and unsolved yet,
is AI!

Would love to see if there are any other better/compelling Serverless options.

~~~
stonogo
> Having done PhD in Cloud Computing and Big Data and I don't find
> Infrastructure/Big Data a sexy problem anymore. To a large extent, it's a
> solved problem.

This kind of sounds like you've never managed a production system, sorry.

There's also the whole "how do you process and manage lifecycle for an exabyte
of classified/sensitive data" thing that nobody's nailed down yet.
"Serverless" is not the panacea people make it out to be; as usual, it's
marketing-speak for outsourcing ops, which isn't always feasible.

People who talk about "data platforms" in terms of size are like people who
judge coder productivity in lines of code. I guarantee your 10pb "data
platform" will choke and die the minute someone shows up with 10gb of
historical data and you have to get the timezones right.

~~~
obulpathi
> This kind of sounds like you've never managed a production system, sorry.

Don't be sorry. Instead, challange me with specific problems you have and I
will show you how to build solutions.

> how do you process and manage lifecycle for an exabyte of
> classified/sensitive data

The infrastructure for storing/processing data is in place. If you doubt me,
please go ahead and give the above-mentioned tech stack a try and let me know
if you still have any problems. Or give me a detailed description of what you
have to do and I will tell you how to do it.

> People who talk about "data platforms" in terms of size are like people who
> judge coder productivity in lines of code

Let me be more clear. I know how to build the infrastructure for that scales
of data. I am not saying that I will write the code for processing data. That
depends on what kind of data you got and what you want to do with it.

> I guarantee your 10pb "data platform" will choke and die the minute someone
> shows up with 10gb of historical data and you have to get the timezones
> right.

See my above comment for the answer.

------
nwhatt
> Everybody is a cloud engineer

Sure - but does everyone want to be? I'd much rather have 2 people on my team
get AWS certified than 10 people with google manage my AWS account.

Also want to point out that any kind of Infrastructure that needs to be HIPAA
compliant can not process any PHI in Lambda. Naturally, Amazon will overcome
that hurdle, but they just started signing BAAs for RDS Postgres this year.

------
specialist
Isn't "serverless" the (slow) realization of Sun's agent-based grid computing?

I bought into Sun's vision. So much so I was gobsmacked by AWS' strategy.
Which is genius in its own way:

Virtualize _every_ interface. Versus deploy self contained mobile code called
"agents".

Watching "cloud" computing evolve into "grid" computing reminds me of the
quote:

"Every sufficiently complex 'C' program reinvents LISP, poorly."

~~~
tjalfi
The last line is a paraphrase of Greenspun's 10th Law[0]:

"Any sufficiently complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of Common Lisp."

[0] [http://philip.greenspun.com/bboard/q-and-a-fetch-
msg?msg_id=...](http://philip.greenspun.com/bboard/q-and-a-fetch-
msg?msg_id=000tgU)

------
mschuster91
To be honest: it's a fad for startups.

Serious enterprise, with a need for data durability, consistency, auditing,
real IT security, regulatory conformance etc. won't touch that stuff with a
10-feet-pole.

Also, once you choose your provider, you're locked in into this vendor (be it
Amazon, GCE or Azure), while you can move your bare metal servers around to
whichever colo/DC fulfills your requirements.

~~~
bsenftner
I think it is lemming stupidity. Building one's own "cloud" is easy, and can
be one in a tiny fraction of the expense any cloud provider charges. The
mindless march to the cloud is a huge competitive advantage for anyone "brave"
enough to buck the propaganda and run their own hardware.

There is a breed of developer that is doing REST in C++, building services
that live in only a few hundred K, and a single physical server can
concurrently host thousands of such services for an expense of $75 a month,
running 24/7 with 16 cores and 16 GB RAM. The same capacity on a cloud
provider is exponentially higher for a single server.

You know that "fake news" idea? I think it has been manipulating developer
opinion for a while. The cloud does not make sense, unless you are a cloud
provider with a reason to sell that lie.

~~~
kuschku
Exponentially higher does not even cover it.

You pay several orders of magnitudes more.

I’ve run the numbers several times, going from

colo -> rented dedicated -> rented VPS -> cloud VPS (think EC2) ->
containerized cloud (think heroku) -> serverless (think AWS lambda)

is, on each step, at least a 2x or 5x increase in cost for the same
computational power.

I started out a few years ago with my hobby projects on Heroku, migrated them
to Digital Ocean, from there to OVH’ VPS, and now migrated them last year to
rented bare metal.

Every migration multiplied my available resources at the same cost, and it’s
definitely been worth it.

I did a price comparison of VPS and some bare metal providers over at
[https://gist.github.com/justjanne/205cc548148829078d4bf2fd39...](https://gist.github.com/justjanne/205cc548148829078d4bf2fd394f50ae)
and the result is pretty much just that. For 16$ a month I can get enough
performance to run services handling tenthousands of concurrent users if I go
with bare metal, or I can’t even handle a few hundred if I go with the
"cloud".

~~~
bsenftner
A few years ago, I got a deal on a cabinet at a colo, and then when one of the
research labs at USC dumped their servers for the cloud, and they gave me 17
servers. I'd previously custom built a 32 core, 32 gig server just out of
hacker interest, and between the USC servers and my previously owned hardware
I put together a 196 core cluster with 3 redundant ( dev, staging, live )
environments for my own playground, and similar setups for hosting clients.
Adding to and modifying the system for a few years, I had what would have cost
$96K a month at AWS, but was only $600 a month to me.

------
jMyles
I don't see how this is "goodbye" to DevOps. This seems to fit reasonably well
into the DevOps methodology in that it makes it even more plausible for the
people doing the dev'ing to do the ops'ing.

------
mdekkers
I love these kind of articles. Serverless? Some commenter here stated "Even
the network is software now" and a variety of related nonsense. Lambda and
everything like it runs on - gasp - servers. Networks have _always_ been
"software", running on some specialised hardware to make the packets linger
less in the boxes they pass through.

Serverless as a name is hokum. Serverless, or rather FaaS, as a concept is
extremely interesting though. However, if you are trying to sell it to me as
"now you don't need anymore sysadmins or devops, or servers" you missed the
mark. Most of time when I look at this stuff I come away with the distinct
feeling that what is actually being sold is just another way to lock you in to
a specific provider that has aggressively abstracted away the actual server,
giving you significantly less control and significantly higher costs, for non-
existing security.

I am not anti-cloud (I have been accused of that here a few times) and in fact
have happily embraced cloud technologies since day one. I was deploying VMWare
GSX Server in production around the time the twin towers came down, when
everybody told me I was an idiot, and it would never work.

However, servers are not going anywhere for the time being, whatever the
latest dev-fad is. Neither are sysadmins, or Devops. These magic functions
still need to run _somewhere_ and wherever that is, it will, by its very
definition, still be a server. The more something is dressed up in
re/misdirecting language, the wearier I am of it.

------
empath75
Every devops guy I know is really excited about serverless. I don't think it's
because they think it's going to get rid of their jobs.

------
menegattig
The serverlees concept is also being applied to other types of services, like
databases and data warehouses.

In this post below the company I work describes the reasons for a serverless
data warehouse and the trends:

[https://blog.slicingdice.com/why-a-serverless-data-
warehouse...](https://blog.slicingdice.com/why-a-serverless-data-warehouse-
ae3b00146c26)

(Disclosure: SlicingDice employee here)

------
iamryo
Oh man, can't wait until this takes off so we can clear out all the data
centers and use that space for something else.

------
wheelerwj
devops isnt going anywhere, its just learning a nee set of skills. you think
any front end developer is going to have a strong enough understanding of AWS
or Google Cloud to build and scale a serverless product? absolutely not. and
most backend developers won't either.

------
mgarfias
It's not serverless, it's just not your server

------
aries1980
Serverless does not make DevOps obsolete. It just make less of a must for
everyday team. Do you want to enter to Russian, Vietnamese, or an African
country in general? Then you will likely need devops.

