This summer, an interesting story about a cloud consultancy’s in-house systems breaking down due to a local disaster made the rounds: How my company went 100 percent cloud.
In short, one night around 2 a.m., a drunk driver who was fleeing a hit-and-run drove his SUV directly into a building adjacent to the company and severed a gas line. The fire department showed up, cut the power, and broke down the doors of the company to vent the gas. The company’s servers were down for eight hours, and various services were intermittent for at least 12 hours. Had things been worse, they could have lost everything.
As a result of the downtime, the company pushed its in-house systems to a variety of cloud providers, as detailed in this chart:
This chart shows the company’s in-house services and the cloud services that replaced them.
In the short term, moving to this variety of service providers addressed the firm’s need for their internal services to live off-site in a real data center, but I expect in the long term, having such a variety of service providers will cause a number of headaches that could have been avoided if they’d simplified with a provider like Skytap.
One of Skytap’s core use cases is combining the advantages of the cloud with the control that comes from using in-house services. OSI, the company in the article, has spread their data and services out on more than half a dozen services, each with their own Terms of Service, login information, and billing. Someone is going to have to be responsible for paying a handful of different bills. Someone is going to be in charge of managing user accounts on all of those different systems—which will be a nightmare for onboarding, particularly for a company that’s “doubling in size every year and [doesn’t] want to create [its] own internal IT department.” There’s also a need to learn each of the different service providers. In contrast, a company that chose to use Skytap management would operate just as though the services still lived on-site, even though the servers now live in a top-notch data center.
Now, I can’t fault them for using Gmail and Google Docs—our own engineering org uses them very effectively—but every other service on that list could be hosted on a cloud like Skytap. In that world, there would only have to be two bills (Skytap and Google) and two accounts to manage per person (Skytap and Google). In this hypothetical world, the chart would look like this:
This chart shows the company’s in-house services and the cloud services that could replace them.
The advantages of such a setup are myriad:
- Full service backup: Lots of solutions exist for backing up the data on a service, but all of the configs, installed packages, plugins, etc., add up over time and can be a huge pain to restore. With Skytap Scheduler, running services can be saved as templates on a regular basis, and more complex actions can be executed with a cron job using our robust API.
- Control: All services running under one Terms of Service. Templates can be exported for local or other off-site backup. Customers have access to all aspects of their Skytap VMs, so no waiting for service providers to upgrade software, and no hurdles for customization. All services migrated to Skytap can be fully managed by the customer, just as if the services were in house.
- Flexibility: As the company’s needs grow and change, more instances of a service can be added with a few clicks in the Skytap UI. It’s also easy to migrate to larger VMs as internal demand increases.
- Easy transition: In this case, the company was already running VMs so they could likely have imported those VMs into Skytap Cloud. To internal users, the change could be almost invisible; all settings, data, plugins, packages, user accounts, etc., could move seamlessly into Skytap Cloud. Users can keep using familiar systems, no need to learn new ones. All services are managed just as they were when they lived in a server closet.
- Cost: Often, self-hosted services are much cheaper than SaaS versions. For example, at Skytap we manage our own Jira installation because it costs half as much per user as the Atlassian hosted version.
And the list goes on.
Has your team or company ever thought about moving everything to the cloud? What have been the major concerns that prevented the move or won the debate and allowed you to shift in-house systems to the cloud? We’d love to hear from you.
