A business point of view...

During the last year and half, we have been working with a few major global banks to test and evaluate our solutions.

To be honest, we were approached by these banks as they started to see the need to create an edge strategy and also start to think about consuming multiple clouds (buzz word – ‘Multi-cloud’), mostly in a private way.

It is important to draw a distinction between multi-cloud and multiple clouds. Many companies begin their journey by adopting Software as a Service (SaaS) offerings like Office 365, Salesforce, or Workday as their initial baby steps to the cloud. If this first foray was successful, these companies look to take further advantages of the cloud by turning to more complex applications.

For others, moving to the cloud is an exercise in lift-and-shift. Applications are hosted in AWS, Azure, or GCP rather than within a private data center. As companies explore the operational nuances of various clouds, they might favour one or another for specific applications, typically due to economic or performance requirements.

The promise of multi-cloud, however, is not about simply fracturing the IT environment into cloud-specific shards that encompass infrastructure and operations for bounded domains. Multi-cloud is about managing distributed resources—regardless of whether they reside in a private or public cloud—as a single, cohesive infrastructure.

The ultimate goal of a multi-cloud environment is in fact the absence of an environment – in other words, the infrastructure should be invisible and thus location shouldn't matter.

The beginning...

And this is where we started with the big banks – The adoption of SaaS.

To be more specific, the adoption of Office 365 (now known as Microsoft 365) as SaaS (but this could be any other SaaS, really).

Adopting Office 365 as SaaS carries some extra complexity because Office, as an application suite, has been used and managed by internal IT teams for YEARS ... and as such it is a little more complex to change processes then to adopt brand new ones.

And this was really the task proposed to us by these big banks. Let me write the task in simple words – “We want to connect our users to Office 365 with the same quality of user experience they have now but with the additional benefits of the Office 365 platform, mainly towards collaboration.”

Ok so we know a few things:

1. Office 365 (as most SaaS platforms) is accessed via the internet
2. The internet doesn’t offer quality of service

   a. FIRST ISSUE – How can we guarantee quality of user experience?

3. Accessing a SaaS platform over the internet might break CORP security mandates (in highly regulated environments such as these big banks)
4. Access to the internet is done via a proxy … via a TCP proxy

   b. SECOND ISSUE – So what about Voice and Video?

Ok, so before going through further details about the above mentioned items, one question really pertained – “What, in reality, is the drive to change from Office on-prem to the SaaS offering of Office 365?” - This question could also be framed as “What, in reality, drives the change to adopt SaaS offerings”.

Business Drivers

Well the answer to this came down to business drivers. The first business driver was an operational one related to the fact that to maintain Microsoft Office applications on-prem requires a massive amount of infrastructure and a complex IT organizational structure to support these applications including, but not limited to, a number of teams/professionals that represent a huge operational burden.

The second business driver was how to achieve better collaboration without harming security.

Global banks have a massively distributed footprint in terms of data centers, campuses, branches, and people. And they need to connect everyone. So having a widely distributed workforce complicates the task of collaboration and thus the adoption of tools that enhance this are a must. But whilst collaborating inside their corp network using their private backbone can be perceived as secure, doing it over the internet with people working from home and connected anywhere has its challenges.

So how to achieve collaboration without harming security when you have a massively distributed workforce? This is where private backbones come into place – carrying traffic over a private backbone not only is perceived as secure (as stated above) but also allows for traffic engineering to achieve quality of user experience. And guess what — banks do have their own private backbones already. So how to connect their backbones right into the SaaS provider to ensure the traffic stays private end-to-end?

There are 2 answers to this question:

1. In the case of Office 365, the Azure platform allows large enterprises to have private, dedicated and high-speed links to its cloud called ExpressRoute circuits. Microsoft, therefore, can now address the common latency and performance challenge by allowing enterprise employees and VDI systems to access Office 365 via this dedicated private ExpressRoute circuit.
2. The second option is to use a service provider that is already connected to these SaaS and cloud providers with dedicated links, via their own private backbone – like Volterra. (yes, in this option you don’t need your own private backbone).

Let’s dig a little deeper on the first solution:

There are a set of services that a bank will need in order to connect and send employee traffic to Office 365 via a private circuit, as well as services that are mandatory when a bank establishes a new circuit – which is in a way a new DMZ, so the services existing in the DMZ need to be there. The minimum set of services needed are:

• Firewall / router – because there is a need to route to the public endpoints (yes they are still public) via this circuit, to inject them in the corporate network and to secure all this by implementing firewall policies and NAT
• Proxy – because there is a need to comply with CORP policies like doing tenant restriction (to only allow access to the corporate accounts via this new path and deny access to private accounts)
• Load balancer – because there is a need to distribute traffic across all the services for distributed processing and also for high availability.

The below picture illustrates this:

So, while one of the business drivers was to reduce the infrastructure and operational burden, there is still a large set of services and infrastructure needed to maintain this option.

Also there are some challenges associated with this approach related to:

1. Injecting public IP address space into the corporate network
2. Managing the diverse paths that users now have to access the services (private circuit and internet)
3. Maintaining the services / appliances needed (as described above)

Enter Volterra

The Volterra VoltMeshTM service can be deployed as a SaaS-managed private access solution for enterprises that includes an application router with programmable proxy and a load balancer. This solution can simplify ExpressRoute implementations and overcome the security hurdles created by the changes to the internal network architecture. This Volterra solution enables enterprises to provide employees with the benefits of ExpressRoute to Office 365 and related application services, while elegantly removing the need for deploying and/or managing complex network infrastructure and security policies.

At a high level, the enterprise will have VoltMesh deployed in one or more locations of the enterprise and peering with the Azure ExpressRoute router where Microsoft presents the Office 365 routes/services. VoltMesh performs automated discovery of the Office 365 endpoints via this router, allowing enterprises to access Office 365 services by implementing the infrastructure components required (firewall, router, proxy, load balancing) in a distributed fashion and thus removing the potential latency (traffic hits one appliance only), risk (routing complexity is removed), and ensuring an optimal user experience.

The below picture illustrates this:

Main comparison points at a glance:

Below is a quick overview of one solution versus the other – side by side:

Operational Overview

Now that we have covered the technicalities around the solutions and what the benefits are, we should focus on the business drivers mentioned in the beginning of this paper and see what the operational impact is of one versus the other.

From what we covered before, there are some operational items that we should focus on. These operation Items are:

1. Adding capacity to the infrastructure that connects to Office 365 – in this scenario we have to compare that in one side we are adding capacity at 3 different layers and 3 different appliances (firewall, proxy and load balancer) and on the other side – Volterra – we just have to add one box that will automatically cluster.

Below is the overview of this comparison:

2. Change configs – Office 365 changes or adds endpoints often. In order to maintain the normal functionality, these endpoints need to be updated and allowed throughout the 3 devices. With Volterra, due to the automatic discovery of the endpoints, this process is automatic as seen below:

Below is the overview of this comparison:

3. Upgrades – Being software, OS or firmware upgrades - these boxes will need to upgrade. Volterra upgrades are done as a fleet of sites/appliances. You click once and the rolling process starts.

Below is the overview of this comparison:

4. Troubleshooting – This is probably the task that will happen more frequently – users do complain – and for each complaint the infrastructure is often blamed before any other troubleshooting is done. Troubleshooting infrastructure across multiple devices, often managed by different teams, is a lengthy process and very hard to correlate. VoltMesh offers automatic correlation between all the services deployed and all teams (NetOps, SecOps, DevOps and developers) have the same view and can get all the information already correlated in the observability dashboards provided.

Below is the overview of this comparison:

Yearly Overview

So what does this all mean and what is it translated in terms of operational breakdown at the end of the year?

In this exercise, we had to make a few assumptions so that we could get the total numbers at the end of the year. The assumptions we made were the following:

1. Adding capacity – we assumed that capacity would need to be added once a year
2. Configuration changes – we assumed that there will be one configuration change each month. This aligns with what Microsoft writes on how often their endpoint addressing and naming can change / add
3. Upgrades – we assumed that 6 upgrades are done per year
4. Troubleshooting – we assumed that there would be a need to troubleshoot two situations weekly. This is probably an optimistic assumption, but we didn’t want to overload the calculation.

So based on the above assumptions, we came out with the below yearly overview of operational expense:

Conclusion

Yes it is a massive difference, one that Volterra and its SaaS-based platform was created exactly to address — the issue of high cost of operations and time resourcing. For a very long time, infrastructure sprawl has been taking place, increasing exponentially as business grows, leading to a workforce also growing and creating new needs.

Collaboration between teams is increasingly important, not only to avoid every team doing their own "thing" but also to avoid conflict and make sure that each own "thing" aligns with the business strategy and end goal and doesn't break any other "thing" (from other teams).

Here at Volterra, we’ve designed a comprehensive solution for connecting and securing modern apps via a single SaaS-based service, VoltMesh. We feel it addresses the majority of new requirements for app-2-app and user-2-app networking and security. Volterra was built with collaboration in mind across all teams (NetOps, SecOps, DevOps and Developers), making sure that all the configuration, strategy and deployment of a service is available to all the other teams to either consume or observe.

Volterra currently offers a freemium service of VoltMesh (including its unique globally-distributed load balancer/ingress-egress gateway + firewall + proxy + router + API gateway + API auto-discovery and control) — and you’re welcome to try it for yourself today.