Add some more redundancy to create seamless updates?

[scottmoyse]

It would be cool if these updates were seamless... The UX of losing service each time an update needs to be applied kind of sucks. Surely you could setup some mirroring? apply the updates on the mirrored version, then flip the switch and sync any data mismatches there after. 

I could understand it being difficult with some major updates, but the majority should happen with no service interruption.... it's one of the things Onshape claim won't happen. Time will tell if that happens in practice.

[carl_bass]

There's much that can be done to make the experience more seamless. The change today had nothing to do with redundancy. We replaced a large chunk of the backend data services which required being down for a substantial amount of time

[scottmoyse]

Thanks for commenting Carl. Sorry if I wasn't clear enough. I understand that today's update wasn't anything to do with redundancy. I'm just requesting that a solution is found to remove the need to take the service down to implement updates (I'm sure there are already plans to make it happen).

There's wasn't an idea of this ilk on here, so thought I would add it. Not to criticise, but to raise the point and possibly open a discussion.

Today's update is worth waiting for, that's certain.

[roambotics_scott]

Carl - this seems like something that could be done with zero downtime. If they're web services, it shoudl just be a matter of bringing up the new stuff, rotating IP addresses, and then bringing down the old stuff.

Other than that you're using AWS, I don't know what you're doing on the backend, but if it's elastic beanstalk, http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html and more or less the same should work (Twitter and Facebook do deploys all the time and there is no perceived downtime).

[carl_bass]

The issue today was all the data needed to be migrated from one system to the other and we didn't want new data created during this time. It has very little to do with our web services architecture. Suffice to say, this should be a very rare occurrence

[roambotics_scott]

Fair enough and understood 

[scottmoyse]

The web service has been cut off a few times in the last 6 months at least. This is the longest by far, and understand given the amount of data involved. But my point is, this isn't a one off. 

[roambotics_scott]

That's definitely true.

I've said this before but I do think it's a mistake to have the cloud in the critical path.

[scottmoyse]

Oh looky here... and they said it wouldn't happen 🙂 

[roambotics_scott]

Funny that looks exactly like the one I got 🙂

My two cents: for a web service that's understandable (if undesirable).. for an app, not so much 🙂

[promm]

We are working towards a goal of zero down time for our users.