SaaS series - GTT: Making the case for MSPs
This is a guest post for the Computer Weekly Developer Network written by Christian Helmus in his capacity as product manager for cloud services at GTT – a company known for its managed network and security services technology that provides secure global connectivity.
GTT designs and delivers technology using cloud, networking and security technologies. It serves thousands of multinational companies with a portfolio that includes SD-WAN, security, Internet, voice and other connectivity options.
Helmus writes in full as follows…
When we ask ourselves, how do we connect SaaS entities (?), let’s think about that question.
For enterprises building up their multi-cloud environments, it is important to understand the vast amount of work that goes on behind the scenes between cloud providers, network operators and service providers in order to make the best decisions.
[Despite the fact that I clearly work for a company in this space, I would like to try and validate the suggestion that] working with a Managed Service Provider (MSP) can support connectivity to SaaS entities in several ways.
Working with private and public-facing partners like Equinix and CoreSite, who host SaaS-based applications in their infrastructure, MSPs can connect directly into their datacentres and interconnection solutions allowing them to connect to their customers’ SaaS applications.
As many enterprises need to enable their employees’ access to SaaS applications over the public Internet, services such as a Managed SD-WAN solution are there to provide a better user experience with enhanced reliability – and if there is a connection to a Global Tier 1 IP network – it allows organisations to securely view and monitor their SaaS applications.
For SaaS applications like Microsoft Teams and Cisco WebEx, MSPs could provide connections through their SIP Trunking service, that is directly peered and integrated with these providers.
Finally, a cloud connection solution can be set up to provide enterprises with a private connection into services such as AWS, Azure and Google, using a MSP’s direct network interconnections with its cloud partners.
SaaS responsibility
Who is responsible for SaaS connection?
The answer to this question may vary depending on an organisation’s own needs. Companies are at different maturity levels and have different network architectures when connecting to SaaS applications. Solution architects and design engineers are valuable resources provided by managed service providers to help understand the organisation’s business objectives to help design a solution to achieve the best outcome.
MSPs provide connections inherently through many of their services including SD-WAN, Cloud Connect, SIP Trunking, Direct Internet Access (DIA), Broadband Internet and Fixed Wireless (4G LTE/5G). Enterprise IT teams can also be responsible for cross-connecting to the applications they support.
So then, what elements of any given cloud stack need to be integrated externally, or indeed internally?
Integrating a cloud stack, externally or internally, involves aligning various components to work together cohesively to meet specific business needs. The elements that need integration within a cloud stack may vary depending on, for example, the chosen cloud model, but also the specific policies and compliance requirements of an organisation.
Every cloud stack should at least have identity and access management (IAM), role-based access control (RBAC), monitoring, logging and security policies implemented. In addition, they all must be regularly reviewed to see if the policies described are the same as implemented in the stack.
A final key element with SaaS solutions is a proper backup strategy for the data that is stored within that solution. Being ‘In the cloud’ does not necessarily mean that your data is well protected. For example, this can be found in the shared responsibility matrix of SaaS providers. Managed service providers can help its customers with backups of data in services like Microsoft 365.
When – in the cloud-native software application development lifecycle – should we connect SaaS services and the wider cloud estate?
In the cloud-native application development lifecycle, a service provider would – at the customer’s request – be able to support with connectivity to SaaS services during the develop and deploy portion. For example, in the Retail sector any SaaS applications running on a point of sale (POS) could be connected into the retailer’s corporate network through SD-WAN.
So then, why does connecting the cloud give us a technology service that represents more than the sum of the parts within?
Cloud connectivity allows businesses to make smarter decisions and moves them closer to the edge. In addition, businesses can be more agile and efficient and provide a better service to their customers on a global scale.
For example, we helped with the implementation of a managed SD-WAN network in a cloud-based environment for chocolate manufacturer Barry Callebaut, enabling the company to provide its 13,000 employees across the globe access to its cloud-based software platform while continuing to serve its clients in over 130 countries. With the implementation of SD-WAN, they saw a lower network total cost of ownership and an increase in bandwidth of 77%.
GTT’s Christian Helmus: Works for an MSP, quite a fan of MSPs, surprisingly.
When should we break SaaS connections – and how?
Examples where an enterprise could consider breaking a connection to their SaaS service include a potential bandwidth issue, reduction in productivity and compromised connections. To help mitigate the impact of a broken connection, an enterprise should consider using a Zero Trust Network (ZTN). This allows the IT team to define policies on which user can connect to what specific SaaS application and with what specific device. For example, a sales professional does not necessarily need access to the HR application, or a finance professional can only use the SaaS application from their laptop when in the office but not from a local coffee shop.
Guardrails
Our penultimate question is about location. Where – in physical data sovereignty terms – can clouds be connected and where should borders, guardrails and port of entry checks be in place?
In a more regulated environment, rather than borders or guardrails and port entry, the key elements regarding data sovereignty terms are where the data is located, meaning where the storage solutions or storage devices are physically hosted. Compliance challenges regarding data are a prime reason why managed service providers who own and operate a private cloud platform are often consulted for their ability to guarantee data location at any time, even when replication is required.
Finally here, what roles do automation and the wider world of RPA play in the cloud connection SaaS landscape?
Automation and RPA can provide several benefits in the cloud connection SaaS landscape, including cost savings through faster time to market, improved business operations, better productivity, and a streamlined development process. This allows organisations to scale, provide better quality software and secure applications.
