back to article Developers, developers, developers: How 'serverless' crowd dropped ops like it's hot

What is serverless? Sure, the name serverless sounds stupid, but serverless technologies like AWS Lambda are increasingly being used by developers looking to build applications quickly. The key word is developers. Serverless is all about giving developers the ability to execute code without requiring sysadmins. There's no …

  1. Doctor Syntax Silver badge

    "Consider a facial recognition function for a security system."

    And how does it handle loss of internet connection?

    1. Anonymous Coward
      Anonymous Coward

      Magic Pixie Dust

      1. bombastic bob Silver badge
        Unhappy

        "Magic Pixie Dust"

        yeah, thinking of 'magic pixie dust' [the entire concept, IMBO]

        Consider the "magic re-use of existing term" 'Lambda Function' - I wonder how long it will take before its existing definition is displaced in online searches with this "new, shiny" version...

    2. Bill M

      The same as with any other loss of internet connection, the solution is to go to the pub. If their wifi internet is also down then have a beer. If their wifi internet is up then what the hell, you may as well have a beer.

  2. Anonymous Coward
    Anonymous Coward

    Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

    This is for toy web & phone applications. When AWS and "serverless" (aka anonymous servers) can run a business critical 500K line multiprocess realtime C++ application connected to a terabyte sized Oracle** cluster we might start giving a shit and considering it at a serious corporate service. Unless then we'll stick with actual physical servers run by people who know what they're doing and can be called upon within seconds if there's a problem.

    ** Yes I know Oracle the corporation are a bunch of ****** and their support apps are generally crap, but their core RDBMS is the best in the business so lets not get into that argument.

    1. Anonymous Coward
      Anonymous Coward

      Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

      When AWS and "serverless" (aka anonymous servers) can run a business critical 500K line multiprocess realtime C++ application connected to a terabyte sized Oracle** cluster ...

      You're missing the point: if you're building a new app as microservices, then it won't be 500K lines of C++, it will be structured as separate services which call each other either directly or via queues. If that's what your app looks like, then Lambda suits it well.

      Furthermore, you *can* run your Oracle cluster in Amazon - it's called RDS for Oracle. Whether it's more cost-effective at terabyte size to have your own hardware + licencing + DR + sysadmin team, rather than using RDS, is something you'll have to evaluate for yourself.

      1. Anonymous Coward
        Anonymous Coward

        Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

        "You're missing the point: if you're building a new app as microservices, then it won't be 500K lines of C++, it will be structured as separate services which call each other either directly or via queues"

        If the new app can be built as small seperate RPCs (because thats all this really is) communicating via queues then its A) not realtime, B) inefficient C) become an unmanageable mess at any reasonable code size and far harder to debug than even the worst event driven program. RPCs have been available since the 80s, however there's a reason they were never used in anger. I'm waiting for the current generation of wheel re-inventers to discover why.

        "Furthermore, you *can* run your Oracle cluster in Amazon - it's called RDS for Oracle"

        Yes, I wonder what the network latency for that is?

        1. Nick Ryan Silver badge

          Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

          Not just debugging as such... but wait until you get to version control and code/setup comparison of such functions/containers/RPCs. Also building a test/dev instance that is guaranteed to be entirely independent of the live system but identical in configuration because otherwise testing is not valid.

          No problem? Let's just reinvent some more wheels and push debugging and version and deployment management into the distance as they're not important.

          /sarcasm, for those that don't spot it.

          Now I'm off to try and help track down application issues in a system where the business logic is splattered across the front end, server application files, server binary files, web services, and database stored procedures. Just add some standard MS-SQL transaction handling and row/block level locking into the mix and we're going to have a day...

        2. Jonathan 27

          Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

          Why would anyone, anywhere ever use Oracle as a backend for new web app development? Tying yourself down to a legacy technology stack like that doesn't make much sense. And if you're not writing a new web application (or a intensive but non-time sensitive compute task) then AWS Lambda doesn't make a whole lot of sense.

          It doesn't sound like AWS Lambda doesn't make any sense for what you're doing, but that doesn't meant it doesn't make any sense to anyone.

          1. Korev Silver badge

            Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

            Out of interest what would you use? Not trolling, I'm just a bit out of touch with the field and am curious.

          2. Anonymous Coward
            Anonymous Coward

            Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

            "Tying yourself down to a legacy technology stack like that doesn't make much sense."

            Neither Oracle nor SQL is legacy despite what the NoSQL vendors may have you believe. Having used Mongo in anger I can assure you I'd far sooner use a relational DB for almost all business operations except for simple document storage and lookup as it sucks at just about everything else.

        3. Graham Cobb Silver badge

          Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

          If the new app can be built as small seperate RPCs (because thats all this really is) communicating via queues then its A) not realtime, B) inefficient C) become an unmanageable mess at any reasonable code size and far harder to debug than even the worst event driven program.

          Complete rubbish. You have no idea what you are talking about.

          Real-time, efficient, message-passing kernels have been around in embedded systems for over 30 years. Large real-time applications have been designed and built on them very successfully. I can tell you, from personal experience, that they are much more manageable and much easier to debug than integrated, event-drive programs.

          Just the built-in, optional but always available, real-time message tracing makes it a breeze -- I never added a single debugging printf to a piece of professional code until I stopped using those environments! And the simulators we had which allowed us to simulate the message-passing kernel as a user process on a workstation with the full real services running and a full debugger attached allowed us to do easy debugging of complex kernel and driver-level code.

          Of course, AWS Lambda is not a real-time, efficient, kernel for embedded systems. But the development process it enables is extremely powerful, friendly, efficient and already widely used. Only toy (or "enterprise") applications are built as monoliths.

          1. Anonymous Coward
            Anonymous Coward

            Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

            "Complete rubbish. You have no idea what you are talking about."

            I do actually, but you're entitled to your own opinion.

            "Real-time, efficient, message-passing kernels have been around in embedded systems for over 30 years"

            And almost no one uses message parsing kernels any more because they're slow. None of the major OS's use it and neither does embedded linux. Minix used it and look how well that didn't do out in the wild. Message parsing is a lovely idea on a whiteboard with a bunch of neckbeards nodding sagely, but when microseconds matter it just gets in the way.

            1. Anonymous Coward
              Anonymous Coward

              Re: "message parsing kernels ... they're slow"

              "no one uses message parsing kernels any more because they're slow"

              Message passing (parsing?) systems aren't particularly slow to run on any half decent modern system, but there may have been some genuine performance issues back in the 1980s, back in the era of the VAX11/750 and such, and maybe a decade or so before Windows NT arrived.

              Systems based around message passing may be slow to *develop*, because they may require enforced use of good and well established design principles (from, say, the 1980s) which have long since become unfashionable in most of the software world. They happend to be design principles which significantly increase the chances of a particular piece of software behaving properly when it's delivered, but that apparently doesn't matter much these days.

              The concepts behind message passing and the like have been around for a long time and can be implemented in most sensible programming languages by people with a clue about systems design. From time to time the concepts become particularly fashionable and end up with particularly fashionanable implementation languages, e.g. Occam (the original language for Transputers), and more recently maybe, Rust.

              The definitive work on the topic must surely be Tony Hoare's 1985 book, Communicating Sequential Processes. It's a bit mathematical and abstract, but there are alternative views elsewhere without the same levels of abstractness. Hoare himself somehow ended up working for Microsoft Research.

              https://en.wikipedia.org/wiki/Communicating_sequential_processes

              http://www.usingcsp.com/ (leads to freely downloadable copy of the 1985 book)

            2. Trevor_Pott Gold badge

              Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

              "Minix used it and look how well that didn't do out in the wild"

              Minix is easily the most widly deployed OS in the world. It's in every Intel IME, and a whole heap of other embedded systems.

              Think before engaging keyboard, mate. There's a lot more to tech in this machine-to-machine world than end-user-facing OSes.

              1. Anonymous Coward
                Anonymous Coward

                Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

                " It's in every Intel IME, and a whole heap of other embedded systems."

                Err no, there are allegedly parts of minix in Intels IME, they're not saying one way or the other. And do you really think they'd have kept the message passing side when this stuff has to run in microseconds in an interrupt? Remember , this is inside the main processor, its not AMT which resides in a sideband CPU.

                "Think before engaging keyboard, mate. There's a lot more to tech in this machine-to-machine world than end-user-facing OSes."

                Wow, thanks for the heads up there Yoda. Wish you'd been there when I was studying OS's back in the day.

                1. Trevor_Pott Gold badge

                  Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

                  Maybe if I had been, you'd have learned a few things. :P

            3. Anonymous Coward
              Anonymous Coward

              Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

              What minix, the real time OS that is running on every single Intel processor?

              Yeah, no one uses that.

      2. Down not across

        Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

        Furthermore, you *can* run your Oracle cluster in Amazon - it's called RDS for Oracle. Whether it's more cost-effective at terabyte size to have your own hardware + licencing + DR + sysadmin team, rather than using RDS, is something you'll have to evaluate for yourself.

        It's not really a cluster. Not the way RAC is. RDS also has size limitation. You pay more for your licensing on AWS than you would on premises. Also, don't forget to factor in things like network traffic in your costing.

    2. Anonymous Coward
      Anonymous Coward

      Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

      Wow, a whole terabyte of data! So impressive!!!! Tell me, is that per day or per hour?

      If you think someone is going to be impressed with 1TB of data you are seriously out of touch with CS.

      From what I understand petabyte has become the defacto base unit at GOOG, as in:

      "We're nearly out of space in this cluster, only 5pbs left."

      "I deleted some old indices, but it only freed up 10pb of space."

      1. Anonymous Coward
        Anonymous Coward

        Re: Cloud, REST, HTTP, PHP, trendy NoSQL DB de-jour, blah blah, whatever...

        "Wow, a whole terabyte of data! So impressive!!!! Tell me, is that per day or per hour?"

        Sorry, I didn't realise this was a dick waving contest. My mistake. A terabyte is a lot of data when it doesn't involve video.

        "you are seriously out of touch with CS."

        You might want to get a clue before you post. No wonder you posted A/C.

  3. Alister

    ...and is it a good idea?

    Serverless is all about giving developers the ability to execute code without requiring sysadmins.

    Given the recent large numbers of incidents where private data has been dumped in an S3 bucket and then ALL THE SECURITY TURNED OFF, I would suggest that developers shouldn't be trusted to do anything without sysadmin supervision.

    1. Nick Ryan Silver badge

      Re: ...and is it a good idea?

      Been there, got the badge, sparkly certificate and a clue-by-four. Application security issues? No problem, just grant everybody administrator access. Fixed.

      1. dan1980

        Re: ...and is it a good idea?

        Yep.

        Had an issue where a developer just stuck with the: "these are the settings that work for us" line and just wouldn't troubleshoot their application to figure out what perms were actually required.

        Just code as though the applications have full access to absolutely everything and things will work themselves out. Permissions, after all, are far too 'OPsy' and just slow down application development.

    2. rnturn

      Re: ...and is it a good idea?

      "I would suggest that developers shouldn't be trusted to do anything without sysadmin supervision."

      Well, maybe not full-time supervision but, for $DIETY's-sake, at least some contact with the admins during the design phase. I've been suspicious of developers' ability to /not/ make insecure applications ever since having to ride herd over a VMS system running a treasury/securities application that, because of the laziness of the developers, required end-users be granted BYPASS privileges. Auditors were in the admins' camp and wanted it disabled (or, preferably) removed but we found it was, indeed, required and we had to get an official document from the vendor to that effect to satisfy the audit team.

  4. Philip Storry

    A true paradigm shift!

    We appear to be seeing a true paradigm shift in the industry. Automation and innovation is removing the need for the traditional core sysadmin roles - sizing, configuring and running applications and their infrastructure.

    Yes, the only part of a sysadmin's job that will survive is the part we like the least - security.

    Basically, you now only need a sysadmin if you have any data. Which must be a terrible relief to all those businesses out there that don't keep or process any data.

    For the rest of the world, sysadmins will continue to be an awkward fact of life. Let's look at the example given in the article:

    "For this use case, a security system that has extremely basic facial recognition built in is presumed. The on-premises security system's facial recognition is presumed to be just powerful enough to tell that there is movement on the camera and that a face is likely exposed to the camera. Once it detects a face it uploads a snapshot of that face into an Amazon S3 bucket."

    So, we have personally identifiable information (a face, in an image 'snapshot') that is uploaded to third party infrastructure over a publicly accessible network. Now I'm sure that this is all done with appropriate encryption - Amazon probably won't offer unencrypted connections anyway. But how is it stored? What are the retention schemes? Who's got access to it? Who enforces that access and how? Who does audits and assumes responsibility for the results? Are new levels of access and auditing required once DPA requests become something the business has to handle?

    These developers are in for a nasty shock - possibly in a legal sense - if they think they're not going to be doing any more Ops in their DevOps.

    If you have data, you need a sysadmin. You can attempt to automate a lot away, but you still need someone to ensure your data is properly handled. If your business wants to hand that off to management or developers, please let me know - I need to make sure I don't own any stock or use the services of your company.

    Still, like I said - this is truly a boon for all those data-free companies out there!

    1. Anonymous Coward
      Anonymous Coward

      Re: A true paradigm shift!

      "Basically, you now only need a sysadmin if you have any data. Which must be a terrible relief to all those businesses out there that don't keep or process any data."

      I'm wondering how long it'll be before someone (probably american) completely fails to spot the sarcasm in that and berates you with some choice insults.

    2. Steve Button Silver badge

      Re: A true paradigm shift!

      Dataless. That's the future young man! If only all our apps don't need any data, then there would be no need for any sysadmin, or security.

      1. Munchausen's proxy
        Pint

        Re: A true paradigm shift!

        Dataless. That's the future young man! If only all our apps don't need any data, then there would be no need for any sysadmin, or security.

        Software-Defined Data. I see it coming.

        No, wait. Hyperconverged Software-Defined Data.

        Data-driven hyperconverged software-defined data.

        Yes, I think that's it. Is it Friday yet?

        1. rnturn

          Re: A true paradigm shift!

          Don't forget the "hybrid" variant for the folks that don't want to jump in with both feet.

      2. sysconfig
        Coat

        Re: A true paradigm shift!

        Dataless. That's the future young man!

        Oh, so the "big data" hype is already over?

    3. Lysenko

      Re: A true paradigm shift!

      Still, like I said - this is truly a boon for all those data-free companies out there!

      While I mostly agree with you, you are missing the fact that some companies have a lot of data that are neither confidential nor anything to do with people. We have systems that process, store, and analyze tens of thousands of temperature, humidity, and power readings per site, per hour. There isn't a single GDPR or other compliance relevant datum in there and no-one really cares whether the data is secure or not (in the sense of unauthorised read). What we are interested in doing is deriving models, correlations and graph functions to improve predictive accuracy and some of that is processor/RAM intensive.

      If you have data, you need a sysadmin.

      Not necessarily.

  5. Anonymous Coward
    Anonymous Coward

    IFTTT for grown-ups?

    So its IFTTT for grown-ups?

    Or maybe Inversion of Control (IoC) for the cloud?

    1. Anonymous Coward
      Anonymous Coward

      Re: IFTTT for grown-ups?

      Something inspired by IFTTT was my first reaction too.

      And also maybe someone's finally noticed that the event-driven dataflow-oriented development/deployment paradigm (yuk) exemplified by National Instruments LabView and friends can actually be used by non-programmers for certain classes of application.

      And why not.

      Maybe.

      Have a lot of fun.

      (What are NI users going to do when Windows is no longer a viable runtime environment for them, and the application(s) in question can't go into the cloud?)

  6. Anonymous Coward
    Anonymous Coward

    I'm a developer, but I have a fairly extensive 'Ops' knowledge, I run a home dev network across multiple sites/subnets that I configured myself using virtual (VM) gateways. I built this dev environment to be exactly that, a pre-configured place where I can dream up a fanciful app, and get on playing, rather than worrying I'll need a DB server for this web server for that etc. Just build and chuck it on the existing environment. It has an isolated DMZ, so when the playing is done, I can publish it as securely as I know how.

    What I don't understand: I seem to be the only developer I've met who 1.) felt a need for such an environment and 2.) had the skills/interest/dedication to actually build it.

    If you're building an application, you're building it to run on something. I want to know about that something so I can build for it as best as possible. I'm left looking at my colleagues who barely understand TCP/IP and thinking WTF! How can you develop for a platform (whether that be some cloud service, a mobile or desktop OS, browser or whatever) without understanding and knowing the platform?

    And now we're telling them there are platform-less platforms on which they can run their apps, so even less concern for them.

    1. Anonymous Coward
      Anonymous Coward

      Here's one that Peter prepared earlier

      "I seem to be the only developer I've met who 1.) felt a need for such an environment and 2.) had the skills/interest/dedication to actually build it."

      Maybe it's just me, but what you've described sounds (in principle) to me a lot like what I used to do with Bitnami a few years ago. I was interested in the idea of virtual appliances (to coin a phrase) but didn't have the skills or time or funding to do it myself, so I found ones that someone had prepared earlier.

      But it got stomped on by the IT Department, 'cos I was a developer and couldn't be trusted with admin privileges to install anything or even boot a not yet IT-approved (and never will be) system image.

      Anyway, go read about Bitnami, and if there are others similar (or better), maybe they'd be of interest to readers here too.

      Have a lot of fun.

    2. Loud Speaker

      You are probably over the age of 40. We all did it that way in the olden days - it was real liberation to not have to use someone else's mainframe. Now, the young whipper-snappers can't do a damned thing, so they "outsource" it.

      Using someone else's environment, used to be known as "got you over a barrel".

      As a developer, I want control over the environment. How is it less effort to specify what you want to someone else, who then has to convert it into choices from a radio-button list, and then hack what wont fit, than install an OS (40 mins or so, if its not windows), and then install the packages you want (with dependencies) another 40 mins, and then update it when YOU want (type relevant command, drink beverage of choice), compared to attempting to explain by email to someone in another time zone that you specifically did not want PHP upgraded to version 7 in the middle of a user evaluation (or whatever). Its probably quicker to install an OS you are used to, than to read the T&C for some cloudy proposition carefully. Definitely less stressful than explaining to a potential client why the system went berserk during the demo.

      You can buy used servers from Ebay for about what you get paid for a day's work. Hell, you can buy a complete Oracle Enterprise scale server for a couple of grand (assuming you can afford the electric bill).

    3. James Cooke

      Been there done that. Now however almost all my workload is hosted on AWS I've ditched the home servers. The skills are still useful though and transfer well to AWS and other cloud services. Be glad that the young ones have no interest in doing the same because setting up large secure cloudformation templates, subnets and VPCs is all extremely valuable in this world. Your skills are probably now much more valuable than before if you can leverage them correctly.

    4. Jonathan 27

      I've got a personal IT infrastructure hosted on AWS (very cheaply I must add), that manages my data, email, a few websites and whatever I feel like testing out. Maybe I'm unusual because I started out doing IT and then moved into development later, what you're saying is certainly true for some developers I work with.

      A lot of them are not very concerned with configurations, and I think part of that might be the way everything can be abstracted with source control, build servers and continuous deployment. I can update any application just by queuing up the right job, only one person in the office needs to know how it works.

  7. thondwe

    Mainframe & SmallTalk

    initial thought #1 - back to a mainframe albeit run "as a service" - write a program to an API and off it goes...

    initial thought #2 - smalltalk - then I g@@gbinged and it seems Smalltalk is already running on Lambda!

    1. mbck

      Re: Mainframe & SmallTalk

      Cloud == Mainframe (with its SNA/BNA/... colleagues)

      Lambda == Software Service bureau minus the big glass windows and rotating tapes on drives.

      Nothing to see. Just new pricing scheme. Otherwise, the "revolutions" of the Internet and of Personal Computing have run their course.

  8. SniperPenguin

    "Serverless" in Layman terms...

    In a Bar, after your initial few drinks the Bartender will always try to move you to "shots" rather than Wine / Beer because:

    - They are more expensive

    - There is more profit in them

    - They are a "cooler" drink

    - You are too drunk to know better (or care about the first two points)

    There you go, I've just explained the pricing models for Serverless computing for you.

  9. Do Not Fold Spindle Mutilate
    Pint

    Thank you Mr. Pott for the informative article.

    Your article explained Lambda in a way that was understandable to me. Someone in a companies management will end up saying "We can't budget for AWS / Lambda because things just get triggered and we don't know why. Just pay the $#$$%! bills."

    Merry Christmas and hope for no "emergency" calls from users.

  10. Frozit
    Facepalm

    Amusing

    Being a developer of too many years to want to count, this just sounds like the latest bandwagon to hell.

    Sure, with the "right people", you can make this work. And those "right people" are the same small selection of people that everybody wants for every one of these bandwagons. Sitting here surrounded by 20+ developers, maybe 3 could make this work. For a while. Maybe.

  11. hellwig

    Lambda functions much be completely composable. No exceptions.

    Sounds time consuming. If these lambda functions are small tasks, why would you want each and every invocation to re-authenticate and re-cache common data?

    I was always under the assumption that getting data was the expensive (from CPU time) part of the equation. It's weird that in a cloud infrastructure, the cost to pull data from anywhere in the world seems NOT to be a concern anymore.

    1. bombastic bob Silver badge
      Unhappy

      Re: Lambda functions much be completely composable. No exceptions.

      worthy of mention, it's "yet another definition" for what "lambda function" does...

      https://en.wikipedia.org/wiki/Anonymous_function

      (note that I really don't like their usage and prefer the 'declared class member function' method in Java, or the use of virtual member functions and/or function pointers in C++ (or C for that matter)).

      But yeah, THIS won't cause CONFUSION in the world of IT.

      [It's almost as bad as calling 'SQL' "Sequel" and having people go 'sequel to WHAT?']

    2. sprograms

      Re: Lambda functions much be completely composable. No exceptions.

      What? No closures?

    3. Long John Brass
      Happy

      Re: Lambda functions much be completely composable. No exceptions.

      Sounds time consuming

      Yes and amazon Et al all charge by the second.

    4. rnturn

      Re: Lambda functions much be completely composable. No exceptions.

      "It's weird that in a cloud infrastructure, the cost to pull data from anywhere in the world seems NOT to be a concern anymore."

      Yeah... remember when "response time" was something that application developers--and their managers--were actually concerned with?

  12. Jonathan 27

    I work for a SaS provider, and my previous employer was.. a SaS provider. Both use cloud servers, and the thing that really bothers me about AWS Lambda is the lock-in. You need to write everything to their API, which leaves you no option to migration to another provider, ever. That's rather terrifying, I don't think I trust Amazon (or Microsoft, or Rackspace, or anyone else) enough to build a product that relies so heavily on a hosting platform.

  13. Missing Semicolon Silver badge
    Happy

    Named-based virtual-hosting

    ... that's been a thing for ages. Take one large box, and resell user accounts.

    On Ye Olden Days, you got shell login, email to your domain directed to your user account, and a ~/htdocs (and possibly a ~/cgi_bin) to put your applications in. No installs needed, you just used what's provided.

    Extend it to J2EE/other server-platform-de-jour (~/webapps ? ) and you've got "serverless deployment" - only without the lock-in.

    First bought mine in 1999.

  14. kryptylomese

    It is a solution (backed by investors) looking for a problem

    AWS is FAR more expensive than private cloud and AWS instances are only 3 nines (so you use more of them and you use Amazon's built in services).

    Company investors (the only people that matter) like the sound of Amazon but it is most often a bad idea unless your business model is huge e.g. netflix

    Sys Ops is dead - long live sys ops!

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