Yesterday, I received an email from Amazon informing me that “one or more of your Amazon EC2 instances are scheduled to be rebooted for required host maintenance.” I think such “forced” maintenance is a major downside of the public cloud. In a blog post, Amazon indicated that a security issue with Xen is the reason.

In my former job as head of IT at a university institution, I was always reluctant to accept offers from the university’s datacenter to manage some of our services. Even though these services were free for us, I was afraid that handing over crucial components of our IT to an external institution would do more harm than good.

It was not that the admins in the datacenter were incapable. Actually, they were better paid than my staff, and most of them were highly qualified. What worried me was that, whenever problems occurred, I had little control over fixing things. All I could do was call the guys in the datacenter and hope that they would give my concern the required priority. However, frustrated users would hold me responsible for the service outage.

Psychologists know that the worst form of stress is when you are in trouble and you have little or no control over the situation. The result was that, even though it may have been irrational and cost-inefficient, I rarely farmed out an important service. I think many CIOs feel similarly, and this is the main reason that many still avoid. The cloud is growing rapidly, that’s true. However, I think most of the services running in the cloud nowadays are not indispensable for their organizations.

To cut a long story short, the email I received from Amazon reminded about those days when I was very skeptical of running my services on other admins’ hardware. Amazon tells me that they will reboot my servers at a date and time that Amazon determines, whether it suits me or not. Perhaps I could call Amazon’s customer service and ask for a different time; however, the email doesn’t mention this option.

It is not that rebooting a server is a big deal. I do this regularly whenever an update requires it. However, I then make sure that the server starts up properly and, if anything unforeseen happens, I am there to fix things.

The service at stake here is 4sysops. The reboot time Amazon scheduled is outside my normal working hours. Thus, the consequence of this email is that Amazon commands me to get up a few hours earlier on a Sunday to watch 4sysops go offline. What’s even worse is that I don’t know the exact time when the reboot is to occur. The time frame of the “event” is six hours!

Just in case you received a similar email and are wondering when your servers are going to reboot, you can access this information in the AWS management console if you click Events right under the EC2 Dashboard link.

Scheduled AWS EC2 reboot

Scheduled AWS EC2 reboot

I can’t really blame Amazon. If they had to set the date and time with each client individually, they couldn’t operate their cloud efficiently. The cloud gives admins much more flexibility in some areas, but occasionally you notice that you are just a guest, and the ultimate control over your assets lies in the hands of your host.

Of course, maintenance reboots are just one example in which IT departments have to sacrifice some of their control. In particular, SaaS offers suffer from this problem. Whenever a cloud provider decides to update its software, you have to follow whether you like the update or not. Sometimes, you are forced to adapt your own infrastructure, and your organization has to train employees to use the new user interface. This can increase the TCO of a service significantly. In some cases, the update might not offer you a single benefit; even worse, features that were essential for your organization might have been deprecated. Moving the service back to your on-premises IT is usually not an option because the costs and troubles are probably much more painful.

Let me say, to avoid any misunderstanding, that I am still absolutely pro cloud. I think I made this clear on numerous occasions in this blog. However, every new technology has its advantages and disadvantages. And you know the mantra of every anti-stress expert: “Let’s accept with full zeal that we won’t always get the best deal!”

1 Comment
  1. Cupples 7 years ago

    You can just reboot at any time before their hard cutoff date. The date is just for you to know when the absolute maximum time and date is before they do it for you.

Leave a reply

Your email address will not be published.

*

© 4sysops 2006 - 2022

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account