The Cloud Is Someone Else’s Computer. But the Plan Belongs to You.
Someone else can manage the infrastructure. Decisions about service, cost, and who does what still land on your desk.
Personally, I like technology that takes work off people’s hands. I also want to know exactly which work has been taken off whose hands. “It’s in the cloud” isn’t quite enough detail to run an organization on.
Imagine telling your team that an important service is now “in the cloud.”
It sounds reassuring. The equipment is someone else’s problem. The subscriptions are working. Someone has probably updated a slide.
Then someone asks: “What happens if we can’t sign in tomorrow morning?”
Ah. That part didn’t make it onto the slide.
A useful shorthand. Heavy on the “short.”
Calling the public cloud “someone else’s computer” helps us picture the physical infrastructure behind our screens. Actual machines. Actual buildings. A disappointing lack of atmospheric magic.
The fuller definition from the National Institute of Standards and Technology (NIST) describes on-demand network access to shared computing resources that can be made available and released quickly. That includes processing power, storage, and applications.
In everyday terms, you can get computing resources when you need them without buying and maintaining all the equipment yourself. That can save time and money, depending on what you use and how you manage it.
For the planning side, think of renting an event venue. Depending on the package, the venue might supply the space, furniture, lighting, and staff. You still decide what the event is for, who attends, and what happens if the lights go out.
The venue can provide the chairs. It cannot decide why you’ve gathered forty people to sit in them.
Know what you’re paying for.
Using a ready-made cloud application is a different arrangement from renting a virtual server and running your own software on it.
For example, customers using Amazon’s EC2 virtual machines manage the operating system and applications they install, while AWS manages the underlying infrastructure. Its shared responsibility guidance explains that the division of work depends on the service.
Three common arrangements come with three remarkably unhelpful acronyms:
Infrastructure as a Service (IaaS): “Give me computing resources I can set up.” You rent resources such as virtual servers, storage, and networking. Your team or technical partner manages the operating system and your applications.
Platform as a Service (PaaS): “Give me a managed place to build and run my application.” The provider handles the underlying servers and operating systems. Your team focuses on the application and its data.
Software as a Service (SaaS): “Give me software I can use.” The provider runs the application. You manage how your organization uses it, including accounts, permissions, and settings.
Moving from IaaS to PaaS to SaaS generally means less underlying technology to manage and also less control over it. Responsibilities for your data and access remain. Microsoft’s overview explains these distinctions.
The useful question is: what does the provider handle, what does our technical partner handle, and what still belongs to us?
Preferably answered before everyone points at everyone else.
Rehearse an ordinary bad morning.
This is where imagination earns its keep: rehearse an ordinary bad morning while everyone is still having a good one.
Picture a fictional community organization using an online booking application. Walk through three situations:
1. The office internet connection stops working.
2. An authorized staff member cannot sign in.
3. A booking is accidentally changed or disappears.
Those are different problems. Don’t assume one support number or recovery feature solves all three.
For each, identify a contact person, an agreed fallback, and what staff should tell the person waiting. Include how any temporary records will be entered or checked once normal service resumes.
Talking points go a long way. “The cloud is having feelings” is unlikely to reassure someone who took time off work to be there.
Staff need practice with everyday tasks and the problems that interrupt them. A working login is a beginning. The goal is helping someone make, change, or confirm a booking.
Ask what “backed up” actually means.
“Everything is backed up” is a useful beginning to an answer. I’d like to turn that sentence into a paragraph.
Ask the provider or technical partner how a specific mistake would be corrected. Then ask for a controlled demonstration using test information.
What can we recover? How far back can we go? How long would recovery take? Who starts it? Which steps belong to us?
Leadership and staff need to decide how long people can reasonably wait and how much missing information the organization could reconstruct. The technical team can then assess whether the recovery options meet those needs.
I would prefer to discover a gap during a demonstration. Ideally, while my coffee is still a beverage rather than a coping strategy.
Give ongoing decisions an owner.
An outside specialist may do much of the technical work. I’d still want a knowledgeable person inside the organization responsible for deciding what’s needed and making sure it happens.
That includes approving access, reviewing whether the service still fits, and knowing who takes over when the usual administrator is hiking the Appalachian Trail.
Good for them. We still need to open on Tuesday.
That person should also ask for regular cost reviews. What are we paying for? What changes in usage could increase the bill? Are support, recovery, and administration included?
Ask before signing or renewing. Compare the features and total costs that matter to your organization. The cheapest subscription can become less charming once you discover everything that costs extra.
Plan the exit before you need it.
Even a service that works well for years can eventually stop fitting.
When choosing a service, ask what information you can export, in which formats, and what would need rebuilding elsewhere. Get a sample export and have someone qualified check whether it can be used in another system.
Being able to download a file is encouraging. Being able to use what’s in it is rather more useful.
For our fictional booking application, does the export preserve the links between customers, bookings, and payments? How long can you retrieve information after cancellation? When is access removed, and what happens to the provider’s remaining copies?
Get the limitations, costs, and timing in writing. Planning an exit is a reasonable thing to do before entrusting a service with information you need.
Write a plan people can find.
Do not bury your service plan in the MISC-WTF folder. Make it easy to find, including when the service it describes is unavailable.
For each important cloud service, record:
Purpose: What people need to accomplish.
Responsibilities: The provider, technical partner, internal decision-maker, and backup contact.
IAccess: Who approves, changes, and removes it.
Interruption:What staff do when they cannot use the service.
Recovery: What can be restored, by whom, how quickly, and how that has been checked.
Cost and Exit:What gets reviewed, when, and how information can be moved if needed.
Build the plan from the actual service agreement. Mark unanswered questions honestly and give someone responsibility for resolving them. “We assume” deserves its own warning label.
Start with one service your organization would struggle to live without. Rehearse a problem, check the answers, and update the plan.
Comments