четверг, 21 ноября 2013 г.

The Most Useless Microsoft Initiative EVER

The following message appeared in Windows Azure OS Updates RSS on November 13, 2013:

We are responding to customer feedback and now adding information to this page on the next upcoming Guest OS release. We hear that you want to know when your roles will reboot. Guest OS releases can move around by days or even a week. The announcements will give projected and approximate dates for the upcoming releases. Updates to the Guest OS Matrix are in process, but not completed yet.

What? Microsoft suddenly cares about Azure Cloud Services users?

Surely not. Not a chance. Here's why.

Those users who have guest OS automatic updates switched on (that's the default osVersion="*" in the service configuration) will be updated withing a rather long timeframe - typically several days - and this will happen before that new guest OS version can be explicitly selected in the Management Portal.

So those announcements will basically mean: oh, dudes, we gonna roll out something which you can't try yourself yet and your service can break in an unexpected way withing the following several days. WTF should the user do? Should he pray or should he pray harder? Should he go to his psychoanalyst and talk about the problem?

WHAT ON EARTH SHOULD USERS DO WHEN THEY SEE THAT NOTICE?

Anyone who cares about their service being broken by a guest OS update (you should too if you claim your service is a Serious Business) have switched guest OS automatic updates off long ago. They manually change the OS version in a testing environment first, ensure that it still works, then do they same in production. These users control their update process and don't care of those announcement just as well.

These announcements are the most useless Microsoft initiative EVER. Just extra noise in the RSS.

And once again - if you have a service hosted as Azure Cloud Service and you want your service to run in stable manner then you should have switched guest OS automatic updates off long ago.

четверг, 26 сентября 2013 г.

How Power Tools Manufacturers Could Get Their Logo Everywhere (Without Looking Dumb)

This day most power tool brands have a wide range of really impressive cordless tools. Most tools have removable batteries. More and more tools get equipped with lithium-ion batteries that have very good energy density and very low self-discharge. What's more important, the battery is the heart of every cordless tool and so all top brands put a lot of effort into equipping their tools with the best batteries possible - with as many charge cycles as possible, with the highest cell capacity, with the best overheating protection so that the battery can output very high power without risk of overheating and exploding.

So you're a cordless tools manufacturer and you've designed a very nice battery pack and you ship several drills, an impact driver, a saber saw, a pneumatic hammer, a flashlight, a disk saw, an oscillating tool, a radio and you can't imagine what else could run of the same battery for your benefits.

Have you ever heard of so-called portable chargers for mobile devices? That's a box with a battery inside that you first charge from mains or from USB and then you can use it to charge or power you cell phone, smartphone or even laptop when far from an outlet. People buy such things from some companies they never heard before.

Since you're a cordless tool manufacturer and you've crafted a very good battery pack for your tools. Why not let people use that battery pack for powering their electronics? All you need is a rather simple converter (yes, it will contain a fair share of electronic components, but this isn't that uncommon these days) that is snapped onto a power tool removable battery pack.

This way you can have your logo just about everywhere and more people know that your cordless tools come with really nice battery packs. Most people only use power tools occasionally or on their workplace or in their backyard but they use electronics everywhere. Letting them use your batteries in everyday life greatly increases exposure to your logo.

Last, but not least, using batteries more frequently will wear them out faster and you'll be able to sell more of them.


вторник, 23 апреля 2013 г.

What Intel Corporation Really Does

You thought Intel only produces processors and hardcore software like compilers and profilers? Think again.

A small ISV recently made a post about moving to their new office with plenty of photos. Among others are this photo of a shaman's tambourine with the repeating inscription "FIX THE BUG" and this photo of a horseshoe amulet with the inscription "A horseshoe nailed to the computer protects code from bugs (the ancient programmers' popular belief)". Both items proudly bear Intel logo on them.

Surely, Intel being a Serious Company™ has to provide a variety of tools for developing and maintaining software. Hence they can't go without shipping debugging aid tools like a shaman's tambourine and bug repelling items like a horseshoe amulet.

Dear Intel, I'm sure you'll be reading this at some point. Could you please not use screws for attaching the horseshoe to the base? In this case screws look as weird as your Atom CPU would look in Ancient Rome. Thank you.

вторник, 26 февраля 2013 г.

In the Aftermath of Unexpected Worldwide Windows Azure Storage SSL Certificate Expiration

Somewhere between Feb 22, 2013 and Feb 23, 2013 Windows Azure Storage service had its SSL certificate unexpectedly expired. Proofs: one and two. A lot of software is configured in such way that once an SSL certificate expires the software no longer trusts the service and refuses to connect to it. That happened to all geographical regions, so no amount of data replication would help (except replicating to some other provider of course).

A fair portion of chaos followed. Microsoft replaced the certificate in several hours and the life goes on.

Now it's time to analyze this situation. Here we have a third party service a lot of other services depend upon and it turns out the service provider let the certificate expire.

Suppose your service uses Windows Azure Storage for storing data and you find yourself in the situation described above. What lessons will you learn from it?

The standard way to handle this situation is the following. It was Microsoft who was responsible for the certificate and so it's Microsoft's fault. Let's get some Jack Daniel's and have a good time.

This approach no longer works. At least not with the cloud services responsibility model.

If you read Windows Azure Storage SLA (highly recommended) you'll see that in no event you're eligible for a refund greater than the sum you paid for the service. This means that if you were affected by that incident you likely can get a refund of several USD, not much more. With that refund you then have to go to your service customers and explain why your service has got affected.

Note that Microsoft is not scamming you – you've been showed that SLA upfront and your lawyers have likely read it.

Now follow any of the two links above and look carefully at that picture with the certificate information. Where's that picture from? When you open any HTTPS-enabled site like https://twitter.com your browser shows a visual indication of an encrypted connection. If you click there you can read who owns the site and who issued the certificate and there's a kind of "more info" button that brings you to that certificate information dialog. Using this way you can see that https://twitter.com SSL certificate expires (as of the date of this writing) at May 11, 2014 which is quite far from now.

So it turns out you can look at any HTTPS-enables site SSL certificate at any time and see its expiration date.

Soooo… Unlike any other kind of unexpected event – like a lightning, a storm, an earthquake, an intern spilling coffee onto critical equipment – this time anyone could have seen the disaster was coming. The information was publicly available weeks in advance and noone noticed the upcoming problem.

Soooo… If your service uses a third-party service via SSL you have only two options. Either you monitor that service certificate or you risk that certificate unexpectedly expiring and sending you into chaos.

It doesn't matter that it's Microsoft (or Twitter) certificate. If your service depends on that certificate you have to monitor it. That's how clouds work. If you don't comply with this model all you have is a crowd of upset customers, a ton of upset blog posts and a refund worth no more than several USD.