How many of us have started a home improvement project and ended up making a handful of trips to the store to complete it? Even a simple painting project can surface unforeseen problems that turn into 3 trips to the store for more tape, brushes, or plastic coverings.

While this might be annoying, it isn’t likely to cause you to lose sleep or interfere with your ability to do more important things.

However, when that “project” is the launch of a new SaaS product or a major cloud migration in the enterprise, the unforeseen challenges can result in millions of dollars lost or thousands of hours wasted.

The SaaS Networking Struggle

SaaS applications leveraging cloud databases they own and control have it easy. Keeping everything in a nice neat package with common access and security policies greatly simplifies the life of everyone from engineers, to DevOps, to customers.

But when a SaaS application requires connectivity to legacy systems or customer environments, networking becomes a critical (and many times overlooked) component. 

Historically, IPSec VPNs have been used to create site-to-site tunnels. However, when a multi-tenant public cloud environment must connect to a variety of 3rd party data centers, legacy VPN solutions can experience a variety of challenges that inhibit the ability to deploy, build additional features, or even properly support the application.

Initially, a software team’s understanding of the cloud networking component is limited to just 1 or 2 issues. They may think that they can push the networking problem to the customer, handle the challenge with some custom-developed code and APIs, or in the most extreme cases completely deny that there is a difference from the legacy point-to-point VPN solutions.

Working under these misinformed assumptions they move forward with product development and the product launch. But as development progresses, products are released, and deployments scale – the extent of the challenges they face comes into greater focus.

The first trip to the store

These problems unfold at different times for different organizations, but typically the moment of truth comes when new sites are being deployed. A customer lacks the ability to configure an on-prem network appropriately or a customer is unsure about opening up a firewall. This leads to delays in deployment, that then begin to stack as more customers experience the problem.

The application team is pulled in (the first trip to the store) to solve that problem – but then stumbles into challenges with maintaining the new remote sites. The networking or support teams are brought in (the second trip to the store) to brainstorm ways to overcome this next obstacle. 

How can we apply patches consistently? Are we sure that all connections are up? How do we determine whether a loss of connectivity is due to the application, network or remote data source failing? How many people is it going to take to ensure that all of this is working?  

Everytime one of these problems pops up, it’s another trip to the store. But instead of being a nuisance that adds an extra hour to the project, these “trips to the store” can slow the rollout of your product, impact user experience, and start racking up tons of unbudgeted CapEx and OpEx expenses.

The SaaS networking problem is everywhere

We see these situations unfolding time and time again. And not to new or inexperienced teams. We see this happening to some of the smartest software leaders in the business. 

Why? Because the architectures are new and the products are innovative – but they rely on legacy IT environments. Similar to the way that you cannot see what is around a corner you have not previously passed, these problems often can’t be seen until you experience them or someone who has been there before explains it to you.

In our latest eBook we dive into the challenges of these distributed application architectures and explore the ways that SaaS networking can be simplified and optimized.

Read more about the challenges of distributed application architectures.