Two Ways to Connect External Users to Cloud Apps: Direct Connect or Third-Party Gateway

This Industry Viewpoint was contributed by Alan Zeichick of Camden Associates

For enterprises, the ultimate purpose of the network is to connect end-users to applications. What the best way to make that connection – and make it affordable, scalable, secure, and reliable?

Let’s start with scoping this discussion. Those end-users may be employees or customers. They may be connecting laptops or desktops; mobiles like phones or tablets; or embedded systems like kiosks or IoT (Internet of Things) devices. They may be inside or outside the enterprise – i.e., connecting via the internet, LAN, or external networks not owned by the organization.

The applications themselves may be primarily resident on the end-user’s device and talk to a remote host to exchange data – think about apps. Or the applications might live entirely in the cloud or enterprise data center – think about applications accessed through a browser or via a virtual machine.

In all of these cases, reliable, scalable, affordable, secure connectivity is essential. If customers can’t access their applications, or if applications can’t access data, the customer will have a poor experience and may go elsewhere. If employees can’t reliably access applications, they can’t do their jobs – and productivity and profitability will suffer.

For this discussion, let’s make some assumptions: The application is running locally on a laptop computer, the user is an employee, and the user is accessing the applications from an external location – which may change from time to time (think sometimes a home office, sometimes coffee shops, sometimes hotel rooms). The enterprise-written application is running in a cloud data center using an Infrastructure-as-a-Service (IaaS) architecture, which gives the enterprise maximum flexibility on how that cloud service is configured and managed.

You’ll see that much of this discussion applies no matter how the user, application, and back-end services are configured – but making some assumptions here will make the conversation easier to follow. Remember, the goal is to connect the user (or the IoT) device to applications securely, with performance, and with reliability.

Connection Method 1: Application Links Directly to Cloud

The most common method of connecting remote applications to cloud servers is to simply have the application open a port to the back-end software, and begin talking. Of course, there’s no expectation of either quality-of-service or security – so nobody actually would create such a simple connection. Instead, some nature of security and QoS are designed into the application, and into the back-end software.

QoS must be coded into both ends of the communication path, though the requirements will vary depending on the app’s needs – which can vary from time to time. A simple transmission of telemetry data from a mobile device will require little bandwidth and short-duration connections. Streaming video requires a lot of bandwidth and a high QoS, with low delay and little jitter. In all cases, no matter the connection method, programmers must take these factors into consideration.

There may be a combination of needs: Sometimes the end-user sends up telemetry, and sometimes the server sends down new firmware, which must arrive with no corruption. Or for an end-user device, users may need to load documents from the cloud service, and then sometimes save them back.

Both the end-user application and server software must request the proper type of connection, and measure what they receive – and if the connection has low bandwidth, degrade services as appropriate. For example, a video stream might be lowered in resolution or in frame rate. If the connection drops, or is temporarily unavailable, the application may need to cache data being transmitted. Similarly, the back-end software may need to cache messages until the end user is connected again.

Security is a trickier challenge. Worried that packets will be intercepted? That’s relatively easy: Use encryption, such as SSL. This leaves it to the programmers to acquire and maintain the digital certificates.

How about ensuring trust – that is, guaranteeing the identity of either party? It is possible for either remote clients or for cloud services to be spoofed – to trick the transmission of data to a third party, either directly or through a man-in-the-middle attack. When using direct communications, it’s up to the programmers and enterprise system administrators to develop an authentication scheme, or to find and leverage the appropriate libraries.

Another challenge: Compliance. There may be corporate or regulatory rules stating that, for example, sessions accessed by the client while in the United States must be with a server in the U.S. Similarly, if the client is in Europe, the session must be established with a cloud service in the European Union, or with a specific country like Germany. Finally, if the client is in some countries, the software must not permit a session to be established for governmental reasons or because fears of hacking.

Programming these governance issues into both the mobile device and the backend services can be done – and is done every day, using tokens and a variety of schemes. However, depending on the complexity of the rules, this can be challenging to maintain. The complexity multiplies if various employees have different policies, or if there are a few exceptions to these rules. It’s also a challenge if the traffic is going over multiple Internet connections.

One challenge that the programmers may not be able to handle: Preventing traffic from transiting outside a specific geography, or to exclude specific geographies. You can make sure the end user and the cloud server are both in Europe… but can you guarantee that none of the packets will leave the E.U.? Generally speaking, no, not without extensive work with the carrier(s) involved.

That’s where the second method of communications can offer advantages, albeit with a financial cost.

Connection Method 2: Use an Intermediate gateway

Instead of coding all the QoS, security, trust, and government issues in the application – well, into both ends of the communications link – a better idea may be to engage a third party. The organization works with a cloud-based service provider that has a point-of-presence in many countries. The service includes a console where IT staff can specify policies for making connections – when and where they are permitted, how trust and authentication works, and what the QoS will be.

In practice, once the service is configured, both the back-end cloud application and the client application connect with the third party’s intermediate gateway using a local point-of-presence. The communications service applies policies to authenticate, and if the organization’s policies are satisfied, enables the connection directly – using its own network, in some cases, instead of the public Internet.

In other words, except perhaps for the client’s mobile device going to a local point-of-presence, none of the traffic ever touches the Internet. And even when the Internet is involved, there are multiple layers of encryption and tunneling, to keep traffic secure.

The downside to this approach? Cost. Third-party intermediate gateway services like this are businesses, after all. However, it would appear that those costs may be less than the costs of creating and maintaining a home-grown platform to handle security, QoS, trust, and governance between the mobile application and the enterprise’s IaaS cloud service.

The most comprehensive offering I’ve seen in this space is from NetFoundry, which is a subsidiary of global telecom giant Tata Communications. That’s where the NetFoundry system gets its local points-of-presence.

NetFoundry uses the term Application Specific Network (ASN) for its method of linking an enterprise’s mobile application to the enterprise’s back-end services. As the company says, “We deployed transit nodes, proxies, session controllers, & security infrastructure across multiple Internet service providers’ footprints all over the world. This allows the NetFoundry platform to dynamically choose network paths to meet application-specific needs while maximizing route availability and resiliency.”

All that’s required are APIs accessed by the mobile application and the back-end software, to create what NetFoundry calls AppWANs: “With our cloud-native global network control fabric as a canvas, you use NetFoundry’s web console and APIs to define your networks by designing and instantly deploying AppWANs. AppWANs are software defined encrypted overlays capable of dynamically adjusting to meet performance requirements, that define how endpoints are permitted to access services (such as applications) across the Internet and/or existing private networks such as MPLS. One major benefit of AppWANs is that since they are abstracted above network infrastructure, they are completely service provider agnostic.”

For small-scale applications, and for those without critical security, trust, compliance, and performance needs, using SSL to create a direct connection between the end-user application and the cloud may suffice.

For complex scenarios, including those where security, authentication and trust are paramount, looking at a third-party intermediate gateway service might be a better enterprise end-user-to-cloud-application strategy. This will be the best way to ensure robust, trustworthy communication – and maximize employee productivity, customer satisfaction, and business competitiveness.

Alan Zeichick is principal analyst at Camden Associates, a technology consultancy in Phoenix, Arizona, specializing in software development, enterprise networking, and cybersecurity. Follow him @zeichick.

If you haven't already, please take our Reader Survey! Just 3 questions to help us better understand who is reading Telecom Ramblings so we can serve you better!

Categories: Cloud Computing · Industry Viewpoint · SDN