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 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 and 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.
I'm no IBM shill but OpenWhisk is at the least open source and can let you host your functions locally for the sake of testing and you can try to do some unit and integration tests using them.
Devops as we know it isn't going to die any more than sysadmins weren't exterminated by "devops." However, if you're still doing sysadmin like it's the 90s your business is probably too slow to compete against more agile, cost-effective players and you'll wind up being forced to exit or wind down. Furthermore, businesses that iterate very slowly hopefully have customers that will continue to be able to afford to pay them for such slow turnaround. However, I've noticed the traditional large, behemoth enterprises used to multi-year cycles for what takes most competent companies a few weeks are all coming under business pressures to iterate or lose customers.
I'm doing some serious kicking of tires with serverless, and totally concur on the lack of efficient development workflow. I told a colleague last week that my productivity is about on par with assembly language programming in the 80s, or even punched car programming in the 70s (I've done both). I know that part of this is my needing to create new workflow, but I am concerned that part of it is implicit in underlying model. I hope that I am wrong and that it's just growing pains. The good things about serverless are great indeed.
> [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.)
> 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.
> 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
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.
> We can keep our source in the cloud and edit it there
Even with this, it doesn't currently save you from code deployment for serverless functions. Editing in a remote-session doesn't help here, either. I have indeed developed via OSXFuse. That works fine (though none of the tools work quite properly together. Nothing detects file changes at the right time).
There are many other issues, but remote debugging is also a massive pain point, and in my experience devs are already somewhat prone to painstakingly printline debugging where other tools would be far more efficient. (PHP is sadly kind of the best at this as an artifact of PHP debugging being generally miserable.)
Yup. I've been doing nodejs and lambdas. (Don't ask.) It's the worst.
Note that I had totally bought into Java/Jini/JavaSpaces, I really thought that was the future, so have some preconceptions about all this stuff should work.
(I never grokked JXTA; I should go back and try again.)
> 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.
What do you miss from Kong?
My main problem with serverless is the unreplicable latency tests. The latency metrics are below the threshold so far but if not, I will have not much of an idea why.
I have no experience with Kong, so I couldn't tell you. I'll give it a try at some point. It does look like a better alternative to API gateway. Thanks for the mention.
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.
>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.
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.
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.
I think that's what he is saying. And yes it is an ultimate lock in. That's what I believe things like lambda are best for creating desired infrastructure, e.g. common ground, so provisioned VMs after bootstrapping might behave the same whether they are in aws, gce or on premises.
I think that's possibility A, and possibility B is that you could see ops and dev diverge into more separated positions with ops focusing on the network border. Or maybe multi dc becomes more tablestakes than it is currently (so: savings from traditional host-intensive staffing goes towards moving goalposts forward). We aren't anywhere near peak efficiencies, peak security, or peak redundancy yet, so we aren't talking about the end of the job, just the end of this job description.
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.
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.
> 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.
> 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.
> Building a data platform with a team of 3 people that can handle 10+ petabytes of data is easy.
I'd hate to see that server bill. I'm sure Google or Amazon would be happy to host that for you, at the cost of a full round of funding a month.
Point of reference: I worked for a company doing some basic ML analysis on the Twitter firehose; only a few tens of gigs a day. Their hosting costs were significantly over half of their overall operating costs (despite huge discounts, and including downtown New York offices), and they still hadn't gotten profitable when I left (they had actually gotten to the point where they were laying people off).
None of it was serverless either - it was measurably incapable of operating at the scale they required.
To me, the definition of Serverless is this: Developer writes code and the management of resources for running that code is taken care of by a Serverless platform. As a developer, I don't have to deal with servers, disks, networks, logs, metrics, ...
> As a developer, I don't have to deal with servers, disks, networks, logs, metrics, ...
Yes, until things don't work as they supposed to.
Disks and networks also don't matter if your application is simple. Disks are pointless if you don't keep a state. Networks will suddenly matter more when you start hiring its capacity.
If your application is simple, you can also run it on a single machine and don't care about any of the things you listed.
But just because those things were abstracted from you doesn't mean they don't exist and their limitations don't apply.
I emit logs. I mentioned that in my above comment as well.
> So your code assumes that the network/storage/DB are fault-free?
No, it does not assume that the network/storage/DB are fault-free, completely. It assumes they are fault free with the SLA limits provided by your Cloud provider. The software is written in a way that enables the platform to know about errors when then happen and remediate them. Like, when you build a website, you make the app serving layer stateless and choose a backend datastore that is replicated across regions and is highly available (like Cloud Datastore or Spanner). If your platform detects that a disk failed and your app is returning errors, then that instance is killed and an another instance is brought up. Very similar mechanisms exist for the above-mentioned data services as well for auto scaling, sharding, ...
If your Cloud provider can not guarantee the SLA's or shows a green sign even when the service is down, IMO they are not competent enough.
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.
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.
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.
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... 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".
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.
You're basically advocating the model similar to how WhatsApp grew. The truth is that most companies are willing to throw more money for delivering a result faster, and even the fastest C++ programmers cannot pump out a CRUD app and re-iterate as those using some random crap like Node.js and that's a fundamental reality of languages you have to compile and ship versus just modify in-place.
I think it's a great idea for bootstrapped startups to host their own hardware until they've got the capital to try to spend more for results faster. But again, I think the current software market primarily driven by an obsession of faster iterations even at a far greater up-front cost is what de-emphasizes your romanticized notion of development cycles and care for efficiency (which I personally fully support - I started in embedded dev and all this web stuff has been boring to me since the 90s).
The tooling is just arriving to enable as rapid a development cycle in C++ as with managed languages. I was having multiple issues, only optimizing portions of a traditional (W/L)AMP stack or node.js solution with C/C++ components until I found Restbed (https://github.com/Corvusoft/restbed). Now I can create a complete self-contained REST API server in a 100K executable with no (W/L)AMP stack or other infrastructure required. Compiling C++ is fast, and unlike the typical (W/L)AMP, node.js, or other "conventional web stack" one is not compiling and/or executing through gigs of data and executable - the re-compile and execute/debug cycle in C++ for Restbed is instantaneous on modern hardware, and the execution speed runs circles around any managed language.
Such a development solution is faster, consumes exponentially fewer resources, and is a great idea for much more than startups. You just need good C++ developers that also know the web - a bit rare right now, but the savings are too real for the situation to remain that way.
The other part of the equation is that good developers let alone good C++ developers are in very short supply in a market already dying of thirst for merely competent developers. Most large companies that need software simply will never be able to attract them, so you have to throw your net wider and accept the hegemony of Java, Python, Ruby, and Javascript.
I think labor economics fundamentally wins in the current market over any technical factors until we start approaching large scale systems by which time, ironically, the costs of high-overhead, low-LOC software infrastructure are far too great and you're like Facebook drowning in piles and piles of legacy code that people are scared to really tear apart just to save maybe 20% on the number of servers while still making hiring even harder.
Furthermore, a pet dating app founder doesn't really have any benefit picking C/C++ over Python, Node.js, etc. unless they are so under-funded they're trying to save $300 / mo on hosting costs in which case they can't even begin to think about paying someone in the first place. By the time you start hitting $2000 / mo in infrastructure costs where a solid C/C++ core on even AWS you'll likely be bringing in enough users that you could conceivably raise more funding anyway.
I'm totally a fan of writing C/C++ for modern software but if I'm in the driver's seat of a company I really can't expect to be lucky enough to find someone that knows what they're doing with modern C/C++ in that market. Heck, even in the super competitive yet lower-pay games industry most programmers aren't on C++11 or C++14 last I heard, so they'd still have to learn new stuff if I hired them for a random web start-up or big company.
Thanks for the hint - I'll definitely have a look at it. Compile it statically and you can run it on a bare Linux kernel (or on a container) without any dependency... reminds me a bit of Go.
Do you happen to know if there's a benchmark comparison (CPU usage, RAM usage, RPS) against nodejs and php (the code style of the example reminds me of Silex)?
> Building one's own "cloud" is easy, and can be one in a tiny fraction of the expense any cloud provider charges.
Yeah, I've recently run the math - 176 real Xeon cores and 1TB of RAM are around 70k€ (4x 2x22 core Xeon 2699 v4), while the same from Amazon costs a load more.
On the other side, it's the good old capex vs opex debate, plus you're going to need someone to do occasional disk swapping, worry about RAID setup etc. - all this is done by the cloud provider for you.
> The cloud does not make sense, unless you are a cloud provider with a reason to sell that lie.
It certainly makes sense if you have an architecture that allows you to handle the base load with your own bare metal but allows you to quickly (and automatically) add power via cloud instances.
My company is hardly a startup (16 years old), and we are in the process of converting a few of our processes over to Lambda and API Gateway (via luigi), with good success.
I wouldn't agree with the "You're locked in to this vendor" statement. Our Lambda code is just Python Flask apps and our "if Lambda is down" plan is to run the services from our data center via uwsgi serving the Flask apps. GCE also can easily serve Flask apps, but the environment there is weird and I spent tons of time struggling with things that worked in my GCE dev environment to work in the real GCE. I had high hopes for GCE but it was a total pain in the butt.
As far as moving your bare metal servers around to whatever DC... Enterprises don't easily move data centers. Minimum to move our couple of Lambda apps, deployed on uwsgi, is probably a contract for 2 years at a grand a month, and $30K worth of hardware. We wouldn't take down one data center until another is fully up and running and proven.
Yes, but honestly what percentage of businesses need regulatory conformance or anything like signed logs?
My main problem is the lack of transparency, vendor lock-in (so you can't enter non-mainstream markets with some regulatory expectations, such as Vietnam or Russia).
> Yes, but honestly what percentage of businesses need regulatory conformance or anything like signed logs?
Uh, as soon as you're processing PII, be it health information, social security numbers like in payroll, or credit card information, you're required by law (or the CC industry) to have these. And no, cutting corners is not an option, at least if you want to avoid some serious jail time.
Media processing (in the sense of professional movie studios) requires MPAA certification, which in turn requires that all systems handling "customer data/assets" even be airgapped to the Internet (source: MPAA best practices guidelines).
And if you're ever dealing with car manufacturers, goodbye to cloud - they're similarly sensitive when it comes to anything near unreleased products. No Dropbox/Slack/... allowed, and for good reason.
> Uh, as soon as you're processing PII, be it health information, social security numbers like in payroll, or credit card information, you're required by law (or the CC industry) to have these. And no, cutting corners is not an option
True, but you can still organise out less sensitive components to serverless, and there are plenty of payment and payroll gateways to outsource the compliance problems.
> True, but you can still organise out less sensitive components to serverless, and there are plenty of payment and payroll gateways to outsource the compliance problems.
Good luck building all the firewalling and other logic required for a sane system.
And everytime I see "outsource" in reference to the core parts of a company (which payments and payroll definitely are), I cringe. That's a desaster waiting to happen.
And yet fortune 100 and 500 companies are increasingly adopting cloud technology. And there are plenty of solutions already available to distribute your cloud infra to multiple providers at once.
I think the writing's on the wall. Software devs are coding Ops out of a job. Even the network is software now.
Only at Facebook, probably one of the few companies in the world which can afford dedicated engineers for that stuff (and probably needs SDN because a server might shift totally in its roles and thus its networking dozens of times a day).
The rest of the world keeps using Cisco or HP gear, which works fine enough for everything I have seen (from SOHO equipment in small offices over 6-or-so-HE switches in a medium company to rack-sized switches at a municipal government). Also, the amount of HP or Cisco certified network engineers outweighs the amount of SDN by far.
It's definitely more than just Facebook. Every major network equipment vendor already provides SDNs, including Cisco, and HP, who has an entire site and app store dedicated to SDN.
2016: Top 10 SDN market leaders: "market is set to top $12.5 billion by 2020" ... "SDN in the data center and enterprise LAN is going to go mainstream in late 2016, early 2017," ... "We're seeing significant customer deployment. Cisco's got over 1,000 deployed customers for their SDN solution. VMware is around the same number, even though revenue might be higher on the VMware side. NEC has over 250 scaled deployment customers."
Just as an example, Cisco's been running Linux on its new gear for years. They can run multiple OSes in different planes on their custom gear and get crazy fast traffic flows while doing things like deep packet inspection. They wrote custom interfaces to do things like get super-low-latency traffic control.
You can make your own Python apps, and run them when triggered by an event, on the appliance or remotely, with several APIs. You can use Ansible, Puppet and Chef to manage the appliance configuration. You can also configure them with netconf, or XMPP. You can have your switches send you instant messages or post in your ops chatrooms. And you can deploy all your devices from a clean slate using kickstart scripts.
Hm. I see your first point(s), but maybe won't immediately concede that they aren't solvable. But to your second point, lots of really successful enterprise companies get "locked in" to Aws, Gce etc and are running just fine.
AWS is right around ten years old. I have children who could read before it was launched. That's not enough time for a business to stabilize, but it would be a good idea for any business to start planning an escape route.
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.
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.
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.
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.
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 and 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.