Slashdot Mirror

← Back to Stories (view on slashdot.org)

What Kind of Data Center Can You Build With $500M?

Posted by samzenpus on from the bejeweled-server-closet dept.

coondoggie writes "So, if the government gave your company $500 million to spend on building a new data center what would you buy and how would you build it? Well, the Social Security Administration is about to find out. As part of the stimulus bill, or the American Recovery and Reinvestment Act of 2009, the SSA got the tidy little sum to replace its National Computer Center. The SSA in fact says it will need closer to $800 million to fund a new IT infrastructure, including the new data center — the physical building, power and cooling infrastructure, IT hardware, and systems applications. (This is addition to a $72 million backup facility currently under construction in Durham, North Carolina)."

9 of 204 comments (clear)

  1. The Unfortunate Reality of Maintaining Legacy by eldavojohn · · Score: 4, Insightful

    I will start with the assumption that this data center must be non-homogeneous. Get an assessment of all the projects that are using the current system you're going to replace (you know, the one with 36 million lines of COBOL code?). Because the number one priority of the customer (other projects) is going to be the lengthy transition from that to current technology. Prepare yourselves for this: Some of the projects aren't going to have any funding to do jackshit. Which means that the awesome spaghetti coded current system that's held together with COBOL duct tape needs to remain intact in some form. Not ideal situation but an uncomfortable truth. I'm thinking you would want to set aside 10% or $50 million or so for this (just throwing out a figure).

    --
    My work here is dung.
    1. Re:The Unfortunate Reality of Maintaining Legacy by jellomizer · · Score: 5, Insightful

      I think more colleges as part of their Computer Science Elective they should be a class on Legacy System Maintenance. Legacy systems are not as bad as everyone makes them out to be. As well for the most part languages such as COBOL and FORTRAN are really not that hard to follow and learn. In many ways they are easier then the newer languages, as they are designed to do particular things and do them well, and not like C,C++,Java,.NET try to be the end all be all language. The old code is usually focused on the business logic while newer code seems to be working more with trying to get the formatting correct, and being well organized and modularized (which is a good thing too). But the old code you get PROCESS_CLAIM.CBL all the code that you need to process the claims are there, so when you fix the code there the problem is fixed. Having done a lot of work in FORTRAN myself I have found that there isn't that much spaghetti going on. Yes there is the GOTO statement but it is usually limited to ERROR cases where if something critical failes it GOTO ErrorNum and displays the error and quits the app.

      For these legacy apps normally when something needs to be changed is because there was a change in the business process not because of a bug.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    2. Re:The Unfortunate Reality of Maintaining Legacy by SatanicPuppy · · Score: 4, Insightful

      As someone who maintains COBOL driven legacy systems, I disagree. Why teach that stuff in college? Those jobs are much more rare than other programming gigs, and they tend to be held by lifers (I inhereted mine when 2 people hit retirement age, and the third decided she didn't want to do it alone). If you DO get one of those jobs, the learning code for the obscure hand-coded systems is going to be vastly higher than the language.

      COBOL isn't that hard to pick up. Maintaining legacy crap code is the same whether it's VB or COBOL or RPG, and the vast vast majority of your headaches will come from environmental quirks (old school databases with fixed width data, packed binary decimal numbers that no one uses anymore, etc).

      The biggest problem with COBOL in the modern world is that its designed in reverse. It treats CPU cycles and RAM like they're the most precious things on earth, so a program will make live changes as it goes along (to conserve RAM and minimize disk IO), and is designed to fail in a dirty state (in the middle of everything, so you can't re-run it) on the chance that it'll preserve cycles. It's a real maintenance headache.

      --
      ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
    3. Re:The Unfortunate Reality of Maintaining Legacy by thePowerOfGrayskull · · Score: 4, Insightful

      Everybody* else knew the language was dead.**

      *everybody: the disturbingly large subset of programmers who are unaware that COBOL and FORTRAN still power the vast majority of the financial and healthcare infrastructures of the world.

      **dead: working quietly in the background without need of constant updates and maintenance

    4. Re:The Unfortunate Reality of Maintaining Legacy by bdenton42 · · Score: 4, Insightful

      There is nothing wrong with a functional 20 year out of date COBOL application. It is a bigger waste of company/governmental resources to rewrite it just because you want to use the language flavor of the month.

      So they should have rewritten it in 'C' 20 years ago, then of course you have to go OO and rewrite it to C++ 15 years ago, then Java was really cool so 10 years ago rewrite again, and now M$ has taken over the world so we better port it to .NET today, but you've just wasted 4 projects to simply get the existing functionality and your company is out of business (or added 0.0001% more to the national debt if you are the government).

      There are very good reasons to port old projects but just doing it because it's 20 years out of date is not one of them.

  2. Mimicking Private Industry? by eldavojohn · · Score: 4, Insightful

    Could you approach Google and ask them to license their ideas on server and data 'pod' technology for your sharded databases? I'm not saying build the whole thing like this but with $500 million, you could probably have a large section to search and sharded databases that mimics Google. I don't think there's anything wrong with following the leader in that department. This probably isn't the best solution for relational databases so I would think another architecture would be in place for your MySQL and Postgres traditional database layouts. And that would be just huge centralized servers running virtualized instances of Linux with MySQL or Postgres.

    --
    My work here is dung.
  3. How about a location first by schwit1 · · Score: 4, Insightful

    Putting the operation in a location that is cost effective would make the taxpayers very happy. The DC area is too expensive. Maybe an old missile facility in Wyoming or the Dakotas.

  4. I don't know... by Cornwallis · · Score: 5, Insightful

    ...but I'll bet you $500 million that: 1) It won't be nearly enough money; 2) It will be obsolete before it is finished; 3) It won't be finished before Social Security runs completely out of money (which will coincide nicely with my scheduled retirement); 4) [Fill in the blank]

  5. Re:Why build one... by timelorde · · Score: 5, Insightful

    Because they're not in my Congressional district?