back to article Heavy clouds in IT world make it rain gold for UPS box manufacturers

The growth in cloud computing services is creating a financial windfall for perhaps an unlikely source: backup battery vendors. As the demand for larger and more reliable cloud data centers has grown, hosting companies are increasingly building up their stock of backup power supplies, and as a result, uninterruptible power …

  1. Anonymous Coward
    Anonymous Coward

    So You Think You're a Software Engineer?

    My favourite question for a budding software engineer is, "How much do you know about air conditioning?". The answer is almost always "nothing". Same goes for power supply. Some of them have no knowledge of UPSes either.

    I wonder how many data centres have been put together by people who forgot to give the aircon plant a back up supply too? Or forget to have back up aircon?

    These things are important because the specification for UPS and air con is directly related to the softies' choice of programming language. If they do their software in JavaScript, or Ruby or something like that then you have to start planning on a bigger data centre. If for a given demand load their code ends up being 1.1 times slower than, for example, native code written in C++ then you're getting some significant multipliers in other costs.

    This was the kind of mistake Facebook and Twitter made back in the early days.

    1. Lysenko

      Re: So You Think You're a Software Engineer?

      DCs are put together by "facilities" people who typically think of hardware in terms of how many kW are consumed/BTUs generated. The only contact they have with software is Excel, MS Project, AutoCAD and (if they're really nerdy) CFD air flow modelling. The closest they get to knowing what is going to be deployed in a given rack is whether it is provisioned for servers, networks, SANs or Comms etc.

      They will almost never know what is actually running in a server rack (oddities like SuperDomes aside)

      and they don't need to because they can't take considerations like that into account. VMs can be moved around on a whim and software toolchains aren't much better. What they are concerned with is things like the bend radius of low smoke CAT6, balanced phases on the PDUs, legacy junk with power factors substantially off unity, CRAC capacity, floor loading and aisle containment baffles etc.

      Programmers designing DCs is about as sensible as airline pilots designing planes. That's why it doesn't happen (cue: edge case anecdote from someone where it probably did).

      1. Doctor Syntax Silver badge

        Re: So You Think You're a Software Engineer?

        "Programmers designing DCs is about as sensible as airline pilots designing planes."

        I think you missed the A/Cs point: if the language used determines the efficiency of the program in terms of CPU cycles to deliver a particular function then ultimately it has an effect on the power and hence cooling requirements of the data centre that runs it.

        1. Lysenko

          Re: So You Think You're a Software Engineer?

          That might interest the bean counters because it impacts OpEx but it doesn't concern Facilities people or CapEx. You can't know what the server loading (for example) is going to be over the DC lifetime so you have to allow for the worst case scenario, which will be specified in kW rather than processor metrics.

          Having said that, I also reject the premise in general. Switching languages can optimise specific functions at the application level, but when it comes to the DC level the efficiency of a business function occupying half a dozen 42U cabinets is going to owe a lot more to design architecture than implementation language. You can't assume that JS/Node automatically needs more resources than C++. It might be the Node version is using Angular/Vue/React and offloading most of the load to the client whereas the C++ version is CGI and round tripping to the server for every page redraw. Or the C++ version might be trying to compute aggregates from Mongo and getting stomped by even PHP because the latter is using a proper RDBMS.

          Implementation language is buried amongst so many other interacting variables that you cannot realistically factor it into DC design decisions that you'll be stuck with for at least a decade.

          1. Anonymous Coward
            Anonymous Coward

            Re: So You Think You're a Software Engineer?

            Implementation language is buried amongst so many other interacting variables that you cannot realistically factor it into DC design decisions that you'll be stuck with for at least a decade.

            Quite. Arguably, every machine that consumes rack space should be running at close to 100% CPU utilisation at peak - anything less and it means you've not used virtualisation properly, or you've wasted money buying unnecessary hardware.

            So your choice of application language might affect the number of racks of processors you need, but in theory each rack will use the same amount of power, and that's all the DC designer cares about.

            Choice of programming language also affects other metrics - e.g. the number of customer-affecting bugs, how rapidly fixes and new features can be rolled out. These things have business costs which can be offset against extra power consumption.

      2. Anonymous Coward
        Anonymous Coward

        Re: So You Think You're a Software Engineer?

        Wilbur Wright? Admittedly not an airline.

        Charles Lindbergh?

        Just teasing, you are of course correct that DC design is a highly skilled profession.

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