7 ms·

Serverless Takes DevOps to the Next Level

40 points by nlolks 9y ago

mschuster91 9y ago
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.
- rco8786 9y ago
  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.
  - stonogo 9y ago
    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.
- dogma1138 9y ago
  TBH that was they said about DevOps.
- peterwwillis 9y ago
  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.
  - holydude 9y ago
    Fortune 100-500 run myriads of different software. Really your "avg" fortune 500 company cant be used as a benchmark.
    - deleted 9y ago
      [deleted]
  - mschuster91 9y ago
    > 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.
    - peterwwillis 9y ago
      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. 2015: Cisco's SDN business is booming. http://www.computerweekly.com/news/2240240260/Cisco-software-defined-networking-business-booms http://www.computerweekly.com/news/2240240260/Cisco-software... 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." http://www.crn.com/slide-shows/networking/300079644/top-10-sdn-market-leaders-in-the-data-center-and-enterprise-in-2016.htm http://www.crn.com/slide-shows/networking/300079644/top-10-s... 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. Automating with NX-OS https://www.slideshare.net/CiscoDevNet/automating-with-nxos-lets-get-started https://www.slideshare.net/CiscoDevNet/automating-with-nxos-...
- bsenftner 9y ago
  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 9y ago
    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/205cc548148829078d4bf2fd394f50ae 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".
    - bsenftner 9y ago
      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.
- aries1980 9y ago
  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).
  - mschuster91 9y ago
    > 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.
    - aries1980 9y ago
      > 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.
      - mschuster91 9y ago
        > 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.
- linsomniac 9y ago
  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.
jMyles 9y ago
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.
wheelerwj 9y ago
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.
holydude 9y ago
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.
- awinder 9y ago
  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.
- FLUX-YOU 9y ago
  >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 9y ago
    AI was around the corner when I learnt LISP and analogue processor arrays 20 years ago. Still not here.
    - linsomniac 9y ago
      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.
bpicolo 9y ago
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 9y ago
  > [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/
  - bpicolo 9y ago
    > 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.)
obulpathi 9y ago
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 9y ago
  > 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.
specialist 9y ago
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 9y ago
  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=000tgU http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=...
zitterbewegung 9y ago
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 9y ago
  You are correct - Serverless DevOps. Serverless actually makes DevOps fun and challenging - and especially if you work on multiple cloud platforms.
  - deleted 9y ago
    [deleted]
menegattig 9y ago
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-ae3b00146c26 https://blog.slicingdice.com/why-a-serverless-data-warehouse... (Disclosure: SlicingDice employee here)
empath75 9y ago
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.
aries1980 9y ago
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.
nwhatt 9y ago
> 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.
mgarfias 9y ago
It's not serverless, it's just not your server
iamryo 9y ago
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.
mdekkers 9y ago
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.

40 points by nlolks 9y ago

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.

rco8786 9y ago
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.
- stonogo 9y ago
  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.
dogma1138 9y ago
TBH that was they said about DevOps.
peterwwillis 9y ago
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.
- holydude 9y ago
  Fortune 100-500 run myriads of different software. Really your "avg" fortune 500 company cant be used as a benchmark.
  - deleted 9y ago
    [deleted]
- mschuster91 9y ago
  > 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.
  - peterwwillis 9y ago
    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. 2015: Cisco's SDN business is booming. http://www.computerweekly.com/news/2240240260/Cisco-software-defined-networking-business-booms http://www.computerweekly.com/news/2240240260/Cisco-software... 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." http://www.crn.com/slide-shows/networking/300079644/top-10-sdn-market-leaders-in-the-data-center-and-enterprise-in-2016.htm http://www.crn.com/slide-shows/networking/300079644/top-10-s... 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. Automating with NX-OS https://www.slideshare.net/CiscoDevNet/automating-with-nxos-lets-get-started https://www.slideshare.net/CiscoDevNet/automating-with-nxos-...
bsenftner 9y ago
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 9y ago
  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/205cc548148829078d4bf2fd394f50ae 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".
  - bsenftner 9y ago
    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.
aries1980 9y ago
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).
- mschuster91 9y ago
  > 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.
  - aries1980 9y ago
    > 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.
    - mschuster91 9y ago
      > 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.
linsomniac 9y ago
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.

jMyles 9y ago

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.

wheelerwj 9y ago

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.

holydude 9y ago

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.

awinder 9y ago
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.
FLUX-YOU 9y ago
>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 9y ago
  AI was around the corner when I learnt LISP and analogue processor arrays 20 years ago. Still not here.
  - linsomniac 9y ago
    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.

bpicolo 9y ago

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 9y ago
> [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/
- bpicolo 9y ago
  > 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.)

obulpathi 9y ago

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 9y ago
> 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.

specialist 9y ago

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 9y ago
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=000tgU http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=...

zitterbewegung 9y ago

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 9y ago
You are correct - Serverless DevOps. Serverless actually makes DevOps fun and challenging - and especially if you work on multiple cloud platforms.
- deleted 9y ago
  [deleted]

menegattig 9y ago

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-ae3b00146c26 https://blog.slicingdice.com/why-a-serverless-data-warehouse... (Disclosure: SlicingDice employee here)

empath75 9y ago

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.

aries1980 9y ago

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.

nwhatt 9y ago

> 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.

mgarfias 9y ago

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

iamryo 9y ago

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.

mdekkers 9y ago

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.