back to article Blurred lines: How cloud computing is reshaping the IT workforce

From every angle, developers are the key to the public cloud. Unfortunately, today's developers often aren't up to the challenge and frequently end up being as much of a roadblock as operations administrators. New breeds of technologists are required, bringing new ways of thinking to using the emerging infrastructure superpowers …

  1. Anonymous Coward
    Anonymous Coward

    Non deterministic code? Wtf?

    "most developers were cranking out non-deterministic code "

    ALL code is deterministic, even when pseudo random numbers are used. Its simply a case of understanding the algortihms and the code paths. Just because some code is highly complex doesn't make it non deterministic unless quantum CPUs have quietly snuck in without anyone noticing.

    "Clouds are not traditional infrastructure".

    Err yes, they are. A cloud service is simply a remote server that you exchange data with using a given API. "Cloud" is just a marketing buzzword you dribbling idiot. Remote data & hosting services have been around for decades in various guises. Seems to me you've swallowed the kool aid hook and line.

    "That is to say it can easily be accomplished by sending commands to an API."

    No shit. And how exactly does that differ from RPC? Oh right, there's a funky web page up front.

    1. AMBxx Silver badge
      Boffin

      Re: Non deterministic code? Wtf?

      You sure?

      CurrentTime() looks pretty non-deterministic to me.

      1. Anonymous Coward
        WTF?

        Re: Non deterministic code? Wtf?

        "CurrentTime() looks pretty non-deterministic to me."

        Really? So if you call currentTime(), wait 1 second and call it again the time might or might not have 1 second added on? A ticking clock is about THE most deterministic thing around.

        Anyway, deterministic code isn't about absolute values, its about being able to deduce what the code will do when presented with various values.

        1. AMBxx Silver badge

          Re: Non deterministic code? Wtf?

          You sure? To me non-deterministic mean that given a fixed input, the output will vary. Time qualifies for that.

          1. Anonymous Coward
            Anonymous Coward

            Re: Non deterministic code? Wtf?

            "You sure? To me non-deterministic mean that given a fixed input, the output will vary. Time qualifies for that."

            Um, with time the output varies in a highly deterministic fashion and essentially there is no input other than the previous time and whatever clock tick will be added to it.

            I think you're confusing unknown initial states with a predictable set of outputs based on those states.

        2. Anonymous Coward
          Facepalm

          Re: Non deterministic code? Wtf?

          /quote

          "CurrentTime() looks pretty non-deterministic to me."

          Really? So if you call currentTime(), wait 1 second and call it again the time might or might not have 1 second added on? A ticking clock is about THE most deterministic thing around.

          /quote

          You've never run anything on a Windows machine have you? Or a VM of a Windows machine?

    2. Trevor_Pott Gold badge

      Re: Non deterministic code? Wtf?

      ALL code is deterministic, even when pseudo random numbers are used. Its simply a case of understanding the algortihms and the code paths. Just because some code is highly complex doesn't make it non deterministic unless quantum CPUs have quietly snuck in without anyone noticing.

      "Non-deterministic code" is a bit tongue in cheek. I am referring to the fact that the applications behave in a completely non-deterministic factor as far as systems administrators, end users, or other applications interfacing via API/XML Import/what-have-you are concerned.

      Anywho, you may now continue with your rage-induced spleen venting. Enjoy.

      1. Anonymous Coward
        Anonymous Coward

        Re: Non deterministic code? Wtf?

        "Anywho, you may now continue with your rage-induced spleen venting. Enjoy"

        Please don't criticize Trevor he really can't handle it...it's worse than playing with the trolls...

        Replace the anon icon with the Troll icon.....--------------->>>>>>>>>>>>

        The article is basically blah blah because it represents what we have been doing in IT since day 1, scrambling around desperately trying to keep things together. it's part of the very nature of an evolving technology/business..

        The fact that the word Cloud has been used changes nothing, it's just another piece of lego to play with. .... I can understand that Trevor will spout this kind of thing to his clients though..

        1. Trevor_Pott Gold badge

          Re: Non deterministic code? Wtf?

          ...did you just imply that I am pro-cloud? If so, I'm getting your comment framed.

    3. Destroy All Monsters Silver badge
      Facepalm

      MY GRANDMA TOLD ME ALL THERE IS TO KNOW AND I KNOW IT!!

      ALL code is deterministic, even when pseudo random numbers are used.

      Or maybe you should just stop writing 15-liners that work in Helen Keller mode.

      "Clouds are not traditional infrastructure".

      Err yes, they are.

      Seriously, are you trying to make some kind of point or do you really believe what you write?

    4. Nate Amsden

      Re: Non deterministic code? Wtf?

      (most) public cloud infrastructure to me at least doesn't remotely resemble traditional infrastructure. While we are 99% virtualized our VM life spans are measured in years. We've never had a VM failure(e.g. have to rebuild a VM). If a host fails, VMs are automatically restarted on another host within a minute or so(last time it happened it was so fast our monitoring didn't even get a chance to send alerts that more than a dozen production VMs went down). Naming schemes are sane, IP addressing is static, things are reliable. Storage uptime 100% since moving out of public cloud 3+ years ago. 2 VM host failures(hardware) in 3+ years. I can sleep well at night not having to worry about something failing like we constantly had to worry about when hosted in a big public cloud provider. To answer the question, no in the past 15 years I have never worked with a development team that built things to operate smoothly in a public cloud, including the present and previous companies who launched their applications in public cloud from day 1 (first one crashed & burned, current one of course moved out in short order).

      There are cloud providers that can provide this, but the "big ones" don't come close (and aren't even trying, it's not their model).

      1. Anonymous Coward
        FAIL

        Re: Non deterministic code? Wtf?

        "public cloud infrastructure to me at least doesn't remotely resemble traditional infrastructure. While we are 99% virtualized our VM life spans are measured in years"

        Oh for gods sake, VMs have been used in mainframes since 1972 with VM/370. You honestly think you're doing anything new just because you're running VMs on a PC?

        It really is about time that people who worked in IT learnt a bit of IT history before they imagine that everything they're doing is somehow new and unique.

    5. Anonymous Coward
      Anonymous Coward

      Re: Non deterministic code? Wtf?

      I would argue that any code using an algorithm to solve an NP-hard problem is going to give you a non-deterministic run-time. Perhaps this is what the author is alluding to.

  2. Neil Alexander

    "[...] push code out live with minimal testing and not get vanished in a dark alley for it."

    "What could possibly go wrong?", they asked.

  3. LucreLout
    FAIL

    Poor article, sorry.

    Unfortunately, today's developers often aren't up to the challenge and frequently end up being as much of a roadblock as operations administrators.

    I can only assume Potty works in the public sector, because pretty well every developer I know has been busily developing cloud solutions at home as research projects, due to the roadblock of management refusing to budge from the current way of doing things. The reason management are refusing to budge is simple: The ops admin team keep filling their head with scare stories about what will happen if we use “the cloud”, mostly due to a fear of loss of control and loss of employment. In reality, there’s zero reasons we couldn’t be using it for green field development work, given we never use production or sensitive data in a development environment.

    Features must be added at a frightening pace and there is never enough time to do things right.

    On the contrary, doing things right is what makes the time. A properly designed, written, and tested app should require very little hand holding or maintenance. The hard part is moving from doing things the wrong ways to doing them the right way – that takes time and effort that traditionally comes out of the developers social lives. It shouldn’t, but it does.

    Security is viewed by both developers and operations as being constantly "in the way".

    Security is something a professional developer designs and builds into their code from the ground up, or it never gets done. It’s pretty binary, because poor security is no security. What gets in the way are peoples pet projects masquerading as security, when in reality they add nothing of value to the security situation but do detract heavily from the productivity stream.

    The server security isn't something a dev can or should be responsible for, save for being one side of the productivity:security see-saw. I don't know how to configure a windows server to be optimally secure, but I do know that there are features of Sql Server that I can leverage to significantly enhance productivity, even though that may push the DBA team out of their comfort zone - "What do you mean the assembly needs to be installed in the Sql Server - we don't know C#". I'm sure we can all think of other examples, both where the functionality is being abused, but also where locking things down has gone too far.

    In a cloudy world you can't just jab a finger at operations and fob an angry suit off on the room of weird socially inept people down the hall.

    What a strange view of world this is. On one hand it implies an alarming lack of professionalism from the developers the author has worked with, and on the other seems to denigrate all admins everywhere. Not all my devs or admins are socially inept. Far from it in some cases. Its an old, offensive, and frankly very dated stereotype that has no place in the modern industry.

    The role of developers too is changing. Companies of all sizes depend on them now more than ever, and as cloud adoption - public, private and hybrid - increases, developers will take more direct control of the infrastructure their applications consume. In order to adapt, developers are having to learn to think differently. They have to become DevOps.

    Not really, no. To summon the kind of infrastructure I need as a developer is pretty trivial. It requires none of the detailed knowledge of a competent sysadmin, none of their experience, as there’s not vast amounts of things I need to manage when looking at cloud for development. In reality, my organisation will never host our systems & data on other peoples computers, which is really all the cloud is. We will always require sysadmins who can deliver our requirements professionally – I don’t have to care about the patch state or backups on the server because everything of value is in my code repository, which is maintained by our in house admins.

    How well Potty understands systems administration may be debateable, but he clearly doesn’t understand coding and software development very well at all. I think the vision of the future presented in this article will turn out to be wildly inaccurate, and that in 20 years time you’ll find we still need proper sysadmins, it’s just that the cloud will have made them a lot more pragmatic and responsive rather than the Dr No type who proliferate too often. Nobody should give a crap about the dev servers – they should be replaceable in an instant if the developers are doing things right, but the prod servers and datastores… they will always need careful and talented custodians. And that very much will not be us developers.

  4. vikdhiman

    Good Article

    The evolution to DevOps and SecOps seems to make a lot of sense and already being felt. Although taking it a step further you might not have SecOps if developers are accountable for security as well which they will be eventually. So only DevSecOps, rest all doomed!!

    1. Anonymous Coward
      Anonymous Coward

      Re: Good Article

      Swing and a miss. There are a lot of good reasons the folks who develop and manage applications and the folks who say "we checked things out and it looks mostly secure" shouldn't be the same people. I'm sure you can think of a few.

  5. Phil O'Sophical Silver badge

    Or to put it another way

    We're moving from the "modern" era of individual computers where developers were their own sysadmins, back to the 1960's timesharing model of huge mainframes somewhere else, managed by expert acolytes, and users who sit in front of a terminal somewhere and see the computer as a service, whose location is unknown and largely irrelevant.

    OK, so the "dumb" terminals are smarter than they used to be, and dynamically allocating storage and compute resources on-demand means a bit more than waiting for the operator to load a magtape and a card deck, but it all looks very familiar.

    The cloud has been pushed more by marketing types than technical ones from day one, and at least half the companies offering cloud solutions are only doing so because they don't want to be seen not to. It has a momentum all it's own, at least until the next trend comes along.

    Security is viewed by both developers and operations as being constantly "in the way".

    I have rarely seen this from operations, they tend to see developers as being in the way of security, and with reason. Developers are now, finally, beginning to realize that customers don't care much about performance these days, they can get all they want for next to nothing. Security is foremost in customers' minds now, and the professional developers who get that will be the successful ones.

    And as for In a cloudy world you can't just jab a finger at operations and fob an angry suit off on the room of weird socially inept people down the hall.

    Of course you can. It just won't be your hall. "it's the cloud" will replace "it's the computer" as the universal scapegoat.

  6. Anonymous Coward
    Anonymous Coward

    Here we go again...

    Apart from marketing, how is the cloud different to the network? What's a 'cloud solution' and how does that differ from two or more processes communicating over sockets?

    This all sounds like the BS we got when application servers first arrived: they'll change everything! they'll make all current developers redundant! Remember Sun telling us we'd actually employ EJB writers and they'd be special?

    There's nothing in this article that applies to 'the cloud' - it's all generalisations. And as for today's developers not being up to the challenge: Really? How on earth would you know - you're an administrator.

    1. Trevor_Pott Gold badge

      Re: Here we go again...

      Apart from marketing, how is the cloud different to the network? What's a 'cloud solution' and how does that differ from two or more processes communicating over sockets?

      The difference between a "cloud" solution and a non-cloud solution is that the cloud solution is self-service.

      What is a "cloud" to the users of that solution is a network to the folks who have to stand it up. The lines can get blurry, but the difference is pretty simple to articulate. In a non-cloud network resources are allocated via manual intervention and approval after receiving a change request. In a cloud those seeking to consume network resources can go about consuming those resources without needing to submit change requests and get approval from IT.

      That's the big difference.

      1. launcap Silver badge

        Re: Here we go again...

        >The difference between a "cloud" solution and a non-cloud solution is that the cloud solution is self-service.

        s/is/can be/

        For example - we are migrating our Dev centre out to a cloudy system. The Devs do *not* get the ability to spin up machines at a whim (that costs money). Rather, they continue to take the traditional route of requesting more resources - that then get authorised and provided by an Ops function.

        The main difference is that spinning up new machines takes a hell of a lot less time that then old hardware route.

      2. MissingSecurity

        Re: Here we go again...

        I think cloud pushers (and I'm not really against it) don't really explain the nuances enough. When I was doing primarily Sysadmin work, Cloud was trying to sold to me as basically migrating my virtual environment to the datacenter (which depending on budget vs risk might actually be a better thing). Since I have switched to Development more, the big thing that I noticed is that Cloud is marketed as something you build for (think Websphere, Weblogic, JBoss). I don't want to call it a new software pattern but in a way it seems like it.

        I think to many people think of the cloud as putting up an Apache web server on a virtual box in a third third party datacenter somewhere.

        1. Trevor_Pott Gold badge

          Re: Here we go again...

          "I think to many people think of the cloud as putting up an Apache web server on a virtual box in a third third party datacenter somewhere."

          Well, personally, I wouldn't call that a cloud. I'd call that a hosted solution. But that's just me.

        2. Khaptain Silver badge

          Re: Here we go again...

          "I think to many people think of the cloud as putting up an Apache web server on a virtual box in a third third party datacenter somewhere"

          I think that most people here realize that the cloud is a little bit more complex than that basic definition.

          I would take a vague stab more along the lines of "the global and dynamic abstraction of hardware, software and services".

          At a moments notice, or at least the flick of a switch or two, clickety click from a nasty BOFHS domain HQ and it can all disappear......... ( Ok that's a bit exaggerated but it was intended to add to the idea this there is a very ephemeral notion to the "Cloud")

          1. Trevor_Pott Gold badge

            Re: Here we go again...

            "I think that most people here realize that the cloud is a little bit more complex than that basic definition."

            I have no such illusions about the competence of commenttards. I might once have believed that, but I've recently become quite disillusioned in the basic level of technical understanding of the readership.

  7. jackandhishat

    They're after mah jorbs!

    The article does make some interesting points, but I'm not entirely convinced on the ops & dev convergence. Sure, you can spin up stuff in the cloud for dev, but knowing how to optimise, secure and maintain systems is a whole different kettle of fish be they cloudy or physical. Likewise, knowing how to tune applications to really make them sing is beyond a lot of sysadmins; you can change kernel params or registry settings etc. to help but without real in-depth knowledge you're limited in what you can do.

    The SecOps idea on the other hand makes a lot of sense when you consider scenarios such as Heartbleed: how easy is it to kick off a mass Puppet/Chef/Ansible run to update the affected packages on a load of systems? Very easy if you've done your homework. Some testing is needed before massively deploying and there'll be edge cases but the act of updating the systems can be made far less painful than it needs to be.

    1. Trevor_Pott Gold badge

      Re: They're after mah jorbs!

      "knowing how to tune applications to really make them sing is beyond a lot of sysadmins; you can change kernel params or registry settings etc. to help but without real in-depth knowledge you're limited in what you can do."

      I think you make the point for Dev and Ops convergence quite clearly. The truth of the matter is that there are too many applications for traditional sysadmins to keep track of. You can't just have a generic "ops guy" and expect them to make everything run to plan.

      That said, it's not that hard for a developer to learn about the environment they're developing for. DevOps who understand how the application they're coding interacts with the web server, the database, the kernel, etc will be better at creating efficient solutions than a traditional dev + ops arrangement.

      Already, this is being noticed by companies who have adopted DevOps. IMHO, sheer economics will push devs towards taking on more and more of the ops role, leading to the traditional ops guys to evolve towards SecOps.

      1. jackandhishat

        Re: They're after mah jorbs!

        Ehh... I'm still not entirely convinced. I see the theory at work in your argument, and agree with it, but given the quality of some of the devs I've worked with I'd be terrified at seeing them try to administer systems. (Think of all those horror stories you hear about outsourced coding.. how's THAT going to end up? Question for another article maybe?) Maybe it's more a question of practicality.

        With that said I do also recognise that a lot of devs are shit hot at what they do and that they're likely to become transcendant mind-boggling cyborg codeslingers. This is a Good Thing, as smartypants points out in his comment - good devs, devs who actually understand optimisation and best practices, they're worth their weight in gold and will be even moreso in a world where Cloud(TM) is everywhere.

        1. Trevor_Pott Gold badge

          Re: They're after mah jorbs!

          "but given the quality of some of the devs I've worked with I'd be terrified at seeing them try to administer systems"

          That could be said of any area of human endeavour though. Won't stop the inevitable. It'll just mean there's a whole lot of shitty DevOps out there and a handful of good ones. Plus ca change...

  8. smartypants

    Software Devs: Finally responsible for resource usage again!

    As a software developer, my early career was writing software for fixed platforms (e.g. desktop computers). In this world, a lack of concern for how efficiently your application used the resources would soon punish you, because your software would be shit in some way. This was a Good Thing.

    Then I moved to the world of the web, where far too many companies allowed software devs to make atrocious design decisions which were then just patched up by IT. Database too busy? 'Throw more money at it' seems to be the response. Webservers too busy? Add more! Never question the devs, not even if they'd combined a load of crappy plug-ins into a witches-brew of a system that made atrocious demands on the poor servers, or was not even optimised out-of-the-box. I bet half of them these days couldn't even tell you how a piece of data makes it into their code from a real machine, or what actually happens to execute their code...

    Now finally, with cloud, if the devs are shit, then the consequence is a big fat bill. No IT middle-men to blame.

    I hope once again software development becomes a skill which requires people to consider the impact their software has on the underlying systems at the start. And I hope this causes some of the trendy technology that helps these shit devs remain clueless about the real world to fall by the wayside.

    1. Trevor_Pott Gold badge

      Re: Software Devs: Finally responsible for resource usage again!

      Excellent way to put it. 100% agreement.

  9. Trevor_Pott Gold badge

    Love the responses.

    There's no haterade as delicious as developer haterade.

  10. bill 36

    i have a question

    Can somebody tell me the difference between Cloud and Thin Client?

    It seems to me that Cloud is just a euphemism for the distance between the server and its users.

    Or indeed the backup of the users machine.

    Then it's a question of security...no?

    Genuine question....no flames please.

    1. launcap Silver badge

      Re: i have a question

      > Can somebody tell me the difference between Cloud and Thin Client?

      Primarily - the site of the destination server. I'd be *very* surprised if any thin clients are being delivered by servers not within the organisations LAN/WAN. Also - thin clients generally boot off a local server and you really, really, really wouldn't want tftp being fudged to go over an internet connection.. (TFTP is about as insecure a protocol as possible)

      Thin client == "running a remote desktop in your own environment"

      Cloud == "running stuff remotely[1] but generally not thin clients"

      [1] Generally - you can have on-premise cloud but that's not really cloud..

    2. Trevor_Pott Gold badge

      Re: i have a question

      "Can somebody tell me the difference between Cloud and Thin Client?"

      Two things:

      1) If you are talking about "Software as a Service" consumed through a browser (which is the main part of "cloud computing" that end users typically see) then the big difference is thin client versus browser.

      Thin clients are thin. In the most traditional of thin clients (which we now term "zero clients" today) they have just enough brains to pass KVM back to the super and bring a screen to you. Modern "thin clients" are actually full "fat clients", but heavily locked down. That's a whole other discussion, as this is largely unnecessary, but done because it's easy.

      Browsers are fat. They are basically their own operating systems at this point that run on top of another operating system. Browsers are the most common means to consume "cloud" apps, but not the only one. which leads us to number 2.

      2) Cloud is about self service of IT resources. Those resources can be anything from a place to stick a fat, traditional Win32 application, to Desktop as a Service to a backup destination to a browser-based Software as a Service application.

      The key differentiator between cloud-based and traditional architectures is that "cloud" removes people from the provisioning portion of the exercise. Developers can call resources through APIs. End users or administrators can create resources through a web interface. You don't fill out a request on a piece of paper, submit it to a bureaucracy and wait months.

      Clouds can be internal to an organization (private cloud) consumed from an outsourcer (public cloud) or they can have the ability to use resources in either place (hybrid cloud).

      That last is something that needs to be remembered. "Cloud" does not have to mean "the public cloud". You can build clouds in your own home if you want. Just start layering self-service interfaces on top of your existing network and voila: a private cloud.

      1. bill 36
        Pint

        Re: i have a question

        thanks guys i'm with it now.

  11. Anonymous Coward
    Anonymous Coward

    War stories from Ops land

    I don't think the article makes quite enough of the horrorshow that is coming with the fashion for DevOps. Not that it's wrong to say that's where things are going.

    We're a new-ish financial. We set up fast, and went straight from greenfield to legacy due to the compromises that have been made.

    It's a competitive industry - the business want projects (new products) delivered, and yesterday. No interest in the problems in getting stuff done quickly due to the creaky infrastructure. JFDI.

    New CIO out of the Dev world, so he thinks we're not being Agile enough - Ops are just getting in the way of Delivery with all their fussing about documentation, testing, QA. JFDI.

    So Ops try to compromise. Out goes the baby with the QA bathwater - let's just hope the regulator doesn't catch us. (But you know who gets the blame if they do). JFDI.

    But the political football that is the first project to get the JFDI treatment turns out to be a disaster. Could have done with some QA. What a surprise! Whose fault is that? Ops, who put the POS in.

    So: get rid of Ops. DevOps ftw! That way you never have to write another line of documentation, and don't have to worry about supportability because you'll just fix it on the fly. Plus all those lovely seats in Ops become part of Dev - well, half of them. Because they were obviously hideously over-staffed. (Bear in mind no-one in Dev here has ever run a rota, or been called out in the middle of the night.)

    Only, remember that legacy stuff, that all your customers actually run on? That only Ops had a handle on, because you couldn't find any Devs who wanted to work on ~5yo code? Yeah, well, never mind. The next CIO can outsource that. (We just got done insourcing it because the #BigFive created that instant legacy problem. But again, never mind.)

    Oh dear me. This has turned into a bit of a rant. Excuse me while I click the anonymous button.

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