How Cloud Managed File Transfer Optimizes Infrastructure Costs, Performance, and Reliability

Let’s get this out of the way: Migrating traditional managed file transfer (MFT) infrastructure to a cloud-native workflow can be a daunting, sometimes even painful, prospect in the short term.

That’s because legacy systems, like Signiant and Aspera, almost always require a lift-and-shift migration of on-prem workflows to the cloud.

But for organizations looking to modernize their tech stacks, optimize costs, and improve file transfer performance by orders of magnitude, moving to cloud-native workflows is a no-brainer over the long term.

In this post, we’ll explain why shifting to cloud managed file transfer can simplify complex workflows, save costs, improve performance in all regions of the world, and—through the magic of custom development—be less disruptive than you may think. 

• Cloud-Native vs. On-Prem MFT: What’s the Difference?
• Legacy Managed File Transfer: Barriers to Productivity
  • Performance impacts
  • Total cost of ownership (TCO)
  • Fiabilidad
  • Flexibilidad
• Save on Infrastructure and Improve Performance With Cloud Managed File Transfer

Cloud-Native vs. On-Prem MFT: What’s the Difference?

Traditional, on-prem MFT relies on local servers and has been around for decades. While on-prem MFT can achieve impressive transfer speeds, it requires expensive infrastructure purchases and upgrades, complicated software and plugin installations/configurations, and is typically a heavy IT lift to maintain and keep secure.

Unfortunately, traditional MFT deployments that want to leverage the power of cloud often require a lift-and-shift migration that brings a ton of additional costs and inefficiencies.

• This includes the migration of traditional workflows to bare metal servers hosting virtual machines (VMs) to automate data into storage.
• Going this route is expensive, isn’t scalable (either up or down), and can suffer from reliability and performance issues.

Cloud-native file transfer, on the other hand, is designed to run in the cloud natively (hence the name—funny how that works).

That means it provides greater flexibility, efficiency, security, and scalability without shoehorning traditional and inefficient workflows into expensive infrastructure.

Cloud-native transfer services don’t require any infrastructure purchases, and offer browser-based file transfer that’s easy for anyone to spin up and use—even external stakeholders and freelancers—without significant IT burden.

Legacy Managed File Transfer: Barriers to Productivity

The following scenario is common among enterprises that regularly move heavy files:

1. An organization wants to get content to cloud or other storage using traditional MFT software like Signiant or Aspera.
2. So they spin up a handful of VMs/compute instances (to ensure performance, redundancy, and load balancing), a required step when migrating traditional MFT workflows to the cloud.
3. Their clients and stakeholders connect to these instances, using the Aspera or Signiant client to get data into cloud storage.

This traditional MFT model of getting file uploads to storage can be so baked into an organization that, in many cases, it sometimes doesn’t occur to their IT teams that spinning up instances and running VMs isn’t even necessary with cloud-native MFT.

Compared to cloud managed file transfer, the traditional model of sending files can be incredibly inefficient. Here are a few more reasons why.

Performance impacts

All things being equal in terms of bandwidth capabilities, there really isn’t much of a difference between the traditional model and cloud file transfer when it comes to receiving single file packages sequentially (assuming there are no extra buffering steps in the workflow).

It’s when organizations conduct multiple file transfers concurrently that things get hairy.

For example: What if you need to receive five large file packages, from five different stakeholders, at the same time using a VM that can handle 1Gbps of ingress bandwidth?

• Because the traditional setup’s bandwidth is limited to 1Gbps in total, if each of those five packages is 100GB in size, the total file transfer time would be around 4,000 seconds (or a little more than an hour).
• That’s not counting any extra scripts for quality control (QC) or other functions you may need to run, which degrade performance.
• Under cloud managed file transfer, on the other hand, each individual package receives 1Gbps bandwidth—multiplying the efficiency of every transfer for a 5x performance improvement (or around eight minutes in transfer time).

This is because traditional file transfers are limited to the bandwidth of an individual instance, while cloud-native file transfer multiplies your bandwidth when sending multiple files simultaneously, no matter where on Earth you’re sending them to or from. Cloud-based file transfer such as MASV ride on a powerful network of global servers that provide high performance transfer practically anywhere.

Cloud transfer services can also run a practically unlimited number of objects or processes in parallel, meaning you don’t need to wait for QC or malware scripts to run sequentially on various batches of files.

Traditional P2P file sharing simply can’t do this unless you pay for more instances.

Total cost of ownership (TCO)

While the example above uses a 1Gbps connection for the sake of argument, it’s of course possible to beef up your bandwidth under a traditional MFT model by acquiring more and faster instances.

But that comes at a significant—and seemingly always rising—cost.

• Most general purpose instances from Google Cloud, for example, offer varying bandwidths but top out at between 100 and 200 Gbps at the very high end.
• In Google Cloud’s europe-west4 region, that means a single instance at 200 Gbps would cost more than $800 per month (at $1.10 per hour).
• Because most cloud providers lock you into annual plans at the minimum, these monthly costs are perpetual and unchanging until your deal comes up for renewal—even if you don’t have the traffic to support those instances, you can’t turn them off.
• Scaling this model up by adding more instances means doubling, tripling, or even quadrupling these monthly costs.
• Costs also include overhead and management of the instances, which often accounts for an additional 20 percent.

With cloud managed file transfer, extra bandwidth capacity required to send multiple large transfers at the same time is free and virtually unlimited, and scales up and down as needed without needing to purchase more infrastructure. There’s also no server or infrastructure management required from the client side.

Fiabilidad

Traditional file transfer is also less reliable than cloud-based because of its single point of failure if something goes wrong: If your instances go down, for example, stakeholders must either delay or retry their transfers later on.

• Traditional P2P file transfer will fail if a recipient’s storage or instances go offline, or even if storage runs out of space, which adds up to extra costs, delays, and inconvenience for those sending you files.
• Cloud-based file transfer sends data to the cloud before hitting its destination, which creates a buffer in case of outage on the receiving side—meaning your stakeholders only need to send transfers once. The cloud system will relentlessly retry those transfers until the recipient is back online.
• It’s always possible to add more instances to alleviate a situation like the above, but as established above, that’s expensive and not very flexible if you need to scale down later on.

Flexibilidad

Cloud-based file transfer is also super flexible—so much so that, through custom development, it can handle virtually any requirement on the recipient’s side.

• Need to trigger a job once the content is in your storage bucket? You can do that through custom webhooks via the provider’s API.
• Do you use internal scripts that require specific file formats, like XML or JSON, and that can’t be changed? All you need to do is ask and a cloud file transfer provider like MASV will make it work.

Migrating on-prem workloads to the cloud via cloud-native custom development helps alleviate much of the pain (and lack of productivity) that usually accompanies a traditional lift-and-shift.