back to article That scary old system with 'do not touch' on it? Your boss very much wants you to touch it. Now what do you do?

Legacy systems have been sitting in server rooms for decades, gradually growing more complex in design, more expensive to operate, less understandable to administrators, and more indispensable to their owners. If some hero tries to poke around inside them, their face turns white when they realize the machines are running all …

  1. Giovani Tapini

    6 point plan?

    The very first thing you are given is a budget.

    The thinking comes later on...

    1. Anonymous Coward
      Anonymous Coward

      Re: 6 point plan?

      ...what's a budget?

      I support legacy systems where the only documentation is pretty much what I've produced, with no internal appetite for refactoring or replacing, but management definitely want to save DC space. Apparently I'll be becoming a magician soon.

      Or just finding a better job.

      Anon.

      1. Pete 2 Silver badge

        Re: 6 point plan?

        > ...what's a budget?

        It's a small bird that lives in a cage. In the past, they were used by coal-miners to warn of impending doom. When the budget stops and you still have work to do (or coal to dig), you know there is going to be trouble.

        1. deadlockvictim Silver badge

          Re: 6 point plan?

          You really are at the codeface there.

        2. Anonymous Coward
          Anonymous Coward

          Re: 6 point plan?

          >> ...what's a budget?

          >It's a small bird that lives in a cage. In the past, they were used by coal-miners to warn of impending >doom. When the budget stops and you still have work to do (or coal to dig), you know there is going to >be trouble.

          This is possibly the single best post, reply or comment I've ever seen in any kind of discussion about IT projects, management, planning, costs, budgets and what could 'possibly' go wrong...

      2. Hans Neeson-Bumpsadese Silver badge

        Re: 6 point plan?

        ...what's a budget?

        The best way to answer that question is to Explain it like this....

        Consider how long it will take you to analyse requirements for the job. Then consider how long it would take to design and implement a solution to meet those requirements. You should also think about how long it would take to design and develop a test plan to verify that the solution worked as expected. Now think about how long it would take to execute the solution and run all your test cases.

        Each resource - designers, developers, testers, etc. will each have a daily (or hourly) cost associated with them. Do some maths to work out how much it'll cost you for the resources to spend however much time you estimated. Then factor in a modest percentage uplift to cover risk mitigation, etc.

        Finally, think about the physical resources you will need to support your efforts - things like hardware, software, tools and the like - and work out how much it will cost to procure those.

        Add all of those together and you come up with a number....

        ...then knock a couple of zeroes off the end, and that will be the budget that you're given.

    2. Anonymous Coward
      Anonymous Coward

      Re: 6 point plan?

      Indeed. In my experience most of these old systems are still in place because there has never been budget to replace them.... Anon because I'm working in such a place now!

      1. Doctor Syntax Silver badge

        Re: 6 point plan?

        "In my experience most of these old systems are still in place because there has never been budget to replace them"

        And because they're what the business uses to earn its money.

        1. Mage Silver badge
          Devil

          Re: 6 point plan?

          Also outsourcing to a 3rd party modern equivalent of the old Timesharing services is a backward step. Is this an article selling AWS (=outsourcing to a 3rd party).

          People will regret outsourcing. Maybe not the Vulture Capitalists, but the customers and employees.

      2. jcitron

        Re: 6 point plan?

        That's what I ran into at a former company. Their legacy business system, not quite as old as some in the article but pretty old nonetheless, was in dire need of replacement in the late 2000s.

        The company never budgeted anything IT-related and had even let the support contract go on the software, let alone hardware. The system was kept running with tape, wire, and squirrels running in cages. I left before replacing anything and the last I heard they're still running this ca. 1998 HP Proliant 5000r server and scrounging on E-bay for hard disks.

        Oh well. That's their problem now and not mine. ;-)

    3. phuzz Silver badge
      Pirate

      Re: 6 point plan?

      It can help you get a migration budget if your legacy system starts to become less reliable. If it starts falling over every few weeks, (and only coming back up due to your heroic troubleshooting obviously), then you'll get some more leverage with manglement to ask for more money.

      Of course, I'm not suggesting you make it crash yourself, oh no! And I'm definitely no suggesting that occasionally 'bumping' the power supply, or 'snagging' the network cable would be the way to do it.

      Because a real BOFH doesn't need my suggestions ;)

    4. Tom 7 Silver badge

      Re: 6 point plan?

      A six point plan is one point short of being able to do anything about the problem at hand. I've found that point 7) Before you start get promoted to a level where you are actually allowed to actually see all the data you will be transferring.

      Nothing harder than trying to verify shifting data and associated semantics when you cannot verify that certain activities* are outside your purview.

      *when I say activities this includes fiddles that people quite high up never expected to be uncovered so an addendum to point 7 would be "I dont want the whole place to close down and all my friends to lose their jobs when most of the board are locked up so a decent reference and I'll be on my way if you dont clean up your act because the next one who tries to sort your IT may not be so generous.

  2. Joe W

    Insurers, banks, board of trade, government...

    ... all have "old iron" in the basement. Like: really ancient stuff, COBOL code, lots af assembler code. Lift and shift means that some company will charge you through the nose for an emulator of your old hardware (we are talking about hardware architecture form the 70s....). It also means that:

    - good luck finding the source code

    - that is documented

    - and actually produces the in-production machine code[*]

    Migrating and updating is (in my opinion, and from what I know from people working at such places) a long term project. Hire some intelligent young-ish people, pay them well enough so they do not look for greener pastures, and let them know that this is a project that can see them through retirement (and hope they stay with you!). Unfortunately the full benefits will only be known a decade down the line, which the higher echelons will not like: it has no tangible immediate benefit for the shareholder value, costs (now) only money, so it will decrease their fat bonus payments.

    If you want to speed things up: Be prepared to spend a f'ton of money.

    [*] apparently some developers used to fix the compiled machine code in production - so the source that is marked as the latest version is not what you have running...

    1. Paul Crawford Silver badge

      Re: Insurers, banks, board of trade, government...

      "actually produces the in-production machine code"

      Is a very valid point, and not just from the aspect of someone editing the machine code to fix a minor bug without facing hours of compilation time.

      You also have to deal with the problem that very likely what is archived was not the "last" version of what was compiled since not every project has good code management using CVS/SVN/GIT, etc and built-test cycles that are followed.

      In one rather sad case a programmer I knew died and several months later the company had wiped and re-used he PC. Then around a year later they realised the in-use executables were build using a version that had been on that PC but had not been checked in to the central repository. Had they only bought a new HDD for the machine...

      1. herman Silver badge

        Re: Insurers, banks, board of trade, government...

        "The programmer died..." That sounds like the Microsoft Windows USB Stack, which has 20 year old known bugs that will never be fixed, for that reason.

      2. Anonymous Coward
        Anonymous Coward

        Re: Insurers, banks, board of trade, government...

        "several months later the company had wiped and re-used the PC."

        ... well, that would be down to all these new-fangled "corporate procedures and quality standards" that just get in the way of real work!

      3. Anonymous Coward
        Anonymous Coward

        Re: Insurers, banks, board of trade, government...

        "In one rather sad case a programmer I knew died and several months later the company had wiped and re-used he PC. Then around a year later they realised the in-use executables were build using a version that had been on that PC but had not been checked in to the central repository. Had they only bought a new HDD for the machine..."

        All too common, this, all too common.

        Where I currently work, there's been a project to replace old IBM iSeries, still running part of the business. Given the profiles, here:

        - old beards with still access to the iSeries, never worked for another company, grumpy as fuck, not a word of english

        - manufacturing company

        - maturity in SW developpment = 0

        , I'm dead sure the sources for the running binaries don't exist elsewhere than a laptop ... somewhere. And even so, comments are surely in local, non english language. No way to re-compile anything. Project closed.

        1. mistersaxon

          Re: Insurers, banks, board of trade, government...

          If it's an iSeries there's a decent chance you could restore the lot to the latest version of the OS on new iron and it'll work perfectly. I mean if the company let the entire infrastructure stagnate for more than 20 years then issues will be more likely but otherwise... go for it.

    2. Anonymous Coward
      Anonymous Coward

      Re: Insurers, banks, board of trade, government...

      Interesting you describe COBOL as really ancient, I've heard people describe it as modern here

      1. Philip Hodges

        Re: Insurers, banks, board of trade, government... [COBOL is modernish]

        Some of us are as short in the tooth as COBOL, there's no need to be an insensitive clod.

      2. Michael Wojcik Silver badge

        Re: Insurers, banks, board of trade, government...

        Interesting you describe COBOL as really ancient, I've heard people describe it as modern here

        COBOL is ancient, as programming languages go; it's the third-oldest HLL, after FORTRAN1 and LISP. The language was developed in 1959, and the first working implementation appeared in 1960.

        There are modern COBOL dialects. ISO COBOL added OO support in 2002, following on from various proprietary OO extensions in the '90s. The latest ISO COBOL standard was published in 2014. Proprietary COBOL dialects have lots of the features typical of contemporary programming languages; Micro Focus managed COBOL, for example, supports anonymous methods, implicit typing, .NET extension methods, and so forth.

        In other words, it's both. The same can be said of Fortran and LISP variants (and even, to some extent, BASIC). When old programming languages persist, they do so in part by evolving.

        That said, a great deal of legacy COBOL applications use COBOL84 or older variants. I often see customer code that was originally written in the '70s or even '60s, and never updated.

        1Which is now "Fortran", of course, but since I'm writing about the original I'll keep the original capitalization.

    3. Anonymous Coward
      Anonymous Coward

      Re: Insurers, banks, board of trade, government...

      "- good luck finding the source code

      - that is documented

      - and actually produces the in-production machine code[*]"

      Exactly that. On most insurance/banks/manufacturers, back then, source mgmt was sci-fi concepts. All was in Joe Admin PC/workstation. Provided he did keep track of the latest. Never throw away a Joe Admin workstation, ever.

      The above is very often why lift and shift or emulation are preferred: you don't need to find out the source code that produced the production binary, if it even still exists !

      You run the black box on new or existing gear. VMware has long made a lot of money due to NT4.0 on ESX ...

    4. Doctor Syntax Silver badge

      Re: Insurers, banks, board of trade, government...

      "Unfortunately the full benefits will only be known a decade down the line, which the higher echelons will not like: it has no tangible immediate benefit for the shareholder value, costs (now) only money, so it will decrease their fat bonus payments."

      However, apply this to the TSB fiasco. What they thought was that running on the old Lloyds platform was costing them too much money and the dis-benefits of screwing up the migration became instantly well known.

    5. FozzyBear Silver badge

      Re: Insurers, banks, board of trade, government...

      Be prepared to spend a f'ton(*) of money.

      Would that be metric or imperial F'tons ?

      1. Alister Silver badge

        Re: Insurers, banks, board of trade, government...

        Would that be metric or imperial F'tons ?

        Well imperial, obviously, a metric one would be a F'tonne...

  3. Jonathan Richards 1
    Alert

    Time for buzzword bingo, sadly

    “In your greenfield you can introduce a microservice architecture so that the developers and new applications can use the latest technologies, build tools, frameworks, and methodologies to help the business innovate and adapt quickly.”

    ...said the expensive consultant, while the IT bods at the meeting detect a nauseating miasma, and the PHB at the head of the table nods wisely and wonders how small a service has to be, to become a microservice, and whether he has any already.

    Seriously, most businesses with such aged mission-critical legacy hardware and software aren't development shops. By definition they've survived this long well behind the curve, so that appealing to the boss's appetite for 'shiny newest and packed with buzzwords' may be profitable (for the implementation consultants) but runs big risks for the business. Find a solution that halves the distance between you and the bleeding edge, and there's a better chance of reasonable prices, available trained support, and not making your business dependent on some nine-days wonder.

    <img grumpygit.gif>

  4. ForthIsNotDead Silver badge
    Meh

    Cheaper?

    It's probably cheaper to introduce new hardware and software that produces the same *output* as the legacy system for the same input, but is, well, you know... new.

    This simply comes down pragmatic and skilful systems analysis, and careful counselling of the people that use the system day-to-day. Do not allow scope-creep under any circumstances.

    The new system will run side-by-side with the old system until all are sure that it is working properly. For example, when it produces end of month, end of quarter, and end of year accounts that all match the legacy system.

    It can be done. Just don't rush into it, don't through boat-loads of people at it. Start the project small and quietly, and up-staff when you are completely confident of what needs to be done.

    And finally, don't be tempted to throw shit loads of hardware at it. Consider this: If the system you are replacing runs just fine on a dusty old VAX, then it will probably run fine a modern PC. You will not need racks and racks of hardware. I've seen some things over the years are simply inexplicable. LAMP stacks and OOP have a lot to answer for!

    1. Dagg
      Facepalm

      Re: Cheaper?

      Do not allow scope-creep under any circumstances.

      Well that screws an agile approach....

      1. Ken 16 Silver badge
        Trollface

        you mean scope sprint

        If it's not defined, it can't creep.

    2. Michael Wojcik Silver badge

      Re: Cheaper?

      It's probably cheaper to introduce new hardware and software that produces the same *output* as the legacy system for the same input, but is, well, you know... new.

      This is wildly unlikely for the vast majority of non-trivial legacy systems. I suspect you have no idea what those systems do. They often implement hundreds of thousands of specialized, obscure business rules, many of which may not be documented anywhere else.

  5. Anonymous Coward
    Anonymous Coward

    I like the idea of a 'piracy' model for difficult migrations

    The 'piracy model' for IT migrations goes something along the lines of -

    1. What differentiates your business model to stop others from simply copying it?

    2. Where are the highest priority legacy (unsupported) systems containing your unique 'intellectual capital'? i.e. when you break it you lose business

    3. How hard is it to COPY the complete system, code and configuration from that old legacy system perhaps to a new emulated or virtual clone system? (emulators are available for many legacy systems and if it runs on commodity x86 kit then this is almost always the preferred option)

    4. How complex and time consuming do you estimate it may be to REDEVELOP and REPLACE the highest priority business functions from the same system?

    5. Choose wisely from option 3, 4 or NO GO before changing. moving and breaking anything!

    Unless your client is truly a unique leader in their area of business there is a reasonable chance that the competition already have an 'off-the-shelf' solution that may be used an an acceptable replacement for many key business application components. The problem is that if your business runs on nothing but easily replaceable systems and applications, it becomes very easy to clone your business and technical models and your only differentiators left are your people and working practices.

  6. Anonymous Coward
    Anonymous Coward

    One approach is to wait until someone introduces SAP into the organisation and then trap the SAP sales guy by suggesting that his system would not be able to replace legacy systems like the one in question. The legacy system then gets ripped out on the orders of the director who ordered SAP and the SAP implementation folk take all the work and flak that follows.

    1. Grikath Silver badge

      yeah... and you end up being the one having to live with the things SAP cannot do/accomplish, or which they claim can do , but only after [insert serious amount of dosh] for which there is no budget left, because SAP ate it all already.

      And don't forget, you're dealing with actual functionality that is gone, and will not be replaced...ever.

    2. FozzyBear Silver badge
      Alert

      Introduce SAP.

      I thought the gist of the article and commentary is trying to reduce the number of problems not multiple them!

      1. Anonymous Coward
        Anonymous Coward

        You know it makes sense !!!

        "Introduce SAP.

        I thought the gist of the article and commentary is trying to reduce the number of problems not multiple them!"

        You are forgetting that the 'Original Problem' was defined as a one of unknown difficulty and unknown achievability.

        If you 'Introduce SAP' the unknowns go away ........ you KNOW it WILL be Difficult, you KNOW it WILL never be finished to everyones satisfaction and you KNOW it WILL cost more than your Budget (or any Budget extension after that).

        Management do not like unknowns ..... so SAP wins !!! :) ;)

  7. Simon Harris Silver badge

    Front page picture

    Feeling nostalgic for the days when things were big enough to solder without needing a microscope.

    1. TRT Silver badge

      Re: Front page picture

      I've been blaming my failing eyesight on the progress of miniaturisation of components for years.

      1. jobst

        Re: Front page picture

        So your arms are not long enough, then?

  8. Pete 2 Silver badge

    Step 0

    > Before taking a pencil to the back of an envelope or breaking out the Excel and pivot tables, it’s important to understand who is driving the migration and what they want

    I would suggest that the very first step is to work out who will get the blame when it all goes terribly wrong (though I think we can all guess the answer).

    We learned how to migrate all the clockwork-powered computers prior to Y2K. The strategy hasn't changed just because the buzz-words in the sales brochure are different.

    The best tip is to employ outsiders to do the work for you. That way, when someone does go pointing fingers, it will be in the direction of people who no longer there (and therefore cannot deny their part in the failure: whether true or false). This is the major benefit of contracting-out work - the indemnity value.

    1. DCFusor Silver badge
      Happy

      Re: Step 0

      My kind of cynic, however, I laughed as I've had it go the other way.

      A company with similar issues hired my tiny outfit to do a similar set of things for what I suspect were a similar set of reasons.

      Long story short - we crushed it utterly, which resulted in long term follow on business, the firing of some of the employees who'd made it so hard for that customer in the first place, and we got to work in our own working conditions - no commute to the customer, at more than double the pay of the people we replaced, for a few years, doing everything else engineering that outfit needed.

      Wound up saving them money - and time - even though we cost a lot more per person, because we were, you know, actually good at this stuff, not sinecure hangers-on. Fond memories, those.

  9. Ken 16 Silver badge
    Holmes

    Retain, retire, rehost, replatform, refactor, and rearchitect

    Were all treatment strategies within Application Portfolio Assessment workflow long before AWS launched on the world.

  10. dajames Silver badge

    ... “six Rs” that ... remains (sic) useful when considering migrations. What are those Rs? Retain, retire, rehost, replatform, refactor, and rearchitect.

    What happened to Retest, or for that matter Redocument, and Retrain (assuming those things were ever done in the first place)?

    1. TRT Silver badge

      Put it all together...

      and it sounds like trying to start a Morris Minor on a cold and foggy morning.

      Rrr, rrr, rrr, rrr, rrr, rr..r....r......r........r...........rrr. Pft.

      1. Voyna i Mor Silver badge

        Re: Put it all together...

        "and it sounds like trying to start a Morris Minor on a cold and foggy morning."

        Excuse me.

        I used to look after my mother's Minor and it started without problems even in the depths of winter. You just needed to know how to adjust the SU, treat the distributor cap with WD-40 periodically and put in better cables to the plugs.

        I think you mean the Austin Allegro, widely referred to as the Agro.

        1. Peter Gathercole Silver badge

          Re: Put it all together...

          Worse than that, it was called the All-agro!

        2. Robert D Bank

          Re: Put it all together...

          from my neck of the woods Allegros were known as landcrabs. They were abominations, only surpassed by the Skoda 110's...shudder!

          1. TRT Silver badge

            Re: Put it all together...

            I think they got bad press... they gave us Hydragas suspension (yay!) and the Quartic wheel (boo!), and they had a reasonable 1.7L engine.

            I mean, it couldn't have been that bad... they went on for three whole series.

            Mind you... so did Derek.

            Yeah... scratch that idea.

            Awful car.

  11. potatohead

    'Migrate it to a cloud based micro-service based architecture'... right

    The thing about legacy systems is that they weren't originally legacy, they were the latest greatest architectural decisions running on cool cutting edge hardware. Now they just look like some weird mess of scripts and code running on an OS that none really understands, but they didn't start that way.

    I've a feeling that the average cloud based micro-service design will not look half as good as that weird legacy you are trying to replace in 5 years time, let along 20 years. Add a dose of vendor lock-in to a cloud supplier, and you'll have management screaming at the next team to replace their new legacy system. 'Ah, this is a cloud v1 system - you need a cloud v2 architecture'. Rinse and repeat.

    1. Ken 16 Silver badge
      Trollface

      versioning

      5 years out you'll just need to test that version 68.4 of micro-service CheeseServer is compatible with versions 80.9 through 94.5 of WidgetDispenser, version 3 of UserLogin (they're afraid to mess with that one much in case it breaks) and v32 of bought in micro-service framework apps. The good news is that there's a AI salesman in the board room selling you a machine learning test suite.

  12. razorfishsl

    What a load of bollox........ chances are those AWS people have NEVER seen an application written with dead software on an out of date box, with programs that auto delete at the end of the run (so they don't double process data), but re-copy and configure from a backup store and rely on the specific ip address of other machines not moving on subnets which was installed & provisioned by fuckwhits dacades ago.

  13. Fading Silver badge
    Terminator

    But what about...

    The scary old system that no-one even knows what it does? It's running- is connected to many things, has dedicated UPS to keep it running and lots of warning signs but has been in the corner of the server room since before your predecessors' predecessor was a PFY?

    How do you migrate the unknown?

    1. Doctor Syntax Silver badge

      Re: But what about...

      "How do you migrate the unknown?"

      You switch it off, hoping you can successfully switch it on again. If nobody complains you can leave it switched off (but don't skip it before the end of the accounting year). If someone does you're now know what it does.

      1. Boothy

        Re: But what about...

        Quote: "You switch it off"

        Yup, done this several times, at both a full system level (i.e. litteral power down of a box), to a specific application running on a shared environment, to specific interfaces running via an integration platform.

        Turn it off, see if anyone shouts.

        If they do, get them to agree to 'own' the service, and to document it, otherwise no turning it back on :-)

      2. Ken 16 Silver badge

        Re: But what about...

        No, you pull the network cables

        1. Excused Boots

          Re: But what about...

          Exactly, that’s what I always do and then listen for any screams over the next couple of days.

          Also if you ‘accidentally’ break the clip on the Ethernet plug then you have plausible deniabilty if things get nasty,

          ‘No I certainly did not disable the CEO’s personal porn storage server, oh look the network cable is damaged it must have been dislodged, could have been like that for ages, never mind i’ll put a new cable in.

          But at least then you’ll know what that box does!

    2. Peter2 Silver badge

      Re: But what about...

      Now see, I don't understand this.

      I simply couldn't tolerate an "unknown" box on my network. You simply have to know. If it's totally unknown, then how can you have a BCM plan to keep it going, and DR plan to recover it? What effect does failure have on the business? Prayer should not be a service management tool for a professional.

      The first thing I do when walking into a new job is go prying into everything in huge detail to find out what lives where and what it's doing and if the documentation matches reality. In this sort of case I just plug my own box into the same switch and stick wireshark on it and figure out what it's communicating with, before then moving to the box and figuring out which processes are doing what and so on. If the conclusion is "nothing" then test that by disabling them and seeing if anything/everything breaks.

      Last time I came across one of these boxes it was a 2k server and actually had fuck all running on it and went within about 24 hours of me encountering it for the first time. My guess is that the signs and warnings dated back to when it was the only DC. It was still the PDC, probably for no other reason than the signs promising death and dismemberment should anybody interfere with it had successfully scared my predecessors off of touching it.

    3. Anonymous Coward
      Anonymous Coward

      Re: But what about...

      "How do you migrate the unknown?"

      By getting to know it. Cyberxenoarcheology is a key part of being a "computer guy" (post-DevOps).

      Look at its network traffic, ports and processes. Look at the source code (if any). Look for clues in long forgotten subdirectorys of the company's oldest file servers. Search archived mail threads and listen to the folklore songs by the water cooler.

      Rediscovering the workings of ancient code mechanisms can be arduous but it can be done.

  14. cirby

    Even the simple things

    Once, I had a consulting call - a friend of mine sold Macs, and one of his customers had decided their print server needed to be replaced.

    I took the new machine to their office, looked around, and asked where the old print server was.

    "What print server?"

    I went onto the office net, found there definitely _was_ one, and started a physical search. Found the offending beast in a closet that was hidden behind a tall cubicle partition. Moved the wall out of the way, went into the room, and found an original Mac II, monitor turned off, covered in dust, attached to an ancient lead-acid UPS. Turned the monitor on and checked the uptime.

    Twelve years.

    It had been a running, non-rebooted print server for twelve years. I felt bad for replacing the poor old thing. Luckily, it was running bone-stock software, so that side of the process was easy enough, but it took three days to train them all on how to use the new process.

    1. Pete 2 Silver badge

      Re: Even the simple things

      > It had been a running, non-rebooted print server for twelve years.

      The BOFH solution would be to clean it up, blow the dust off. Put it back where it was.

      Then tell the company you had "installed" their new print server.

      For extra points, sell them a 12 year maintenance contract.

      1. nichomach

        Re: Even the simple things

        And a bit of hood cleaner, maybe a stick-on logo, just to keep it convincing...

  15. werdsmith Silver badge

    I worked at a place where there was a super high-availability, shared-nothing, geo-dispersed cluster that was put up before these things were easy. It was made up with 3rd party utilities and DIY hacks. The people that set it up had long since left and nobody could support it, the complicated allsorts lashup caused more downtime than it solved and every one was scared of it.

    But it cost unmentionable thousands so management wouldn't let us replace it with a modern cluster.

    Until it broke in a way that a reboot wouldn't fix.

    1. Ken 16 Silver badge
      Facepalm

      get me started

      on people who run Oracle RAC or MS Cluster Server on top of VMWare - one cluster good, two (or more) clusters are not better when you're trying to get something back up quickly

  16. iron Silver badge

    “In your greenfield you can introduce a microservice architecture so that the developers and new applications can use the latest technologies, build tools, frameworks, and methodologies to help the business innovate and adapt quickly.”

    Nice marketing speak garbage quote. WTF does this shit even mean?

    1. kyndair

      easy translation

      it means £2200 a day plus costs per person assigned

    2. Excused Boots

      It doesn’t mean anything.

      I think that’s the whole point....

    3. Michael Wojcik Silver badge

      Nice marketing speak garbage quote. WTF does this shit even mean?

      I won't defend it, but I don't think it's meaningless. Here's a gloss:

      • Have two environments: the new one with all the toys your current developers expect, and your legacy one.
      • In the new environment, your cheap off-the-shelf developers can use whatever flavor-of-the-day crap they like.
      • Use the new environment to create that fancy website or whatever else the C-suite wants.
      • Expose the new stuff as services so the legacy code that does the real work can talk to it.

      He said "microservices", not "services", but that's just because microservices are the flavor of the week. The supposed advantages of microservices (real or not) are irrelevant here; it's just buzzword inflation.

      And, in practice, this approach often works just fine. You keep the legacy stuff where it is, and put a fresh coat of paint on it with whatever toys your fresh-from-school developers know how to use. The business logic stays unmolested and there's some eye candy to throw at management and customers.

  17. Jason Bloomberg Silver badge
    Coat

    A pensioners guide to sucking eggs

    The best course is probably to put it in the hands of someone who doesn't need a 101, has been there, done that, wears the T-shirt, and doesn't just say "move it to the cloud".

    And, when the DevOps team say they'll have it up and running by tomorrow; don't forget to ask them when it will actually be working as required.

  18. cavac
    Facepalm

    Microservices...

    ...yeah, the buzzword of the day. How does this make a business solution less complex? The maintenance IT guy in a decade will just complain about the myriad of undocumented data connections between hundred or even thousands of programms.

    And how all those hundreds of programs need to be rewritten to into a single modern application, because the communication network complexity is unmaintainable, undocumented and so complex that you need fifty times more processing power to run the communication between the microservices than to run the actual business code.

    History tends to repeat itself.

  19. ivan5

    The things that have to be considered when 'upgrading' those legacy systems are, what language were the programs written in - who programs directly in assembler today and how does the system interface with the real world - in industrial systems that can be through custom interface cards that are no longer made but the machine tools have a life of 25 to 50 years more.

    When you mention such things to management and the bean counters they go all quiet for some strange reason.

    1. Wayland Bronze badge

      Yeah, trying to buy the most modern ISA slot motherboards.

  20. Doctor Syntax Silver badge

    “In your greenfield you can introduce a microservice architecture so that the developers and new applications can use the latest technologies, build tools, frameworks, and methodologies to help the business innovate and adapt quickly.”

    More likely they'll develop a minimal set of apps which do what marketing wanted but don't deal with everything marketing didn't think about such as invoicing end user customers when you've always dealt with distributors before or handling returns.

    1. Alistair Silver badge
      Windows

      “In your greenfield you can introduce a microservice architecture so that the developers and new applications can use the latest technologies, build tools, frameworks, and methodologies to help the business innovate and adapt quickly.”

      The only greenfield this has direct relevance to is the green field(s) that are now legal here in Canada. Someone done been smokin a bit too much.

      I'm the body that knows the 20 year old legacy system. I'm movin on.

  21. ocratato

    The Spaghetti Has Escaped

    “In your greenfield you can introduce a microservice architecture so that the developers and new applications can use the latest technologies, build tools, frameworks, and methodologies to help the business innovate and adapt quickly.”

    Once upon a time we programmed computers using a tangle of patch cords.

    Then we had a tangle of JMP statements in assembler, and GOTO statements in early programming languages.

    Then we had a tangle of functions accessing common data.

    Then we had a tangle of interacting objects in OO programming.

    Now we have a tangle of processes on the network.

    I think I am seeing a pattern here.

    1. Voyna i Mor Silver badge

      Re: The Spaghetti Has Escaped

      If you have a tangle of interacting objects, someone needs to be fired.

    2. Conall O

      Re: The Spaghetti Has Escaped

      don't worry, there's even a certain blockchain that refers to itself as "the tangle".

    3. Anonymous Coward
      Anonymous Coward

      Re: The Spaghetti Has Escaped

      Document it and you'll make a fortune

  22. mistersaxon

    Put the blame in the right place

    So... 'Then, there’s the networking issue. “Your legacy machine was probably built in the days of token ring. It has isolated switches. You have 10,000 clients with hard-coded addresses to it and you want to move it to a new environment where you have IP mobility,” Trundle said. “Lift and shift explodes quickly.”'

    Sounds like the desktop and networking team fouled this up, not really fair to blame the legacy system for that is it?

  23. Wayland Bronze badge

    Mirroring is looking backwards

    If you're going to build a new system don't expect it to produce the same results as the old one. What would be the point?

    The new system should be built in stages but those stages must be significant enough to actually do something that's an improvement. If the stage is too small it will fail. It has to be big enough to stand on it's own but small enough that it can be managed.

    Let's say you are migrating to Linux, you would first migrate to cross platform programs. Then the move to Linux is just a change of OS.

  24. OzBob

    Cost of replacement vs hassle of IT personnel

    Having worked in govt IT, if the cost of running legacy hardware is only the time of a permanent (and therefore zero additional cost to the business) employee, with occasional 24 hour work-a-thons to recover after a crash, then the business will definitely not replace, re-org etc.

    What I try and design into my systems is the migration path for the eventual end-of-life cutover. So sticking to flat files or low levels comms for interfaces, splitting app stacks into distinct components that can be hived off individually, etc. I am never around to get the thanks for this from the users (and I never tell the management in case they try to "help" and f**k it up) but I like to think someone notices and appreciates it.

  25. pɹɐʍoɔ snoɯʎuouɐ

    "Migration comes in a range of flavors:"

    I say they come in two.... cheap and expensive...

    cheap is how the people who are paying for it, but dont directly use it want it doing.

    Expensive is how the people who use the systems and maintain them want it doing, as in the right way.

  26. AndrewDu

    Anecdote

    In the basement of a large factory I used to work in, I once came across an old Compaq Deskpro 386 (yes!) running with no case on, and no monitor, attached to various serial cables and such. I asked the person showing me round what it was for and whether it mattered, and how long it had been sitting there hoovering up the considerable dust in the (very dirty) operational area where it was.

    DON'T TOUCH THAT, IT RUNS THE WHOLE FERMENTATION PLANT was the answer.

    Later, I found that this was no more and no less than the truth.

  27. Anonymous Coward
    Anonymous Coward

    Ahh memories

    Spent a lot of time as a contractor before turning perm and found almost every large company has one of these somewhere, like the large bank who's entire server room was controlled by an ageing IBM PC running a compiled C program with naturally no source (found during a Y2k audit! c1998).

    I later went on to specialise for a time in secure file transfer of information from banks to companies treasury systems...my god what a can of worms that was!, dial up modems the banks were desperately trying to pension off (this was about 8 years ago) feeding data into systems where the end points and business requirements had changed substantially over the years, spent many a happy hour with bemused finance directors saying "ok so this data her is going to X" their shocked reaction "My god is that thing still going?, thought we got rid of it years ago, totally superfluous", ended up doing half project management/ business analysis and half coding!

    On the subject of documentation having spent some time as a build manager too, suggesting programmers produce proper documentation and properly commented code is often met with the same reaction as if you had suggested torturing baby animals.

  28. Anonymous Coward
    Anonymous Coward

    The problems I have are :

    Are we doing this because we have to or are we doing it because we have decided we have to?

    What will it cost us to do nothing compared to the redevelopment costs?

    What is our return on investment?

    What is the projected lifespan of the redeveloped system?

    Suppose the system we are replacing has done a job for 20 years? Are we saying that in 20 years time our replacement will be in the same place or are we going to commit to shorter lifecycles and spend more money and more time getting new systems to work?

    The American ICBM control system springs to mind https://www.theguardian.com/technology/2016/may/26/us-nuclear-arsenal-controlled-by-1970s-computers-8in-floppy-disks

    On the face of it all the shock-horror reactions are justified - until you wonder how much it would have cost to rewrite it every decade and how many new system bugs could have accidentally launched the missiles.

  29. Paul Hovnanian Silver badge

    "Growing more complex in design"?

    That implies someone is fiddling with them. And contrary to the stated position of the IT group responsible for them, someone still has the documentation/knowledge to make these changes. It might not be in the official company library, but a dog-eared notebook stashed somewhere. Or it's just been passed around as oral tradition. When the analysts responsible for systems migration show up "nobody really knows" how the old beast works. But when new regulatory requirements or functions need to be added to the old code base, magically the support staff seem to know how to get it done.

    1. Anonymous Coward
      Anonymous Coward

      Re: "Growing more complex in design"?

      "magically the support staff seem to know how to get it done."

      Not true in large corporates, been to places where I've had to use password crackers (with management permission) to retrieve adminstrator passwords because everyone involved had either left or been let go and had left no records.

      Had to go Sherlock Holmes on Unix systems on 2 sides of the Atlantic where there was no remaining documentation, all staff involved had left, the various support departments in the company were arguing over who was responsible for the systems which had dropped off of support, and were running an old unsupported version of UNIX no longer used by the company (same for the software, compiled Fortran anyone?), but coincidentally were vital to a particular product undergoing certification which needed verification on the "original system" that scientists statistics were correct, threatening 10 years of work and the product itself (potentially costing millions).

      In global companies weird things can happen, systems get forgotten, major staff restructuring and layoffs can leave "orphan systems" which you only learn about when your harassed manager/team leader rushes up to you asking you to drop everything, and you can have whatever resources you need to rescue it.

  30. karlkarl

    But what emulators are acceptable?

    You cannot just use Virtualizers like VMware, VirtualBox because they do not provide any actual support for older operating systems like Windows NT 4.0 or Windows 95. They can be hacked to run but that is not ideal for mission critical work.

    You then cannot use Qemu and full system emulators because again... their focus is generally on Linux these days.

    Emulators for non-x86 systems are also often very hobbiest or immature so that's poor for old SPARC servers

    So emulation is actually not an ideal solution to this problem.

    Anyone have any suggestions? My PhD is on this topic and I am currently in the process of the literature review ;)

    1. Anonymous Coward
      Anonymous Coward

      Re: But what emulators are acceptable?

      In my experience with older operating systems it's more finding device driver support for the guest operating system more than anything else, but I have VM's running Windows NT4 and XP on VMWare ESX 5.5 and I've got an OS/2 v2 VM running on Virtualbox, with some O/S's you have enthusiast communities writing device drivers if you are lucky and if the technical data is available, and the only other alternative is to try best guess on the drivers that shipped with the O/S.

  31. Richard Pennington 1

    Years ago ...

    Back in the late 1980s, I used to work in Cambridge for a company which no longer exists. We had acquired - I for get how or why - an old UNIX box which took up most of a room and could only be housed on the ground floor because of the limitations on floor loading. We then had word from Head Office in Shepton Mallet that they wanted it moved there; again, I don't know why.

    I did suggest dropping it off in Salisbury Plain in case anybody there needed a new henge.

    1. The Oncoming Scorn
      Pint

      Re: Years ago ...

      I was going to say Sinclair, but then it occurred to me they didn't have a branch in Shepton Mallet.

      Babycham perchance?

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

Biting the hand that feeds IT © 1998–2019