Anterovium - Fotolia
What IT admins need to know about cloud application patching
When they host apps in a SaaS or PaaS environment, IT teams offload some patching duties to cloud providers. But other responsibilities become even more important.
Patching is an IT practice as old as the data center itself. For many admins and IT operations professionals, this routine task has become as commonplace as a morning cup of coffee. As a result, the process has become almost seamless; it's fairly easy to control with Windows Server Update Services and other tools, and the risk and likelihood of bad patches are minimal.
But as it has for so many IT operations practices, cloud computing has changed the patching and patch management process. Just because an application or platform is hosted in the cloud, it doesn't mean the patching process is a relic of the past. Organizations have significantly less direct involvement -- or even awareness -- but, in cloud operations, there are more players involved that are outside of the enterprise IT team.
Platform as a service (PaaS) and software as a service (SaaS) present different levels of control, and responsibility, for cloud application patching.
Patching in SaaS
SaaS is the most hands-off -- and yet most troublesome -- model for the admin. The vendor handles application maintenance tasks, including patching, and provides the end result to the users. This model is likely a significant contributor to the huge growth of SaaS applications, such as Office 365, cloud-hosted electronic health records and learning management systems (LMSes). These services seem to carry few downsides -- at least until the IT team must address the change in its own environment. With SaaS platforms, patches are vendor-driven rather than customer-driven. This means SaaS application patches to address new features, security concerns or performance are decided and managed by the provider -- not the enterprise.
Depending on how extensive a patch is, this can create application changes that disrupt normal business operations for end users, and present a challenge for IT ops teams. To retrain or ramp up users in the middle of a business day or cycle is nightmarish for the average organization.
But the main issue with cloud application patching, and the ways in which it can change a SaaS product, isn't user readiness -- it's the potential scale of those changes. Radical and simultaneous changes made to a SaaS application's interface, function or APIs can affect all end users -- and prostrate an IT ops team. For example, a change to a key API could disrupt integration between the SaaS app and other business-critical systems; those systems, as a result, would not be able to exchange information properly and might deny authentication. While unintentional, this sort of issue does happen, especially for organizations that store resources in multiple cloud services or platforms, or that use a single sign-on framework across the full breadth of their IT environments.
Typically, cloud providers alert users of upcoming changes, but they don't always occur at an ideal time for the IT organization. SaaS vendors are aware of this and will usually plan to make major updates in lulls or off-hours; for example, many school and college LMS cloud service providers commit patches over the summer months, and Microsoft commits many Office 365 updates overnight or on weekends.
The key to successful cloud application patching is to communicate with both application end users and other IT teams that interface with the SaaS tool. IT admins can develop a bad habit of ignoring the readme files that accompany patch notifications, but cloud adoption makes a review of changes critical: There's no option to back out of changes, because your organization doesn't control them.
Patching in PaaS
With PaaS, IT organizations maintain control of the application, but not the OS or hypervisor stack. This provides the IT team more control; OS and hypervisor patches are significantly less likely to cause application changes or extended outages.
In a PaaS model, sys admins are responsible for application configuration, performance and delivery when patching or upgrading. While this is limited in scope compared to patching that also involves the OS and hypervisor, it doesn't mean IT ops can put their feet up: If app performance suffers post-patching, it's not as easy to blame -- or change -- the OS to compensate. Organizations can increase cloud instance size to improve performance, but that carries a price tag. Never try to address an issue by simply throwing more cloud resources at it.
Software and hardware will always need to be patched -- but the location and level of internal IT responsibility have changed. IT operations admins' workload and patching responsibilities decrease significantly with SaaS and PaaS, but the necessity to research and plan for cloud providers and services has increased. Many cloud vendors have scripts and automation capabilities to facilitate -- and ease -- the patching process. The key is to track all changes and communicate with users about both the patching occurrence and any effects that they will experience.
Editor's note: This article is the second in a three-part series on adjusting IT operations tasks for the cloud. Check out part one on monitoring here and stay tuned for expert advice on security.
