Server Side Upgrades | Hacker News Reader

Server Side Upgrades

blog.alexmaccaw.com

67 pointsmaccman30 comments

I disagree with the author. Backwards compatibility is one of the great things about Microsoft's stuff, not a bad thing. In 6+ years at Loopt, an upgrade (to get new shiny features) never meant we had to stop using older code.

SQL 2012 is nearly completely[1] compatible with SQL 2005, and largely compatible with SQL 2000. IIS 7.5 will still run ASP code in VB from the early 2000s, and that code can live alongside ASP.net 1.1-4, or ASP.net MVC 1-3. In many cases, you can even have hybrid ASP/ASP.net/MVC combined applications.

There are often benefits that make revisiting your old code worthwhile, but rarely are you forced to. And we kept getting security updates back-ported the whole time.

  [1] http://technet.microsoft.com/en-us/library/ms143179(v=sql.110).aspx
  [2] http://learn.iis.net/page.aspx/727/classic-asp-applications-on-iis-overview/

The financial people recognize that in most cases the value of an investment degrades over the time. If you pay $1M for new machinery, it will be worth lot less after five years.

In software we should have similar mentality and we should somehow turn this into numbers. If you don't touch your environment, the value keeps on going down - until it reaches zero. In order to keep the value, you need to constantly work on the environment. Patch operating, upgrade libraries, upgrade frameworks.

Each time you do a quick'n'dirty thing, you essentially increase your liabilities. Refactoring equals to decreasing those liabilities. If you would put numbers for these, you could actually create a balance sheet every year for your software.

> Although this backwards incompatible policy causes short term pain for developers on their platform, Apple made this conscious decision because in the long-term it leads to an overall healthier ecosystem.

From all evidence I've seen it's more likely they 1) don't care because people are willing to put up with it and 2) don't have the proper type of process/system/codebase/culture to allow such a move (and would rather spend that effort on something else).

One of Microsoft's top 3 selling points in the enterprise is backwards compatibility... They go as far as implementing run-time patches for 20 year old 3rd party DOS binaries that they don't have the source code to when they get crash reports in and it crosses a certain threshold.

> We only have to look at Microsoft's third-party ecosystem to see the alternative.

A developer that targets Windows breaks compatibility with a previous version of his software, then...? What does that have to do with Windows/Microsoft?

The Apple bit isn't _particularly_ true, anyway; look at Carbon. Ten years and counting of supporting ancient apps.

When you do a server side upgrade you are essentially doing an upgrade on behalf of every person who uses your product and it's sometimes difficult to roll-back. This is a really good reason to treat server side upgrades differently.

Once you are bit by a bad update you will be very shy about doing it again without a good cause. As an example, we updated to Recent Version - 1 of critical server software and had the thing crashing constantly thereafter. So then we upgraded to Recent Version and had a new bug that was introduced that was causing equal troubles. But now we were stuck and had to wait for next version to fix the bug. Made a really good case for not changing what works.

This is just as true for client side upgrades, for example in the App Store. As an app developer you're upgrading every client out there, and it's much harder to revert.

Just as you test on the client side, you should have a staging cycle which tests releases before you deploy them.

The advantage you have as a web or app store developer is that if you make a mistake, you can always correct it by shipping a new version. Just imagine the stress that's on the Windows Update or Chrome update teams. If an update to Windows Update itself or to Chrome update itself turns out to be wrong, millions of users could be stuck with a non-upgradeable piece of software and each user would be forced to fix it manually.

Ok, I had to laugh at 'spend 20% of your time on upgrading and refactoring'. That will never happen, especially in a small company where engineers are focused on innovation above all costs. At the end of the day, we're so busy pushing out new features that our clients couldn't care less what version of Python we're running on our servers.

As a former .NET guy, I have to take issue with the Microsoft devs chiming in about how great the .NET stack is for upgradeability.

Upgrading an ASP.NET web forms app to ASP.NET MVC is painful, and in many cases requires a full scale rewrite due to the high coupling of front and backend code in WebForms apps.

While Microsoft hasn't abandoned Web Forms, it's clearly behind the times in terms of modern web development and Microsoft isn't making much of an effort to bring it up to speed.

Comparing the upgrade of a Rails 2.3 app to 3.0 is a much better story IMO, and a far more realistic upgrade for even the largest apps.

You don't "upgrade" from WebForms to MVC - it is a different tool-set. I don't know a lot about the Ruby web world, but it's probably like going from Rails to Sinatra. WebForms still works for the corporate devs, with an IE-only userbase.

Apropos little: I kind of love where svbtle (the software/blog network this is on) looks to be going.

Looks like it's the platform/network that Dustin Curtis has been using for his own blog (http://dcurt.is) and is finally opening up to other authors, albeit slowly.

There's a link to it in the upper-right corner of dcurt.is that goes here: http://svbtle.com/

Edit: missed where tptacek mentioned the name of it. There's how you find it, though.

I'm so used to this being the engine behind, and so unique to, dcurt.is that it actually threw me a little when it wasn't Dustin Curtis's site. I don't know who is/are the developer(s) but my feeling is that it would sit better with a low number of users. Or maybe not, maybe it'll just be like Octopress if it gets opened up.

If it goes in the direction of a nerdier Deck advertising network, with a common look/feel, that sounds great to me. More people I think should do those.

What's so special about it? What's to stop somebody taking design influence from it? There's not a lot to do to make another platform look similar.

Me too; then I realized it is well suited to being a generic blog template. I'd even go so far as to say that I'm used to the idea now.

Best practice is to keep 100% current on security patches (which are often delivered as backports to older/stable versions, e.g. by Debian).

Anything beyond that, and there are multiple schools of thought. One is to keep upgrading bleeding-edge in near realtime -- this keeps you ahead of a lot of known vulnerabilities, gets you access to features, etc., but imposes a cost in constantly fixing bugs.

Another is to do big batch upgrades periodically -- e.g. always updating to Ubuntu Stable within a month or two of release. This breaks more stuff all at once, and has periods of less current software being in production, but is a reasonable compromise.

Another is to deploy things once, get them working, and then leave them in place (with as few upgrades as possible) for as long as possible, then do what is basically a forklift upgrade as required. It has the lowest ongoing cost for maintenance. For something with extensive safety or security critical code which can only be audited and certified at great expense, this is commonly done -- but leads to nice tasty 0-day exploits working well against the most critical systems. It also leads to losing the organizational knowledge, resources, etc. to upgrade.

This would be a problem a couple of years ago, but I think it isn't anymore. Any startup can lease it's own webserver(s) (be it VPS, cloud or dedicated) for prices that were unimaginable even 5 years ago.

And best of all, most providers that are appealing to startups (Rackspace, Amazon EC2, Linode...) offer some kind of pay-what-you-use plans, so you can keep costs low at the beginning.

Amen. I'm writing a python script that'll install a demo version of our software on a Redhat system, and dealing with an outdated version of python makes things... unpleasant.

Updating server software is not rocket science. There are enough good webhosts out there that are doing a great job of keeping their servers up to date. Mind you, they are not the cheapest.

I also like to mention Parallels and their product Plesk that gets updated automatically without any problems; at least on our server.

I disagree. If it works once, it works. We're running on Rails 2.3, have been for two years, and have no plans to upgrade. I can't imagine any extra feature we'd need from the framework; if so, we build it ourselves. We've hacked Rails up to fit our needs, and I think that's the way it should be.

Replace "Rails 2.3" with "IE 6" or "Windows XP" and you have enterprise software.

Yes, you have the code for Rails and can fix/make changes, but the further you deviate from what other people are fixing bugs in, the less you benefit from using open source.

No. In the case of IE 6 or Windows XP it's been shipped to millions of users and they have to go through the trouble of upgrading themselves. Besides, those are platforms, not frameworks.

If there's a bug or security hole in Rails 2.3, we go in and fix it for our users and ship it immediately.

The point being that you have work to backport the fix, whereas keeping up with current other people fix it for you, and more eyes see it, so the fix is more likely correct.

Forking off your own special version of something is a recipe for eventual pain when keeping up the old version is worse than upgrading.

We thought this was the case as well for some internal apps using an ancient version of Rails. The problems start to arise when you bring in new people to work on improvements to the project after the creators are gone. It is much easier to find someone that knows Rails 3 than to find someone who can dive into Rails 1/2 code. You have to know what the patterns of that "era" were and be aware of bugs and subtle differences that have been ironed out as the project matured.

Imagine trying to find a blog post explaining why your 4 year old version of an image upload gem doesn't work on JRuby. It's no fun :)

> Imagine trying to find a blog post explaining why your 4 year old version of an image upload gem doesn't work on JRuby. It's no fun :)

This really depends if you are running a hobby on a server, or running a business. I update client side apps cause it is exciting and it doesn't matter to me if it breaks. If it does, we cry foul and the developer updates a patch hopefully within a few days or weeks.

On a production environment, this is much different. There's a reason why people say "if it ain't broke, don't try to fix it." A down time of 5 minutes could cost one company thousands while another company millions. If the cash printing machine is down, having a broken image uploader would be the least of their concerns.

Because you really don't care about getting fixes for security vulnerabilities? Or you have your own infosec team that tracks every single fix in Rails3 and backports it?

We only have to look at Microsoft's third-party ecosystem to see the alternative.

??? What does that mean? It seems rather hand-wavy.

Some of his arguments are hand-wavy as well "majority of mature companies in San Francisco..."

Reply on news.ycombinator.com