Google Engineers Say IPv6 Is Easy, Not Expensive 233
alphadogg writes "Google engineers say it was not expensive and required only a small team of developers to enable all of the company's applications to support IPv6, a long-anticipated upgrade to the Internet's main communications protocol. 'We can provide all Google services over IPv6,' said Google network engineer Lorenzo Colitti during a panel discussion held in San Francisco Tuesday at a meeting of the Internet Engineering Task Force (IETF). Colitti said a 'small, core team' spent 18 months enabling IPv6, from the initial network architecture and software engineering work, through a pilot phase, until Google over IPv6 was made publicly available. Google engineers worked on the IPv6 effort as a 20% project — meaning it was in addition to their regular work — from July 2007 until January 2009."
Comment removed (Score:4, Insightful)
easy? (Score:4, Insightful)
I wouldn't call something that take 18 months to do "easy". :-|
Maybe that's why I don't work at google
Re:easy? (Score:5, Insightful)
In a company of 10,000+ employees, it took a 'small team' only 18 months to convert and test what took 11 years to build? I think that's pretty good.
Re:easy? (Score:5, Insightful)
It may be "pretty good", hey it may be great. But if they're saying that it's easy enough for anyone to do, that's jsut not the case. At 20% of 18 months, that's almost 4 months of solid labour. If you told me that my business needed to take 4 months to do something, I'd tell you it had better be revenue-generating.
Not easy, and not the core problem (Score:5, Insightful)
Define 'small team' - 5 people? 200? What's a 'small team' at Google?
The fact that Google makes such a big deal about only hiring the best and brightest and PhDs and such also indicates this isn't 'easy'. If it took a team of people who are regarded to be the best and brightest in their industry, with numerous PhDs on the team (or at least at their disposal on campus) *18 months* to do something (even part time) that still means that this is going to be a bigger issue for most companies.
Consider that the bulk of Google's apps that would need to be 'converted' have been written in the past 3-4 years (docs, maps, earth, etc.), and likely were written by people who put modularity and efficiency much higher than the average developer does (or is allowed to, in many cases) and you'll conclude that average developers who've inherited undocumented legacy code from previous average developers will have a much harder time than expected.
The core problem (as someone else pointed out) is consumer-level adoption - ISPs, routers, etc. It's somewhat chicken and egg, and perhaps having Google announce 100% support for it, this will give other players in the field the encouragement to put more effort in to transitioning over.
Lastly, why didn't Google (of all companies) bake IPv6 in to these main apps when they were first written?
Re:easy? (Score:3, Insightful)
Re:Yep.. (Score:5, Insightful)
With NAT, who cares? (Score:1, Insightful)
Seriously?
I am in no rush to make this argument to my higher ups, as if I don't have enough work lately. NAT works fine for us and we support over 17,000 desktops.
Re:With NAT, who cares? (Score:3, Insightful)
NAT sucks because port forwarding sucks. If you're ever at an organization with enough IP addresses for users, it's like a breath of fresh air.
Most universities are like this. No fucking around with, well, anything. Want someone to download a file? Copy it to a directory, set up FTP on the directory, and give them your IP address. That was easy.
It's like how IP was supposed to work, after all - any Internet-routed IP address can route to any other Internet-routed IP address.
Re:easy? (Score:3, Insightful)
Google is NOT huge, and it is very young.
To get a real corporation on IPv6 will takes years of constant work, and even then you'll still have legacy systems hooked up to analog lines doing whatever it is they do on their data/fax modems.
The reality is there are TONS of legacy systems out there that can NOT be replaced with any currently available "solutions".
Re:easy? (Score:5, Insightful)
Re:With NAT, who cares? (Score:3, Insightful)
There is nothing inherently wrong with port forwarding, it's not that much different then proxying. The problems that pop up are because of applications that are still being written like they are running on one big network where everyone is nice and trusts each other.
Re:easy? (Score:4, Insightful)
That's a big falacy. Google has all of it's stuff in one place, and with the scale and redundancy to maintain it all without taknig things down. I'm a small web company. I have more "products" than google, and more distinct clients than google. For me to upgrade some software, I need to talk to every client that uses it, I need to convince them to buy new hardware or adjust their existing hardware. I need to teach them how. I need to convince them that it's beneficial in the first place. Then I need to change dozens of projects being used by nearly one hundred clients without taking anything down.
Every one of my clients says the same thing: "I'm running a business here. I don't have time to redo things that work.".
So when ipv4 stops working, then I'll be able to convince them. Same goes for me, by the way. I have nothing to gain by switching to a new protocol. The old one works fine.
Re:easy? (Score:5, Insightful)
Re:easy? (Score:1, Insightful)
Time and ease are independent. Walking across the country takes a long time, but isn't hard. Bench-pressing 500 pounds is very hard, but won't take long.
Remember that the average result of a software project at a company that has tens of thousands of employees is "sputters along for a couple years, and then dies".
An IPv6 migration does sound easy to me. Each piece is basically independent. You can stop at any time, and be no worse off than when you started. It's probably highly parallelizable. Since many of your programs are probably open-source, you can get help from a huge pool of outside people.
It sounds like the world's easiest 18-month software project to me.
Re:With NAT, who cares? (Score:3, Insightful)
Yes there is. Port forwarding works provider you have *one* http server and *one* ssh server and *one* smtp server. It works for home networks.. it's a horrible hack even then.
There's a huge difference in the administrative load, because you don't have to start farting around with allocating new ports because the other one is used, or changing the forward twice a week because two different servers need to be available, and they have clients that can't change the destination ports (real world example).
Re:easy? (Score:5, Insightful)
That's BS. They CAN be replaced but people are simply inflexible and corporations in particular get very scared of change when it comes to IS/IT. Software in 2009 can do anything software in 1979 could do, only better. Your analog modems are legacy equipment and they are there to support the PEOPLE who insist upon them - there ARE better solutions than merely kludging legacy support into every possible corporate upgrade. Ditch the old, get better stuff!
For example, a fully functional legacy PC system with analog serial ports etc. could be implemented entirely in software including an analog modem that handles DSP via the host, and the phone line via VoIP, and then virtualized on a server somewhere, and the physical legacy analog crap could be tossed out. But humans (i.e. workers familiar with the legacy system, as well as upper management) will NOT just jump on board to ideas like this without a lot of resistance. That doesn't mean they aren't do-able. The above example is still implementing the legacy solution, but not using legacy hardware. There is probably a much more elegant (albeit completely hypothetical as per this discussion) solution that ignores the legacy equipment, and if the corporation as a whole switched over to the new solution en masse, there would be no need for the legacy system.
The block is ALWAYS people when it comes to implementing technological upgrades within corporations. It's rarely the technology. Technology is easy to replace/toss out and re-implement. People are much harder to organize and manage than technology.
Oh... and is Google not a "real corporation" now? I am surprised by that statement. They are definitely young relative to corporations from the 18th century that may still exist, but they are not new kids on the block in their field. In addition, I would suspect their network and their tech footprint greatly exceeds that of the average "real corporation", and encompasses a lot more than what a company who doesn't specialize in online information indexing / data mining would need.
Re:easy? (Score:3, Insightful)
Less forgiving? I have to call BS on that one.
No one is less forgiving than the general public paying nothing.
I award you one Fail Whale.
Re:easy? (Score:3, Insightful)
Speaking as a geek myself, I would just like to point out that a common mistake we geeks make is factoring out the human factors problem. "If only everyone were reasonable" is not a good grounding assumption.
Another point, which is really more relevant to what you've said, is that it's not always cheaper to upgrade. A legacy app that works well and does not need enhancements may be safer and more secure than a new app that replaces it, despite great effort to make the new app safe and secure. This is not because the new app programming environment isn't as good as the old one - it's because the old app and the old environment have been around for thirty, forty, even fifty years, and the bugs have been ironed out. Tossing that and replacing it with something different is not to be done lightly.
However, my main response to what you've said is that in fact the person you're correcting was wrong for a different reason. That reason is that you don't need to change the legacy systems. Switching to IPv6 doesn't mean you have to update all your mainframes to do IPv6. Leave them with IPv4, and do protocol translation. They will never know the difference.
Re:easy? (Score:4, Insightful)
Once you have a big system, it's YOUR SYSTEM itself that is the biggest "problem" for you. Not whether it's on OSS.
For example, say some years ago someone built a huge complex system that somehow was reliant on MySQL 3.x (because it appeared to be the least bad choice at that time - e.g. postgres95 was too slow, Oracle = $$$$$, etc).
Now the system works, with known bugs and known workarounds, and worse, with lots of stuff that's custom made to deal with the deficiencies and bugs of MySQL 3.
As a result, it is going to cost a lot to migrate the system to a more recent version of MySQL, or some other DB. Development, testing, extra hardware, time, lost productivity.
Analogy: if you only build a small hut on top of FOSS, moving it to something else is a small problem. That changes once you build a big factory on it.
If the company hasn't budgeted for the cost of upgrading, then it's stuck with the old software.
There's plenty of FOSS out there that has a poor record for backward compatibility, and poor support for old versions.
Yes the upgrades might be free, but you can't use them till you figure out what you have to change in your million-lines-of-code system.
Re:easy? (Score:2, Insightful)
I wasn't disputing that there was or was not an incentive, I was disagreeing with your statement that it was a lot of work and/or not possible.
Specifically these statements:
To get a real corporation on IPv6 will takes years of constant work, and even then you'll still have legacy systems hooked up to analog lines doing whatever it is they do on their data/fax modems.
The reality is there are TONS of legacy systems out there that can NOT be replaced with any currently available "solutions".
Clearly, if a company has a motivation to move to IPv6 it will not take years of constant work, as Google has just demonstrated.
Conversely, there are NOT tons of legacy systems that can NOT be replaced. They are just being left alone because the owners of them have no reason to upgrade them. "can not" is not the same as "will not".
That's all.
There will be no business incentive for the average corporation until IPv4 runs out of addressing space, and those who have already switched at that point will be laughing and taking the weekend off while other businesses scramble to regain basic connectivity. For some (i.e. Google), that is enough incentive right there, as their sites need to be universally connectable for their business model to work.