Windows Azure cloud services and killer asterisk

One of the convenient buns of Windows Azure cloud services (PaaS, the so-called web and worker roles) is the lack of need to install, configure and maintain the operating system. Instead, the developer can focus on developing the service filling, which he then publishes as a special package to the cloud, after which the Windows Azure infrastructure deploys it on virtual machines with an already installed, configured and optimally patched operating system, which can then be updated if necessary. .

You have to pay for everything. If something sounds too good, it is no accident. By default, the Windows Azure infrastructure can update the operating system at any time and it's far from a fact that after updating your service will be able to continue.

Consider in detail how this happens.
')
For starters, you should pay attention to this RSS, which publishes messages about upcoming operating system updates . Dig in and continue.

Everything described below is in the English-language MSDN in the form of this very thoroughly written article , which is constantly updated. In the Russian-language MSDN, a similar article has long been outdated, you should not count on it.

Windows Azure allows you to set two parameters that indicate on which operating system the service should run.

The first parameter is the “family” of the OS, osFamily in the service settings file. Valid values: 1 (Windows 2008), 2 (Windows 2008 R2), 3 (Windows 2012), in the future there will be more options. The default is “family” 1.

The second parameter is the “version” of the OS, osVersion in the settings file, this is a string of the type WA-GUEST-OS-2.15_201305-01, which points to a specific disk image with the OS of the given “family” with the specific set of updates installed and other changes. The default value is "*" (the same asterisk from the name of the post), in which the Windows Azure infrastructure should start the service on the newest "version" of the OS and as the new "versions" of the OS come out, transfer the service to these new "versions".

The transition to the new "version" is as follows. First, all services that have osVersion = "*" (or this setting is missing) are gradually updated, it takes about a week, then the new "version" becomes available for explicit selection.

Blablabla, blablabla, this is how it actually happens.

At some point, Microsoft decides that the default security policies are not secure enough and you need to tighten the nuts. In the RSS , a message appears stating that in the next “version” the nuts will be tightened, and a link to the details with the comment “please look, and check that nothing breaks in you”. Then, after two weeks at 15 o'clock on Friday of your local time, your service with the osVersion = "*" setting is updated and it turns out that nothing works with new security policies. You spend the rest of Friday after urgently fixing the service and thinking that you are lucky that the update did not happen on the weekend.

Just in case, you need to repeat: first, services are updated with osVersion = "*" and only after that the new "version" becomes available for explicit selection. If the service is configured on osVersion = "*", it will be updated (not "can be updated", but "updated") before you can even try a new "version". In fact, with this setting, your service can be updated and has good chances to break at any time, and this setting is set by default.

If you do not want your service EXTREMELY UNEXPECTEDLY broke on the night from Saturday to Sunday, you should stop relying on an asterisk.

Dmitry Mescheryakov,
product department for developers