For the past few years, one of the biggest trends in tech has been the transition to the cloud. Almost every industry is realizing cost savings by embracing cloud computing. After all, it’s fairly hard to compete with Amazon when it comes to economies-of-scale when building data centers. Perhaps more importantly, it allows a company to centrally manage a business process and disseminate that process to any location, no matter how remote, with no risk of human error.
One of the other big trends in tech that has facilitated the move to the cloud is the explosion of broadband connectivity everywhere. If a company wants to offload a business process to the cloud, that company had better have fairly reliable, always-on connectivity to that cloud system. In most cases, that’s not a problem.
Cruise is different. Satellite connectivity on ships may be good most of the time, but a company would hardly want to make a critical business process reliant on it. How then do cruise companies reap the benefits of cloud systems without the necessary infrastructure available to support it?
Sourcetoad has worked with a number of companies in the cruise industry trying to solve this problem in various ways. The solutions we have seen run the gamut. Some have been quite elegant. Others, however, have been as crazy as Drupal installs being compressed and sent over the satellite daily via a cron — a mutex nightmare of epic proportions.
Here are a few of the key lessons we’ve learned:
- Satellite connections are pretty good, and they’re getting better. This means you don’t have to go crazy. The first system Sourcetoad built worried about Internet cutout so much that it had methodologies to resume transfers on files less than a megabyte. This turned out to be overkill. We have never seen a connection bounce up and down so much that something like this was necessary. The biggest thing to plan for is when the connection is down all together, which can and does happen for extended periods of time every so often. It’s definitely a bad idea to build a system that needs connectivity to work at all.
- The business process operationally needs to match the design requirements of the system. A centrally managed system to store iTV entertainment metadata is great, but there has to be someone on the shore who can ensure this information is entered and synced to the proper ships. Deciding what to manage directly onboard a ship compared to on the shore needs to be well thought out. This is one aspect where the engineering is agnostic; it can do whatever is desired without much care one way or the other. The buy-in from all the teams to properly use the system is the hard part to obtain.
- Care should be taken in both deciding what to sync and how often to sync it. This is probably the most important lesson. When the connection is strong, syncing in near-real time is possible, especially for small amounts of critical data. In actuality, most data are not critical. Analytics of who watched what movies or TV shows probably can be a few hours, or even a day, old for decision-makers on the shore. Developing and adhering to a strict QoS system to decide what needs to be sent and when can leave your powder dry to ensure that critical information is available right away, rather than being held up by less important information syncing too often.
Centralized “cloud” management is here to stay. Cruise has an inherent technical disadvantage that cannot be easily overcome. However, with good planning and systems design, reaping the vast majority of the benefits isn’t out of reach.