As you think about this question, it helps to remember that this blog is from Hanu, and we manage the parts of the platform that many companies don’t want to, or can’t, manage themselves. When you balance that with your goals and your budget, you’ll be able to determine just how much patching you need to do.
Just to make sure that we’re all using the same definition of “patching” in server technologies, let’s turn to the Wikipedia, which tells us,
“A patch is a piece of software designed to update a computer program or its supporting data, to fix or improve it. This includes fixing security vulnerabilities and other bugs, and improving the usability or performance. Though meant to fix problems, poorly designed patches can sometimes introduce new problems (see software regressions). In some special cases updates may knowingly break the functionality, for instance, by removing components for which the update provider is no longer licensed or disabling a device. Patch management is the process of using a strategy and plan of what patches should be applied to which systems at a specified time.”
As alluded to in the definition, anyone who has spent any time managing servers, or the people who manage servers, has probably experienced problematic patches that cause more problems than they fix. This is why most IT managers prefer to check out each patch on a test bed before introducing it into their production environment.
Azure provides automated patching services, for example automated patching for SQL Server on Azure Virtual Machines was introduced as recently as January 2015. Customers may or may not want to select manual patching instead in order to avoid any potential problem patches.
Hosts & Guests
Azure provides customers with virtual machines (VMs) that are all running on “host” servers. Each of these virtual machines will run a workload, in most cases a “guest” operating system (OS).
Microsoft patches the host servers and is responsible for their operation.
The virtual machines and their “guest” OS is where you take over, and you stay in charge right up through to the applications running on the guest OS. If you think about it, that’s really no different than when you were running your own physical servers, or VMs on your own on-premise host servers. So there’s really nothing new.
One of the attributes that gets set when you deploy a guest OS is the “osVersion” attribute. This not only indicates the actual operating system in use, but also the Azure version that is currently installed. This attribute can easily be set to allow the newest versions of the guest OS to always be updated for you upon release. But, again, you may want to test to make sure that the new version doesn’t break any of your application software before updating to it. This requires choosing the manual method, in which you manage patches much as you always have, or have a managed service provider like our team at Hanu handle it for you.
Just to wrap up the issue of control, this is where you choose what you want to obtain “as a Service.”
In all cases, a key advantage of a cloud service like Azure is that Microsoft manages all the servers, the storage, the networking, and the virtualization.
Infrastructure as a Service (IaaS) – gives you control starting at the guest operating system level all the way up through the runtime executables, the data, any management middleware, and finally the application.
Platform as a Service (PaaS) – Moves more responsibility off of your shoulders. Here, you only need to manage the applications and the data. Everything else is somebody else’s problem.
Software as a Service (SaaS) – takes all the responsibility away and all you do is use the applications and the data without managing any of it.
The level of “as a Service” you choose has a lot to do with how much patching you’ll be responsible for. As the man says, “Choose wisely.”