back to article Serverless: Should we be scared? Maybe. Is it a silly name? Possibly

What exactly is "serverless"? Like many popular technology terms, the exact definition of serverless is increasingly fluid. Also like many popular technology terms, the fact that the term means different things to different people doesn't sit well in some quarters. I've taken my own stab at defining serverless here on El Reg. …

  1. Warm Braw

    Don't care about how their applications do what they do?

    They clearly missed their GDPR training, then.

    1. Peter2 Silver badge

      Re: Don't care about how their applications do what they do?

      And security, legal compliance and operations basics?

      1. AMBxx Silver badge
        Alert

        Re: Don't care about how their applications do what they do?

        All those people who used to write crap Lotus Notes applications are now 20 years older and in more senior positions.

        Run for the hills.

        1. Wayland
          IT Angle

          Re: Don't care about how their applications do what they do?

          An excellent point about Lotus Notes. That tool allowed people to use computers to do their job. Say a secretary wanted people to fill out a questionnaire. These days she would write it as a word document with boxes for them to fill in with a pen and have them scan and email it back to them.

          In the old Lotus Notes days she would create the form in Notes and email it from there. When the recipient filled in the form their data was automatically being entered into a table. The secretary could then see all the answers tabulated and could perform statistics and graphs with the data or put it in a spreadsheet.

          IT has gone backwards since Notes was murdered. I did not like Notes because it was a competitor to my MS Access development work. It seems secretaries could develop apps in Notes but could not manage MS Access.

          Serverless seems to be a re-invention Github but for the Dragondrop croud.

        2. J__M__M

          Re: Don't care about how their applications do what they do?

          All those people who used to write crap Lotus Notes applications are now 20 years older and in more senior positions....

          You'd rather they were still coding?

      2. Anonymous Coward
        Anonymous Coward

        Re: Don't care about how their applications do what they do?

        My thoughts to a tee. It's bad enough now that we have a third party handling some important bits for us but when there's no-one else to blame other than a black box that's so easy to use a windows admin could do it. I for one do not want to be on the recieving end of that (though the schadenfreude of the PHB would be worth whitnessing).

    2. post-truth

      Re: Don't care about how their applications do what they do?

      Excellent point on GDPR, @Warm Braw. Just as any jurisdictionally non-deterministic cloud application processing personal data necessarily breaches the GDPR even if the data never actually leaves the EU (if only because ignorance plus mandated advance notification plus reversal of legal burden of proof ipso facto equals breach), the same applies to anything that replicates the same effect.

      That said, actually I'm exploring the feasibility of deploying what used to be called "middleware" as BDCAs, even in the context of GDPR control software - so long as you never ever send anything but non-personal metadata into the black box! Then the only issue becomes performance...

  2. jake Silver badge

    "Serverless" is a marketing term. No more, no less.

    And like most such terms, it'll last until someone comes up with a new name for the same concept. During the meanwhile, I'm still making good money rescuing companies from the so-called "cloud". Centralized Computing's sell-by date was roughly when IBM legitimized the personal computer.

    1. Name3

      Re: "Serverless" is a marketing term. No more, no less.

      > Centralized Computing's sell-by date was roughly when IBM legitimized the personal computer.

      Exactly. It goes in cycles of maybe 15 years going from one extreme to the other (centralized computing <-> de-centralized).

      1) single big computers and super computers

      2) main frames with linked terminals

      3) personal computer (PC)

      4) Web2.0 / cloud and smartphones (with cloud services)

      5) upcoming next de-centralized hype

      1. wallyhall

        Re: "Serverless" is a marketing term. No more, no less.

        And (forgive me if I'm misunderstanding here) the concept of having a bunch of individual units of logic with a well-defined input and output running and interconnected transparently over multiple distributed and disparate pieces of hardware doesn't feel particularly new either. (I'm far too young to have used it, but I believe Plan9 was possibly just "too ahead of its time"?)

      2. John Smith 19 Gold badge
        FAIL

        "our new serverless code monkey could build an application"

        Not a good application.

        Not a fast application

        Not a robust application

        But my goodness, look how cheap it is.

        The nature of (code) monkey* is irrepressible*

        *But still "anonymous server farms in unknown jurisdictions"

    2. Sir Runcible Spoon

      Re: "Serverless" is a marketing term. No more, no less.

      @Jake, thanks for saving me some typing.

      I remember when the 'cloud' became a thing and I was surprised because I had no idea what they meant by it, to me it was all just hosted services.

      All these additional functions/features are an attempt to streamline delivery and create generic templates from which to build networked environments, i.e. commodification.

      It seems to serve particular needs of a certain group of consumers (ideal for SME's and project based deliverables in larger companies perhaps) but not everyone, since there are considerable downsides.

      Most of these downsides are ignored if the bean-counters are in charge - after all if it all goes wrong they just blame the techies, when in reality most situations that arise can be traced back to poor or incompetent/misled business decisions.

      All I can see with these kind of services is a decrease in total cost of ownership, along with a decrease in flexibility and accountability (what use is a months refund for failing an SLA when your entire customer database has just walked out the door?) and a huge increase in risk.

      If your data is low risk and you only need a cookie-cutter solution and cost is a major factor, then sure - fill yer boots, but buyer be-warned - you have been.

      1. Doctor Syntax Silver badge

        Re: "Serverless" is a marketing term. No more, no less.

        "ideal for SME's"

        Maybe not even them. I had an occasional client who had an engineering supplies business - store-room, several counter terminals and printers, office PCs and more printers, all running on an in-house server. As a customer, I can go to a branch of a national chain of builders' merchants and the transaction is handled through a server sitting there in the office. If their comms went down how would they manage with the data on somebody else's computer? The small business, maybe, but a catching up after a couple of outages wouldn't leave them very pleased. The national chain - maybe the beancounter says No - must record it properly.

    3. Daniel von Asmuth
      Paris Hilton

      Re: "Serverless" is a marketing term.

      Of course, it reminds us of another marketing term: "client-server". It's just that whatever it means seems to involve more servers, whereas peer-to-peer mesh networks would use fewer servers.

      Maybe the PC should be called a computerless typewriter.

    4. Procast

      Re: "Serverless" is a marketing term. No more, no less.

      Well, I have to disagree a bit: I am running a backend for my mobile app on aws Lambda for about 4 months now (https://itunes.apple.com/us/app/procast-podcast-app/id1215380730).

      The app stated growing quite rapidly recently, and the scale I get from Lamda is amazing. And the cost is just a fraction what I would spend otherwise. I architected it with quite some caching tricks to save some money, but even without that is it truly amazing. And I say that in spite of working on the Microsoft Stack for more than 15 years.

      1. JohnFen

        Re: "Serverless" is a marketing term. No more, no less.

        I'm honestly not seeing how any of that contradicts Jake's assertion.

        1. AMBxx Silver badge

          Re: "Serverless" is a marketing term. No more, no less.

          Looks like we're returning to Client-Server to me.

          The client is either a javascript application running in a browser or a local application running on a phone.

          I'm sure the next great idea will be to run the UI stuff back on the server and we'll have come full circle again.

    5. Anonymous Coward
      Anonymous Coward

      Re: "Serverless" is a marketing term. No more, no less.

      As a marketing term it is understandable enough.

      In education there are plenty of schools getting rid of their file-servers for students and replacing it with G Suite. In fact, I'd say the trend is growing.

      1. jake Silver badge

        Re: "Serverless" is a marketing term. No more, no less.

        And I'm following right behind, replacing "the cloud" with a local system that actually works 24/7 after I get wind that the school is very unhappy with the off-site kludge that they bought into.

  3. RyokuMas
    Paris Hilton

    Oh, shit...

    "And it opens up really complex application development to people who never could have done this before."

    I've seen what happens when you do this: when Unity3D, Unreal Engine et al were made free, it abruptly opened the floodgates to people who previously had been unable to make games - in the first instance this was due to the technical knowledge barrier, which put off the people who could not be bothered to learn, and in the second instance, it then removed the financial barrier ie: people had to be willing to pay for these engines.

    The result was a flood of shiteware into the marketplaces, resulting in a lot of good games that had had a lot of time and effort poured into them vanishing beneath this deluge of crap.

    1. Anonymous South African Coward Bronze badge

      Re: Oh, shit...

      It really is a load of bollocks, if you want to play something small (like pixel dungeon) you have to wade through thousands of similar crapware before finding the one you want. And risk getting a trojan/worm along the way.

      I have my favourites - oceanhorn, two pixel dungeon variants (damn that permadeath) and three or so other RPG games. And Marvin (Speccy emulator) in case I am stuck in a boredroom meeting which went past its sell-by time and is dragged out by some self-righteous pompous troubadour, then I can just keep myself busy for a while until said pompous troubadour finishes said boring performance and we can escape.

    2. IamStillIan

      Re: Oh, shit...

      JavaScript for infrastrucutre? Anyone can use it; but no one can use to make anything you'd be confident in..

    3. JohnFen

      Re: Oh, shit...

      This.

      The problem is that actually writing the code (whether in text form or by assembling logical Legos), is the easiest part of software engineering. It's the "engineering" part that's hard and requires knowing what you're doing.

      1. Bronek Kozicki

        Re: Oh, shit...

        This, but what should we expect when everyone - including headhunters, regulators and journalists - think that CODERS are synonym with ENGINEERS.

        Sometimes it feels as if these two were seriously considered to be engineers, and the whole of the profession held responsible for the inevitable mayhem.

  4. Bronek Kozicki

    @Trevor Pott

    I think you got it right here "If something goes wrong, we don't know how to fix it, but we may still be held responsible. Most IT practitioners simply won't be able to get over this."

    The thing is, IT practitioners make the decisions. Their job is to control the risks and take the responsibility. Until "serverless" evangelists find a way to put that in a black-box, too, it will not take off. And we are far from it.

    1. Sir Runcible Spoon
      Coat

      Re: @Trevor Pott

      The thing is, IT practitioners are supposed to make the decisions. Their job is to control report the risks and take the responsibility blame.

      There, that looks more realistic now doesn't it :)

      1. Trevor_Pott Gold badge

        Re: @Trevor Pott

        @Sir Runcible Spoon well that comment certainly created a combination of wry smile and crushing, crushing depression. A little bit too on the nose...

        1. Sir Runcible Spoon

          Re: @Trevor Pott

          Yeah, reading back I'm almost in tears. I must have been channeling my inner Dilbert when I wrote it.

  5. Death_Ninja

    COBOL

    Haven't we been here before?

    For those of you not old enough to remember....

    "Representatives enthusiastically described a language that could work in a wide variety of environments, from banking and insurance to utilities and inventory control. They agreed unanimously that more people should be able to program and that the new language should not be restricted by the limitations of contemporary technology. A majority agreed that the language should make maximal use of English, be capable of change, be machine-independent and be easy to use, even at the expense of power"

    (Wikipedia quote)

    And what happened to COBOL? Far from being an enabler which rid the world of computer geeks, it simply created a new one - COBOL programmers.

    Did it reduce development costs? Maybe. Did it create a whole new layer of hell? For sure.

    1. Anonymous Coward
      Anonymous Coward

      Re: COBOL

      "And what happened to COBOL? Far from being an enabler which rid the world of computer geeks, it simply created a new one - COBOL programmers."

      SQL was designed with a similar mindset - ie people being able to "talk" to their computer in something resembling english (of course they never said what would happen if they were , say french and couldn't speak it). Which is fine for 5 minutes. But as soon as any complex logic is required then someone who understands complex logic and how to implement it is required on the scene. There's a name for these people - they're called programmers.

      1. Prst. V.Jeltz Silver badge

        Re: COBOL

        "SQL was designed with a similar mindset "

        You wouldnt think so would you? I know its got a couple of english words in it like , but once you've nested a couple of queries it looks far less intelligible than C or VB

        1. Anonymous Coward
          Anonymous Coward

          Re: COBOL

          "You wouldnt think so would you?"

          Apparently that was one of the original goals.

          " I know its got a couple of english words in it like , but once you've nested a couple of queries it looks far less intelligible than C or VB"

          Oh I agree. A highly complex SQL query is far harder to grok than any declarative piece of code simply because what it actually does is highly implicit and the correlations between various parts of the query or subqueries can become almost impossible to hold in your head after a certain point. Hence my comment about programmers ultimately being required.

      2. Deltics

        Re: COBOL and ActiveX and <insert miracle programmerless tech>

        To be fair, COBOL didn't aim to rid the world of computer geeks, it actually set out to increase the number of geeks. The goal was not to make a language that anyone could use, but to make a language that could make computers easier to program for business oriented tasks, as opposed to the computer science/abstract data processing that had prevailed up to that time.

        On the other hand I clearly remember sitting listening to Microsoft drones warbling on about how with ActiveX, businesses wouldn't need as many programmers (we hadn't started calling ourselves engineers yet).

        There would be a small number of programmers who would create ActiveX components which would then be assembled into working programs as needed by people in the business who didn't understand and didn't need to understand *how* those components did what they did, only *what* they did.

        Seems to me that this is exactly the same sales-pitch for server-less which would more honestly be called (these days) "engineer-less".

      3. Anonymous Coward
        Anonymous Coward

        Re: COBOL

        We have a vendor who substitutes brute force, ignorance, and the ever useful excuse of 'throw more hardware at it' to try and solve design issues with their software. One of our major LOB applications uses some truly terrible SQL queries when building reports- I'm talking 'select star from star' and using the WHERE clause to filter it down to what they want, against a 600 GB+ dataset, and then bitch about why the stupid expensive (and massively over powered) hardware we bought is running like molasses on a cold winters day. Oh, and they've either never put an index on the dataset, or they are indexing EVERYTHING, INCLUDING THE INDEXES. (which is technically impossible- I'm not sure how they did it, either.)

    2. Teiwaz

      Re: COBOL

      I think I have to agree with Boltar

      The problem has nothing to do with COBOL or any other language new or old, designed to supposedly allow the average user to be more enabled.

      But more to do with the ability to apply structured logic and have at least some grounding in data structures.

      The existence of ready made cement and DIY stores did not presage the era of the average shopper then being able to build Cathedrals and road bridges nor were they expected to. Why should IT be any different.

  6. Andy Taylor
    Trollface

    Serverless = Someone Else's Computer(s)

    nt

  7. JimmyPage Silver badge
    Megaphone

    Is this have-a-go time ?

    "Serverless" : Where the functions traditionally performed by a physical machine are now undertaken within a network of machines with no single identity.

    Where's my $100K ?

  8. Anonymous South African Coward Bronze badge

    At the core of it, serverless means that those building applications no longer have to care about how their applications do what they do, they just have to tell the applications what to do. That’s revolutionary. And it opens up really complex application development to people who never could have done this before.

    One great example of the power of serverless is Bulk Data Computational Analysis (BDCA). I can take a windows admin who can barely write batch files – they don't even have to know how to use PowerShell – and inside of a day, I could have them writing voice recognition apps. Our hypothetical novice developer can slap a fully functional voice recognition app using little more than code snippets from Stack Exchange and some public sample code from Amazon.

    And that is the problem right there. A good coder will be able to recognize a problem (eg exploit or an embedded rm -rf / *) code within the copypasta - but the above windows admin will not know how to spot an exploit or the such, and will compile a big problem...

    Keep in mind, ne'er-do-wells will think outside the box - and they will try to obfuscate their ne-er-do-well piece of sh*te code in such a way that it will looks as if it does X but actually does an rm -rf all over the place.

    1. Sir Runcible Spoon

      It took me a full day to get my head around regular expressions. It's obvious to me that you could hide an awful lot of nasty in those impenetrable looking expressions :)

      1. AndyD 8-)&#8377;

        "It took me a full day to get my head around regular expressions."

        Well done - I've been trying to get my head around them for several decades, and still struggling!

    2. Naselus
      Joke

      "Our hypothetical novice developer can slap a fully functional voice recognition app using little more than code snippets from Stack Exchange and some public sample code from Amazon."

      Isn't that what 80% of developers currently do...?

      1. Doctor Syntax Silver badge

        "Isn't that what 80% of developers currently do...?"

        Your hand seems to have accidentally slipped and added a joke icon.

  9. Aitor 1

    Problematic

    These platforms tend to privide 90 to 95% of what you need.

    And it is the missing part that converts it into hell, as these blackboxes tend not to play well with other parts.

    Another problem is cost. You are now charged "per use", or "per 10k uses", whatever.

    It seems nice.. but how do you control that? It is not easy.. and it is completely out of your control.

    1. Matthew Brasier

      Re: Problematic

      It isn't completely out of your control, there are a number of things you can do to control costs in a cloud environment, from picking the right technologies in the right places, applying limits etc. This is broadly what "cloud architecture" is about (the drawing a cloud on a bit of paper with arrows going in and out of it is to real cloud architecture, what "Enterprise architecture" was to real systems architecture). Most cloud vendor architecture certifications recognize this, and focus on cost control (along with security) as one of the key pillars of architecting a system.

      1. Sir Runcible Spoon

        Re: Problematic

        I've been doing enterprise architecture for years now. Nothing on Earth will tempt me into that cloud. I would rather work at McDonalds than sully myself with, what I believe will one day be, a massive red flag on my CV.

        I'm not just being a grumpy old fucker either. There are real risks that I wouldn't be able to control and would have no way of overcoming them with a clever design if that environment couldn't be constructed 'just-so'.

        For example, the environment I've just designed is highly secure and hosts a number of critical analysis tools for the overall network. Some users will end up logging in to this environment to use those tools and to them it will be 'a cloud'. However, as far as I'm concerned this is a highly bespoke, tailored to fit, security solution end to end.

        It simply couldn't be done in the cloud: it's been hard enough to control the risks when I have a huge say in what goes into the design and what gets thrown out because we can't secure it fully.

        1. TRT Silver badge

          Re: Problematic

          McDonalds has a wall based terminal screen now, a bit like the ones at Argos... glossy catalogue... tap in the code for a supersize BigMac... tap in some more codes for the meal options... put in my bank card... receipt printed... Please collect your "food" at collection chute A.

          What's happened to the server? Ah! They're now in the kitchen putting the little boxes all the same into the chutes.

          Serverless.

          Now, what have they done with all the straws?

        2. Sir Runcible Spoon

          Re: Problematic

          Oh dear, that wasn't a popular opinion now was it? :)

          I should clarify (or you could read some of my other posts on the subject) that I'm not objecting to cloud based services where they are appropriate, but for the kind of environments I'm asked to design 'The Cloud' is an anathema to me.

          If a security consultant were to suggest we put the crown jewels of a company into a cloud based solution I would strongly object, to the point where I would walk off the project if it were insisted upon. You are welcome to disagree with my opinion, but I don't know any reputable security consultant who would align themselves with such a precarious proposition. My reputation is pretty much all I have to trade with, if I lose that I'm out of work and penniless - no way I'm going to put it into someone else's hands.

          1. J. Cook Silver badge

            Re: Problematic

            At [RedactedCo], we've been largely resistant to anything 'cloud'-esque for a while now, primarily because most of the data we deal with is company sensitive and under the ever watchful eye of the regulator that allows us to operate.

      2. Doctor Syntax Silver badge

        Re: Problematic

        "It isn't completely out of your control, there are a number of things you can do to control costs in a cloud environment,... applying limits etc."

        And then the limits get hit just before month end.

    2. Anonymous Coward
      Anonymous Coward

      "Another problem is cost."

      And I can imagine the usage licenses hell, especially when someone starts to get ideas from Oracle or the like... AWS and other cloud usage licensing is already complex enough.... put on top of them any server application you need to use, and it could become quite a nightmare.

    3. Doctor Syntax Silver badge

      Re: Problematic

      "And it is the missing part that converts it into hell, as these blackboxes tend not to play well with other parts."

      It raises thoughts of the bill for successful percussive maintenance: £1 for hitting it, £999 for knowing where to hit.

  10. PyLETS

    Problematic business model

    Geocities was bought in 1999 for $3.57B and switched off 10 years later. Providing the server and service with no revenue stream apart from paltry advertising, however temporarily popular, could only have been sold for that price if someone making the decision imagined it could become a monopoly capable of being monetized at some point.

    Creating a production as opposed to demonstration/research app using such a service is likely to be high risk unless you can know in advance what it's going to cost your users and how they will pay for it. If it becomes a must-have monopoly, your heavy users will be price gouged or have to stop using what they've come to depend upon. If they imagine it will cost nothing it's unsustainable by definition and will eventually be switched off when the investor gives up funding the black hole.

  11. Anonymous Coward
    Anonymous Coward

    "serverless means that those building applications no longer have to care about how their applications do what they do, they just have to tell the applications what to do. That’s revolutionary"

    Only about as revolutionary as the concept of the subroutine: pass in arguments, get a return value, don't care how it works inside.

    If you define serverless as "being able to bolt together a bunch of 3rd party applications" then this is what SOAP and Web Services APIs were promising years ago. The reality was rather different: you could end up writing a whole bunch of glue and data transformations to pull data out of X and push it into Y which ended up being more complex than the application itself. Plus there's a whole bunch of error scenarios which you need to cater for if any of the intermediate steps is temporarily unavailable or unreachable, but most people didn't bother with.

    If you take serverless in its more narrow scope (such as AWS Lambda) then it just means writing code but not caring where it runs in production. Simplified operations, but essentially PaaS.

    1. Ken 16 Silver badge
      Thumb Up

      PaaS

      I think of it as a managed hosted Java framework (until someone can explain more to me)

    2. Name3

      Serverless is essentially PaaS, basically shared-hosting

      Serverless as AWS Lambda, simplified operations, but essentially PaaS, so basically the old shared-hoster with know from Perl and PHP haydays. (btw PHP7 is great again nowadays)

      About AWS Lambda, I was quite underwhelmed by it's crude implementation. One has to re-upload a zip file with the complete source code, again and again. Even shared hosters that have support Perl and PHP since 1997 have been more advanced and offered FTP or upload form where one could re-upload only the altered source code files, not the whole repo everytime.

      1. Anonymous Coward
        Anonymous Coward

        Re: Serverless is essentially PaaS, basically shared-hosting

        About AWS Lambda, I was quite underwhelmed by it's crude implementation. One has to re-upload a zip file with the complete source code, again and again. Even shared hosters that have support Perl and PHP since 1997 have been more advanced and offered FTP or upload form where one could re-upload only the altered source code files, not the whole repo everytime.

        If you really want to, you can edit code in-situ, on the AWS console.

        However, most people would rather keep their code in source control and use a framework to upload it, such as [serverless](https://serverless.com/). Just type "sls deploy" and let it assemble and upload the whole zip file for you, along with all the CloudFormation config to connect your app with any other AWS resources it needs.

        1. Anonymous Coward
          Anonymous Coward

          "keep their code in source contro and use a framework to upload"

          At this point I would expect AWS being able to get code automatically from source control, and only the modified code, instead of a whole zip.... next time it will ask to send punched cards by mail?

    3. SVV

      "this is what SOAP and Web Services APIs were promising years ago. The reality was rather different: you could end up writing a whole bunch of glue and data transformations to pull data out of X and push it into Y"

      My experiences exactly. Spending days writing XML transformations between one schema and another and making new web services in the internal house style just to call external web services, so that the internal applications used the correct style (I was made to do it this by the architect by the way , so don't assume I was responsible for this nonsense). Pretty much everyone is going to go for this wrapper / interface layer approach I would presume. Then come all the availabilty problems of multiply located services. For this to really work, every service needs to implement a simple "heartbeat" function to check that it's still alive and reachable, so a simple webpage can be put together for the sysadmins that lets them see the status of every component part easily and rapidly determine which service is at fault if there are problems. Then the usual round of phone calls / emails / shouting and swearing / recriminations can begin. But most people probably won't bother implementing this, so it'll scupper chances of being any more popular than SOAP / REST services currently are.

      I am in total agreement too with all others here who have posted that the "this will eliminate the need for trained and experienced devs cos idiot code monkeys will be able to do it all" claim is making its' current apperance, shortly before deeper consideration tucks it away for another couple of years, until someone invents the next version of this square wheel.

  12. Anonymous Coward
    Anonymous Coward

    Like dude, thats totally "insane!"

    "With a little work, our new serverless code monkey could build an application that reads an S3 bucket looking for uploaded sound clips, sends those sound clips off to a BDCA tool for natural language recognition, and then either does voice-to-text conversion or executes commands, depending on the contents. That's insane"

    First of all give the idiotic north american hyperbole a rest. Its not "insane" , its clever, but gui driven dev been around for years in various forms and as we know from VB, it doesn't generally lead to quality applications. The best this will manage is a way of doing simple batch operations until some more complex logic is required and a proper coder has to step in and take over.

    Secondly what has a GUI based devlopment enviroment got to do with serverless? The two are entirely disconnected other than these facilities are being offered on top of cloud services.

    1. Brewster's Angle Grinder Silver badge

      Re: Like dude, thats totally "insane!"

      Okay, so you can write an office security system. Now write Angry Birds.

  13. Anonymous Coward
    Anonymous Coward

    re: and inside of a day, I could have them writing voice recognition apps.

    Actually, you meant to say

    and inside of a day, I could have them writing CRAP voice recognition apps.

    Those apps will probably be framework on top of framework on top of frameworks and perform like a dog, take up 100+Mb of RAM and .... {do I need to go on?}

    Writing tight code takes skill and experience. Many coders these days can boast the latter but the former? Not if any of the so called developers I've interviewed in the past four or five years is anything to go by.

    Software Development these days is more 'never mind the quality, see those flashy lights and images and sound and ...' and very little about functionality and performance and lack of bugs. They just don't care, just as your amateur coder who you have taught to make even more useless apps with no thought to who has to support them.

    I'd better go and lie down in a darkened room now before I get back to sorting out some IoT device crap[1] that was probably put together by the same person you taught to write VR apps, i.e a total shithead.

    [1] Why an IoT device codebase (for a Realt Time device controller) needs a calc app, a photo editing app and a media app is just one of the bits of stupidity that I'm dealing with. Getting them removed is probably going to be as easy as getting a 10-minute rule bill to become law.

  14. Bill M

    Internet of Trout

    I just want to know who thought building an internet out of fish was a good idea.

    1. TRT Silver badge

      Re: Internet of Trout

      Project Neptune? Don't knock it, man. That last layer 1 upgrade was... I mean... Frickin' sharks with lasers, man.

  15. Anonymous Coward
    Anonymous Coward

    It's not serverless it's 'server couldn't care less'

    It's another marketing fabricated name, exactly like Cloud - both are other people's computers we don't want have to be bothered with, as those in charge are too busy in management la-la land drinking the koolaid, enjoying their yachts, spaffing away the company profits to build their CVs for the next gullible idiot company to hire them.

    1. Professor Clifton Shallot

      Re: It's not serverless it's 'server couldn't care less'

      'Cloud' was in common use in my workplace in the 90's (and quite possibly before - I'm not as old as all that) well before it was being redefined, sprinkled with fairy dust, and sold back to our management.

      It was the bit in a drawing where you stopped caring about the precise details - someone else's stuff (your network guys', a telecomms provider's, some sneakernet, whatever), represented by a cloud-shaped squiggle. You cared about the stuff going in and coming out but not about how it got from one end to the other - in fact remarkably like this 'serverless' idea now.

      We all know we're being marketed at but that doesn't mean there's not a kernel of good stuff in this. I've worked in places where providing tools to people who knew what they wanted out of the data was really important - we did have developers but we didn't want them to have to be involved with things like "Do sales of product-x increase on the weekends following the mode pay date for for region-y? Is there any difference in the delta for men and women?" so they made the tools for the people who could formulate the questions.

      Security will be a thing, but only the thing it always is; getting stuff done will be the driver and if this sort of setup helps get stuff done affordably then it will succeed.

  16. Doctor Syntax Silver badge

    "I've taken my own stab at defining serverless here on El Reg."

    Maybe another stab is needed. I went back on the link. I didn't see anything that looked like a definition. It just moved rapidly into discussion AWS Lambda which I take to be an example but didn't offer anything I could recognise as a definition. If it can't be defined then it's not surprising we regard it as just another buzzword trying to sell us the idea that running something on somebody else's computer is a better idea than having control of what's essential to running one's own business.

    1. Anonymous Coward
      Anonymous Coward

      "I've taken my own stab at defining serverless here on El Reg."

      Agreed: there is no definition of serverless in the linked article, but it does cite AWS Lambda as a prime example.

      This is in complete contrast to today's article, which seems to push "serverless" as some sort of non-programmer business logic generator (anybody else remember "The Last One"? It was supposed to make programming obsolete, hence its name)

      "a windows admin who can barely write batch files – they don't even have to know how to use PowerShell – and inside of a day, I could have them writing voice recognition apps"

      Using AWS Lambda? Sure.

      Firstly they have to learn either Python, Javascript, Java or C#, because those are the four languages that Lambda supports. Then they have to learn how AWS works in general, things like using the console, API keys and IAM permissions, and how to give their code permissions to talk to other AWS resources. Then they have to learn how to upload code to Lambda and invoke it, possibly using a framework like "Serverless". Then they have to understand the APIs of the third-party services they are trying to invoke, and learn some libraries for calling out to those services (such as: making JSON or SOAP HTTPS requests across the Internet), and how to authenticate to those services as well. Then they have to work out how to allow incoming events to trigger functions, such as files being uploaded to S3 buckets, or incoming HTTPS requests via API gateway, or messages via SQS, and parse and act on those requests. And then debug it all, e.g. using CloudWatch logs.

      A seasoned developer will probably get to grips with these things pretty quickly. Your average lame Windows admin, in one working day? Less likely methinks.

      Hence I don't think this article can *really* be talking about AWS Lambda. But if not, what *is* this mythical serverless environment it refers to?

      1. Doctor Syntax Silver badge

        "Firstly they have to learn...Then...Then..."

        The somebody forgets to secure one of these multiple points of failure and all the data ends up on haveibeenpwned.

        1. Trevor_Pott Gold badge

          There's a whole industry full of supposed trained experts with loads of experience and education and all our information is ending up on haveibeenpwned anyways. You'll excuse me if I don't feel that people doing the application development equivalent of drawing lines between black boxes that are designed and maintained by large multinational public cloud providers could possibly do any worse.

          Hell, maybe those public cloud providers will actually hire enough security people that the stuff they offer is secure by default. It would be a nice change from the shitpoaclypses created by the "I know better" or furiously cheapskate crowds.

      2. Anonymous Coward
        Anonymous Coward

        > Firstly they have to learn either Python, Javascript, Java or C#, because those are the four languages that Lambda supports

        Now five - they added support for Go

  17. teknopaul

    how much will it cost

    Trying to guess the price of your serverless app is a nightmare. I set up a test aws account in the free tier, added this thing where they warn you if you're about to go over budget (above zero) and after a year got billed for the budget warning service itself, which stopped being free. without have *any* other services running.

    For now I'll stick to budgeting and capacity by sizing "servers" I dont care if they are real or virtual as long as they are fixed price.

    I can code, do my own sysadmin, and devops, and its less effort and risk than trying to work out how AWS pricing works.

    1. Paul Crawford Silver badge

      Re: how much will it cost

      Not just "how much will it cost?" but also "how long will it continue to work before some numpty at the cloud/serveless/whatever provided decides to change your interface/data structures/supported APIs and break it?"

      Ever had the sad misfortune to rely on any Google's forever-beta products? If so you will realise your fancy new product won't last a generation, a century, nor or strange aeons, but 1-2 years tops.

      1. Trevor_Pott Gold badge

        Re: how much will it cost

        The individual applications wont' last long, it's true. But the black boxes themselves can. Oh, they'll change and evolve as they're maintained, but as a general rule, once invented, they won't be uninvented.

        If someone creates a black box that does facial recognition, we aren't going to find ourselves 50 years from now without a black box that does facial recognition. We may find that someone has created better facial recognition systems, but we will always have at least the original black box's capabilities.

        The digital skills being created accumulate until, one day, you'll be able to say "computer, watch the roses in the garden and water them if they start to show wilt", and it will happen.

        That phrase spoken to the computer is a script. It told the computer to gather a dataset consisting of images of the roses in the garden. It told the computer to send those images through a black box that determines if there is wilt. If there is wilt, it will trigger the garden's watering system. That, right there, is serverless. The only difference is the interface used to create the serverless script.

        The end user doesn't care if the black box that checks images of roses for wilt is the same today as it was yesterday. They only care that it works. All that matters to them is that a black box that performs that action exists, and that it doesn't stop existing.

        1. Anonymous Coward
          Anonymous Coward

          "but we will always have at least the original black box's capabilities."

          Are you sure? I'm not. And replacing them may still be complex.

          You may found the service you were using didn't generate enough revenues, so it gets shutdown, and an alternative may not be available. They may increase prices beyond what you are willingly to pay, maybe including a lot of orchids and mushrooms support you're not interested in at all, changing their interfaces in ways that force you to rewrite your script from scratch. Or maybe they'll drop roses support because the new fashion are tulips.

          If we are speaking about simple services, it's probably they'll exist for a long enough time. The issue will be more specialized services. I've seen interesting products disappear when bought by someone who saw advantages in using them exclusively, because of the competitive edge.

          1. Trevor_Pott Gold badge

            Re: "but we will always have at least the original black box's capabilities."

            Yes, I'm sure. I'm sure because already "serverless" doesn't mean "Amazon". Serverless has a lot of ardent followers, and they're building open source solutions that do what Amazon's Lambda does.

            Similarly, machine learning, AI, BI and other BDCA tools are seeing a lot of open source growth. In short: a commercial entity (like Amazon) might come up with the initial concept and get to milk it for a while, but all technology eventually ends up democratized.

            The basic approach of serverless - white simple scripts (or have a UI/digital assistant write them for you), and have those scripts simply pass data from one black box to another - isn't going away. Humans don't typically uninvent things, especially in IT.

            The increasing adoption of digital assistants also makes this seem like a permanent thing to me. The black boxes used by serverless types are really no different than the "skills" one can build for Alexa. Indeed, many of those skills are nothing but serverless scripts that call black boxes, and I've already seen Alexa used to create new serverless apps, which could be published as Alexa skills...

            The whole thing has already reached critical mass and started a cascade. While a bunch of whingy nerds who can't disconnect "application development" from "enterprise apps" might not get the importance of an ever-increasing library of digital capabilities that can be used by any Tom, Dick or Harry, non-nerds seem to get the importance really quickly.

            So we, IT nerds used to the way things were, we might not see the utility, or ever get around to using serverless to do our jobs. Our kids, however, will use serverless-style tech to do all sorts of stuff. Using - and trusting those black boxes will be as natural to them as smartphones are to my generation, or staring blankly at VCRs flashing 12:00 was to my parents' generation.

            So sure, in the short term I expect some of these black boxes to disappear. That will lead to a backlash, and to standardization, to the development of "skill libraries" and all of the predictable evolution of responses to this problem. Corporate greed is eventually overcome in tech, even it takes a decade or so for us to get our shit together.

            It is very early days for this technology yet, but the basic approach is sound. And those who have used serverless in anger tend to become adherents pretty quickly. Even the disenfranchised and cynical nerds.

  18. andy 103

    Isn't that just an API?

    Sorry, but:

    "build an application that reads an S3 bucket looking for uploaded sound clips, sends those sound clips off to a BDCA tool for natural language recognition"

    Yeah, and how is the reading and sending performed? If you're doing all of that with only a few lines of code, you're basically just calling methods/functions in other libraries of code that you yourself haven't written. That's essentially how most API's work.

    And as for " using little more than code snippets from Stack Exchange" I think you'll find that's how well over 50% of "developers" do their job.

    I was going to use the joke icon, but I'm not actually joking!

    1. Anonymous Coward
      Anonymous Coward

      Re: Isn't that just an API?

      "I think you'll find that's how well over 50% of "developers" do their job."

      In web development is probably over 90%.

      1. TRT Silver badge

        Re: Isn't that just an API?

        If you're API and you know it, clap your hands...

  19. Anonymous Coward
    Anonymous Coward

    That's has been the holy grail for some time, remember the CASE hype, than the visual programming hype, etc. etc.

    The hard truth is that finding exactly pre-made components that do exactly what you want, and just link them together with a little, simple glue code doesn't work outside simple demos.

    Programmers are usually tasked to create applications that before were not avalable to tackle specific needs, because each customer needs may be different enough to require skills.

    Sure, you didn't implement a database server from scratch, you bought it. So, "serverless" looks to mean "server software applications, just you don't buy them, you rent them from the cloud", and then you glue them together as you always did when you got data from your FTP server and then run data through an ETL software to load them into a DB to process them and then have data shown in your business analytics application. Just you do in the cloud, with some new server as well to process new kind of data like voice or the like.

    It's OK, I'm just sure the requirements and the orchestration of all the different pieces becomes quickly enough so complex you still need a programmer to implement all of them, plus the UI to let user access them.

    Otherwise, we'll se a lot of badly written, unmaintenable, ad-hoc arcane scripts - using services that today are here, and tomorrow you hope they're still there and didn't go bust and disappear. At least when the server and code were local, you could run them until you got a replacement....

  20. craigh

    I worry the author is bluring Capabilites and Serverless Environments

    My team differentiates between a Serverless Environment and a Capability/Service that may or may not be delivered from a Serverless Environment.

    My reading of this article is that the author is describing the ability to build and offer Capabilities behind an API but there is nothing abut his descriptions that means the people offering them have to be using or benefiting from a Serverless Environment. The whole point of a Capability is that it is a black box to any other application using it, so they should not know or care what is happening under the hood.

    For us a Serverless Environment is something that AWS/Azure offer us to deploy code into alongside Capabilities they offer such as a DB or Storage. We are able to deploy our code behind an end point without any concern for the underlying infrastructure that the code is running on. We know that within the limits we are paying for, each time that end point is hit our code is executed and the environment our code is in is surge resistant, resilient and scalable while still only costing us what we use.

    The key element for us that makes what we are building as a dev team Serverless is that the degree of abstraction between our code and the environment we are running our code in is so great that it is no longer something we need to maintain or spend much time concerning ourselves with.

    The cost of this simplicity is a significant degree of lock-in where our code is developed and optimised for the Serverless Environment we are building for. This makes each Capability we build in it pretty sticky. However the lock-in is only at a Capability level. Each Capability is a black box to the others in our solution so we can migrate some or all of our Capabilities between different environments fairly painlessly as and when our business case justifies it, running two in parallel until we are comfortable shutting down the one we are moving from (given pricing we often can just stop using the original one, leaving it there should it be needed).

    1. Trevor_Pott Gold badge

      Re: I worry the author is bluring Capabilites and Serverless Environments

      @Craigh You are correct: there is no reason for various cloud features (such as BDCA tools) to be tied to serverless. On the other hand, serverless doesn't offer you much of any real use except the ability to push data into and pull it out of various cloud features.

      The point here is that serverless basically allows one to lash together some pretty complex applications about as easily as one could write a (reasonably simple) batch script.

      Real developers will build the various black boxes. Trained IT practitioners will be able to use those black boxes wither through serverless or other cloud solutions. But for the milled masses, serverless will be their gateway to application development.

      Right now, today, in order to build serverless applications you need to actually type a few lines of code. But the code you need to write in order to pipe data from A to B to C and back out again is simple. It's the sort of thing that you could build into a drag-and-drop GUI and have 4 year olds use.

      Nerds think about serverless from the viewpoint of "how does this help me do what I do now"? Non nerds don't do any of this now, and when shown how easy serverless is, say "wow, look at all the neat things I can do that I couldn't do before".

      So serverless - in the form of AWS lambda - is itself pretty useless. But it is this gateway to all the other things that Amazon's packed into AWS. It isn't the only way to use all of AWS's goodies, but it absolutely is the means by which individuals who aren't specialists, trained practitioners or experienced cloud architects will set about making tools for their own needs.

      1. craigh

        Re: I worry the author is bluring Capabilites and Serverless Environments

        @Trevor_Pott I absolutly agree that a servless environment lowers the barriers to delivering some fairly impressive looking functionality, however we have found a way to do a lot more than pull data in and out of different features.

        Part of what we do in our own code involves extensive file analysis, transformation and generation. Some of this is all our own work and some utilises the same third party libraries that we have used in our native applications.

        There are potential solutions to parts of what we are doing, offered as capabilities by the cloud providers however our need is very niche and not what those capabilities are aimed at meeting. The pricing model for this capability is so out of kilter for what we need at the scale that we need it that it is more cost effective to do it ourselves inside the Serverless Environment they offer for our code to run in.

        This niche element does bring something else into the conversation, the impressive looking functionality that can be bolted together easily faces a significant commercial challenge if it is to become anything other than a gateway to other things.

        The technical barriers to entry or competition to anything built this way is very low, if there is the slightest possibility of gaining something from a solution built in this way then competition will quickly emerge driving down the margins possibly to zero if the gains to others do not require them to earn from it. Should that application be generic enough to access a large market then you can expect to see the cloud providers bolting things together themselves and offering it in a much slicker package.

        We have migrated or cancelled some work after starting it as functionality we needed within our solution became available to us and was packaged up and delivered more effectively by the cloud providers, I expect this trend to continue meaning that it is the complex niche products able to flex to customers needs that will survive being commoditised for the longest.

        1. Trevor_Pott Gold badge

          Re: I worry the author is bluring Capabilites and Serverless Environments

          @criagh yes, but you are doing enterprise work. Application development for commercial purposes. What you - and all the rest of the angry nerd mob of commentards are missing - is the part in my article where I very specifically said "It is the commoditisation of retail and consumer application development".

          Serverless isn't going to replace traditional development for organizations looking to build their own middleware anytime soon. VMware isn't going to make their next vSphere UI using serverless. That's not where the revolution comes in. The benefit of serverless is not "helping highly trained nerds do what they already do better", despite the inability of the commentariat to conceptualize anything different.

          Serverless is going to let people who are not nerds create applications that solve problems that nerds and commercial entities are not normally interested in.

          For example: Let's say that i want to grow cannabis plants at home. (In a few months we can legally grow 4 plants per household here.) Cannabis is a particularly persnickety beast to grow. Much more so than the bell pepper plants that I have all over my house.

          With serverless, I could take data from my house - images of my plants, or perhaps sensors similar to these - and feed that data into a black box up in the cloud. I could set the thing up so that if A happens, the plants get watered, if B happens, a fan turns on and if C happens, it sends me an alert.

          Traditionally, if I wanted something like this I would have a few options:

          1) Build something myself involving an ardunio (lots of work)

          2) See if a vendor has already build a pre-canned solution, probably involving their own sensor ($$$)

          3) Hire a human ($$$$$$$$$$$$$$$$$$$$$)

          With serverless, however, I just need someone to write a "black box" that can accept some form of data I can provide (images, sensor data, etc) and spit out simple data about the plant in question. That black box does not, to my knowledge, exist today...but I am sure it will soon. (I could even train my own black box using machine learning, but that's another discussion.)

          Essentially, serverless is a scripting platform allowing access to an ever-increasing number of "skills" or "capabilities", in a marketplace-like format. A platform I don't envision being used to replace super-niche industry development, but one I envision being used by civilians to automate and enhance their daily lives.

          Application development is already a thing that is out there enhancing businesses that can afford qualified nerds. Now it is going to start being something we can use in our day-to-day lives to collect, modify and act on the data around us.

          1. craigh

            Re: I worry the author is bluring Capabilites and Serverless Environments

            @Trevor_Pott Good example, I agree that the scenario you paint is possible and even likely, its just got nothing to do with the fact that where you create this glue between black boxes is serverless.

            You can create all sorts of environments for gluing API's/Black boxes together, you can offer this environment in a multi-tenanted way within any number of commercial models to different hobbyists and others to work in. You have an example of one such environment that happens to be serverless but there is nothing about it being serverless that is essential to offering what it does or what you are using it for.

      2. Anonymous Coward
        Anonymous Coward

        Re: I worry the author is bluring Capabilites and Serverless Environments

        > Right now, today, in order to build serverless applications you need to actually type a few lines of code. But the code you need to write in order to pipe data from A to B to C and back out again is simple. It's the sort of thing that you could build into a drag-and-drop GUI and have 4 year olds use.

        Yes, in cloud-cuckoo land.

        Even if you are just using black boxes, any real application will need to:

        * store the data returned somewhere for later use (something like "variables")

        * extract part of a response to pass to another service

        * make if-then-else decisions or loops

        * make sensible decisions about when to retry and when to give up

        You can front this with a GUI, which might look like Stretch, but very soon your orchestration layer becomes a messy, crippled programming language of its own. Let me give you a couple of real-world examples:

        * AWS Step Functions

        * Openstack Mistral

        Both have a YAML or JSON language to define which steps to do and their interdependencies. SF | OM

        Both have a sub-language to extract sub-elements from JSON data. SF | OM

        Both are great examples of Greenspun's Tenth Law (no particular love of LISP here, feel free to replace with "any sane programming language")

    2. Doctor Syntax Silver badge

      Re: I worry the author is bluring Capabilites and Serverless Environments

      " the environment we are running our code in is so great that it is no longer something we need to maintain or spend much time concerning ourselves with."

      And that, folks, is how you end up with a security nightmare.

      1. craigh

        Re: I worry the author is bluring Capabilites and Serverless Environments

        @Doctor Syntax pointed but not necessarily true.

        Our engineers have invested time in understanding this environment and the potential issues we face using it but they need to invest less in low level concerns than they did in the past and once up to speed need to invest less time in maintaining what we have done and can invest more in helping us improve what we do.

        Our developers have also been brought closer to the security issues we could face meaning we two sets of eyes with different skills sets and backgrounds looking at the challenge all supported by the Cloud providers who have a vast pool of expertise and a real incentive to help us to keep things secure.

        We are aware of the high profile headlines associated with cloud security but see little indication that it was caused by anything more than organisations failing to properly assess and adress where the risk to their systems and data lie in a Cloud environment.

  21. Anonymous Coward
    Anonymous Coward

    Starting a serverless project

    So, I'm starting a big FaaS project in a few weeks. It's being developed on a derivative of OpenWhisk. The back end will be NewSQL, NoSQL, S3 blob storage and a custom distributed logging database.

    We are using Banana Pi as the platform and expect to be able to handle transaction processing for 100,000+ users on a few devices. We'll have 9 Banana Pis as compute and storage, 3 Banana Pi routers as switches and cold storage and two Cisco C3560CX switches as distribution.

    We have done some experimentation and found that we can handle insane amounts of transactions on this platform by adopting FaaS.

    See, the thing is, we know we can build huge business systems on this platform because it's basically the same thing as CICS, COBOL, DB2 and RPG. We can also scale if we need to by adding more Pis. It doesn't cost anything and frankly, we don't need to run any of the heavy stuff on servers anymore.

    See, AD is in the cloud. Exchange is in the cloud. DropBox is in the cloud. Collaboration is in the cloud. Accounting is in the cloud. All these systems simply make more sense to put in the cloud. DropBox might come back home someday, but we can write it ourselves and run it on our Pis if we need to.

    All that's left is our business software. And our business software is a series of web pages that we store as blobs with the GUIDs linked to filenames in a table, and REST calls which are transactions. Transactions are cheap if you don't go through virtualization or containers.

    Also, we're building full RBAC and security into every single function and class. As such, we'll be substantially more secure. We're running as little C or C++ code as we can and we're 100% TDD.

    For backup, we have a separate site with traditional tape backup. Since our data set should never be measured in gigabytes as we're only storing a few hundred thousand records... maybe a million at most, we'll never need to have big storage. We simply have a bunch of drives for failover to avoid using enterprise SSD which is just wasteful.

    The beauty of serverless is that it will allow us to pull our business systems back out of the cloud and make them manageable again. If a node breaks, unplug it, throw it away, plug in another and it will be up and running in 20 minutes. Because of using a lot of little nodes all running exactly the same code, we won't even notice the outage.

    Serverless is amazing. Back to mainframe we go... and I can't wait.

  22. Bucky 2

    Everything old is new again

    They told us this in the 80s.

    It's time for career counselors in high schools to once again steer kids away from computing as a career. It's all going to be obsolete Real Soon Now.

    Unless, as before, it turns out that the general public is just too staggeringly lazy to bother.

    1. Doctor Syntax Silver badge

      Re: Everything old is new again

      "It's time for career counselors in high schools to once again steer kids away from computing as a career."

      Yes

      "It's all going to be obsolete Real Soon Now."

      But not for that reason. See the discussion on the ITC apprenticeships article.

  23. dnicholas

    We're stumbling towards a generation of dribbling idiots who don't know how anything works.

    Did you know there are people in their twenties who don't know, and will refuse to try, wiring a plug?

    1. ecofeco Silver badge

      We're stumbling towards a generation of dribbling idiots who don't know how anything works.

      Pfft. We've been there. Since day one.

    2. Ken Hagan Gold badge

      "Did you know there are people in their twenties who don't know, and will refuse to try, wiring a plug?"

      That's hardly surprising, since it has been illegal for ages to actually buy something that required you do that. I dare say there are *lots* of things that are easy but unnecessary.

  24. ecofeco Silver badge

    Serverless is a stupid name

    Something more like "programless" or something along that lines. (I'll think of a clever name but I sure as hell won't tell you lot! Still trying to create a retirement fund, you know?)

    I've always been a big fan of having computers do the heavy lifting. It is, after all, their sole purpose in life.

    If I can create an application that can sort what was once disparate data and produce useful and practical information faster than all previous methods, then bring it on!

    I've seen glimpses of this already and it's very cool. Well, the stuff that works right, anyway.

    Here's one example (I cannot vouch for its quality only that it's not the only one) https://www.appmakr.com/

    1. Ken Hagan Gold badge

      Re: Serverless is a stupid name

      "If I can create an application that can sort what was once disparate data and produce useful and practical information faster than all previous methods, then bring it on!"

      Umm ... UNIX command lines, shell scripts, pipes, tools that do just one thing ... and it probably wasn't a new idea then. (Someone else has already mentioned "subroutines", which is another perfectly fair example of the same concept.)

      1. Trevor_Pott Gold badge

        Re: Serverless is a stupid name

        Ease of use is the difference. Yes, serverless is basically "scripting for noobs". But the "for noobs" part is really critical.

        Yes, really smart, well paid, highly experienced nerds can write a bunch of gobbedly-gook scripts, or write applications in proper development languages that called libraries or other application components. That's hard. And it requires expertise. And if you are incorporating some black box (application, library or other component) into your solution you first have to find it, download it, install it, make sure it's in the right place to be called, etc.

        Almost all of that goes away with serverless. You write what amounts to a script, but you have access to this (constantly growing) library of tools and features supplied by the cloud provider. Making use of those tools and features is generally much easier than a bash script, and you don't have to manage or maintain the underlying infrastructure in any way.

        When you take something that requires significant expertise and make it something that nearly everyone can use, that's a pretty big deal.

        I'm sure that there were a bunch of nerds who knew how to build and maintain their own electrical generators who also said that national grids were a stupid idea. If they can run their own generation capacity, and wire up their homes/businesses exactly according to their own specifications, why can't everyone? Standardization means everyone isn't using the optimal plug/wire gauge/whatever for the job! There might be inefficiency! A national grid won't be revolutionary or change everything, because people can use electricity now!

        I, for one, am glad nobody listen to them.

        1. Anonymous Coward
          Anonymous Coward

          "You write what amounts to a script"

          I believe the illusion lies here. Sure, in the very beginning the script will be small and easy, especially in demos. Soon, they will grow in complexity. And will become programming languages with all the related skills needed to use them.

          One of the biggest advantages of software compared to other solution is exactly customization to fit specific needs. The more specialized a subsystem is, often the less versatile it is. It could also be a great opportunity for a few to hinder competition, and chain customers even more. It's also difficult to leverage IT as a competitive advantage if all you can do is use pre-made receipts as everybody else.

          For some, the real advantage is "you don't have to manage or maintain the underlying infrastructure". I understand, instead of renting a cloud VM and maintaining the software yourself, you rent the software as well.

          You have to trust the supplier even more, because you're now actually feeding them your data for processing, so you have really no way to protect them. And one day the TOS could be easily changed to assert you're paying with your own very data also.

          About the power grid, you see more and more people installing solar panels to become more and more independent from the grid. But the grid was born and used before many people had access to the technology to generate power at acceptable prices. And a shared grid itself has issue - look at the other article today on the spikes recharging cars will introduce.

          Yet, for heating, local systems are still the norm despite grids to deliver heat are being also built.

  25. Erik4872

    Serverless is just another abstraction layer

    All serverless is is the next generation of API-only applications. Instead of having dedicated instances of...anything...you just pass a JSON blob into a URL and...somehow...you get a response blob and/or a set of actions. The main difference is that you don't even care where it's going or how it's working...but under that tower of abstraction is a real set of web servers somewhere.

  26. JohnFen

    So, in other words...

    "Serverless" just means "4GL in the cloud"?

    Just trying to get a handle on this. It's still one of the stupider terms I've heard in a while, though, considering that servers are more heavily involved than ever.

    1. Dan from Chicago

      "Codeless" maybe?

      The server aspect seems rather orthogonal to your intent, calling it gluten-free technology seems to be as suitable a term as serverless.

      :-)

      1. Trevor_Pott Gold badge

        Re: "Codeless" maybe?

        If we did call it gluten-free, we'd probably get a whole bunch of new people interested in application development! :)

  27. Lord_Beavis
    Facepalm

    Marketing Droids

    Sounds like that "Cloud" nonsense all over again.

  28. DaveN007

    Serverless is a revolution

    It's the only way to run codeless software that I don't care about. I have found that the less I care, the better the result. I feel much better since I gave up...hope. I do all of this uncaring is the most snarky way possible.

  29. Anonymous Coward
    Anonymous Coward

    'Serverless' the next Nirvana ....... form a queue here !!!

    Yet another attempt to sell a solution to a problem you did not know you had.

    The 'people who do' (the ones who make the money in your company & require all the 'Computers, Screens, Data etc that the Techies/Programmers provide and keep working each day) have always had a problem with the 'need' for a group of people who 'get in the way' of doing business and who take too long to supply whatever they need.

    At regular intervals some 'Wizard' comes along and tells them about the new magic solution to all their problems. No more explaining what you want to people who don't understand, no more waiting for solutions that take weeks/months/years to appear, and no more people hiding behind 'Techno babble' when you don't get what you wanted (or thought you wanted).

    Cue the next 'Magic Solution' ......... it will not work other than in a few very specific well defined cases as per usual. :)

    What we will all experience will be another dash to get the advantage over your companys competitors, at great & increasing cost and effort.

    There are NO easy and simple solutions that will eliminate the need for the IT Dept etc :)

    Business solutions will not be able to be 'Simply' built with some sort of 'up-market Techno LEGO' set.

    The first realisation will be when the first Prototype goes 'Live' and the SLA's sudden cannot be met due to 'events out of the control of the Company'.

    At that point the IT Dept will get lambasted for allowing this to happen ...... ignoring that warnings were raised, by IT, and ignored as a small but acceptable risk. :) :)

    Very entertaining to watch, ONLY if you are not the poor people who are tasked with proving its value in the Prototype Project.

  30. Anonymous Coward
    Anonymous Coward

    Marketing of Serverless Nonsense

    While it must have been fun to blend together a bunch of IT concepts and claim they are somehow related to so-called Severless Compiting, it’s not useful. Spinning up server apps on a just-in-time basis for the duration of the users needs and then spinning them back down until needed again is not new. It also creates needless latency to the user. Server less is not the holy grail of anything. Move along, nothing to see here, real innovations are coming. Eventually.

  31. Neoc

    Oh goddess... It's COBOL all over again. And didn't *that* turn out well. By the time you actually write something complex enough to be useful to a major company (or gov department) you might as well be a programmer.

  32. Iain53

    Ewwww. Reading these comments is like reading about how much Socrates detested the young people of his age. There will be change. I'm not sure that human beings will necessarily be of any use except to be users. Full circle.

  33. Anonymous Coward
    Anonymous Coward

    I wholeheartedly support the move to serverless

    The well paid consultancy jobs generated by this move, going in to sort out the utter mess businesses will get into through letting the local sixth-former write the enterprise software, should see me through to a comfortable retirement!

  34. rav

    Serverless? So what is it?

    The entire piece does not define serverless except in terms of what it is like.

    Drop the metaphors and get real will ya?

    Oh I get it, you don't know what serverless is either.

  35. SnapperHead

    What? No mention of Lambda??

    I'm not sure how to discuss this topic without a large and illuminating dose of Lambda in the discussion.

  36. khentiamentiu

    Huh?

    Amazing how you can go on at such length without once providing a succinct definition of "serverless." For those of us who are techbabble neanderthals, define, please.

    1. Hargrove

      Re: Huh?

      @khentiamentiu

      BRAVO!

      Words and what they mean matter. At one time dictionaries were among my favorite reading material, Now. . . Well to quote Humpty Dumpty in Through the Looking Glass, "Glory!" (which he defines as "There's a good knock-down drag out argument for you" when Alice challenges him.).

      We live in a post-truth Looking Glass world where, to paraphrase Humpty, words mean whatever the person using them intends them to mean.

      Unfortunately, even dictionaries have become corrupted. They are dealing this by simply discarding long standing wording of definitions in favor of the moral equivalent of self-licking ice cream cones, to wit (to offer my own modest neologism):

      serverless -- not having or appearing not to have servers

      By tolerating this kind of insanity we are all complicit in the continuing degradation of the defining characteristic of humankind--symbolic language and our ability to communicate. We are effectively destroying our ability to relate to one another as human.

      This will not end well for us.

      Terrence Deacon in his book "The Symbolic Species" introduces Hoover, the world's first and only talking seal. Maybe, if Hoover's lucky enough to find a mate with the right DNA, the seals will do better.

  37. Robert D Bank

    Applicable

    That's what I'd call it

    As someone that couldn't code to save my life (and yes to lazy/stupid to learn as it's not an interest) it sounds interesting as a means to bring a great commercial idea to life, and maybe generate an income stream. In terms of the scalability, security and performance I expect Cloud providers might come to the party on that to help and bring more customers on board. You might see deals available where you get the service at a price offset by the Cloud provider taking a cut of your revenue stream. Both parties win on that score.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like