Database networking the old-fashioned way
Let’s say you’re a multinational hospitality company that has an AWS footprint of 40 databases. Each of these databases likely was set up by a different member of your database team and with varying sets of defaults.
When the databases need to talk to one another—like in the case of an online booking, when the customer database and invoices database need to connect—the data exchange costs are exorbitantly high. And because this network is so heavily siloed, you also run into the danger of duplicating services. As a result, some invoices are accidentally generated twice, or else generated a month later. Meanwhile, the network itself has become painstaking to maintain and monitor, leaving it and your customers’ data vulnerable to breaches.
And this is all before considering the users who need access to this cloud.
Many of our clients maintain tens, if not hundreds of user accounts. Up until roughly three years ago, for one account to communicate with another, users either needed to utilize VPNs or hairpin traffic by sending their data to a data center first, in order to send it back to the same cloud and to a different account. Not only did this result in a costly process in terms of time, but also in terms of computing power.
What a mess, right?
MPLS and SD-WAN
In the past, companies relied on multiprotocol label switching, or MPLS, to connect remote branch offices to their data centers. MPLS is a networking technology that has helped run enterprise networks since the late 1990s—and is still used to this day. The problem is, to access cloud-based services by way of an MPLS connection, traffic needs to be backhauled to an enterprise’s central data center, rather than by way of direct access to the cloud itself.
Around a decade ago, the industry started adopting a new model. A software-defined wide area network (SD-WAN) utilizes software to enable multi-point connectivity and services between data centers as well as remote branches. Even with this improvement, the licensing fees remained high and communication between databases and accounts remained poor.
In 2018, AWS released Transit Gateway to address these lingering shortcomings, and to allow for inter-account communication in the cloud. But even that action didn’t completely solve the problem. The solution still did not offer the flexibility of dynamic policy control. Overlays—in which one resource gains access to another and then, once the exchange is complete, is revoked of its access—stayed beyond our grasp. And this state is where we’ve been for the past few years. Solutions on top of solutions, to try and wrangle the beast that is the multicloud, multi-SaaS environment.