

Server Side Upgrades - maccman
http://blog.alexmaccaw.com/server-side-upgrades

======
kogir
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/

------
jpalomaki
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.

------
powertower
> 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?

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

------
stevear
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.

~~~
maccman
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.

~~~
jules
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.

------
marquis
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.

------
hkarthik
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.

~~~
balakk
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.

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

~~~
aprescott
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.

~~~
tptacek
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.

------
rdl
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.

------
tzaman
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.

------
pavel_lishin
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.

------
NameNickHN
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.

------
joshuaxls
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.

~~~
swanson
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 :)

~~~
kappaknight
> 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.

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

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

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

