Cloud Service Architecture

The marked increase in the utilization of Cloud Services is affecting the foundations of IT infrastructures. OSHEAN’s Member institutions are each uniquely engaged in cloud service migrations according to their individual application environment needs balanced with the resources necessary to take on the migration project. We see everything from completed migrations of all applications, eliminating the local data center entirely, to members in the early planning stages of moving their first application. At the same time, application vendors are doing their own migrations from premise-based installs to Software as a Service (SaaS) in the cloud. For all members, the understanding of the network implications from design to production, cost and support should not be underestimated.

Don’t Forget The Network

Often, the network is the last thing considered in cloud migrations.  IT organizations are typically structured with apps teams and network teams in different lines of command and applications teams usually lead the way in migration projects. OSHEAN’s Cloud Access services are designed to help our members migrate to the cloud with a resultant network architecture that optimizes routes, resiliency and maintenance of the individual payload to its destination.   

Cloud migrations happen on an app-by-app basis.  The characteristics of that application will determine criticality, latency restrictions, bandwidth and other important metrics that influence the design of the network path that will service it. One can then assess what transport method will work best.  Also, these choices will affect overall cost of the given service. 

OSHEAN has partnered with Internet 2 to integrate their Cloud Exchange fabric with the Beacon network.  With our I2 integration, we can assure transport on our private fiber network right to the destination cloud service. This affords all members the option of building the most robust and resilient Access platform they wish.  They can decide to build geo-diverse resiliency by designing primary and secondary access to say, Ashburn and Chicago.  They can also choose the type of connectivity be it commodity Internet, Layer3 VPN or Layer2 Ethernet peer.  Many end up in multi-cloud, hybrid environments, using the optimal cloud provider of choice to fit the app.  We also have members who use the Exchange’s functionality of interworking between cloud providers for optimal route efficiency for the function (i.e. backup). 

Visibility, Telemetry and Analytics 

OSHEAN has done significant development in the area of telemetry and instrumentation to provide members with visibility to their most critical applications.  We have partnered with Cisco’s ThousandEyes platform to combine with our other tools and deliver a service that is designed to optimize and manage traffic on a payload/route basis.  Cloud migrations potentially put highly critical applications many miles away from the source and these tools are essential in deployment management.  The telemetry and analytics of OSHEAN’s toolsets are designed to produce end-to-end insights, from the end user source to the target node of the cloud service. 

Security, Security

The expansion of the network perimeter has challenged organizations to confront the security question of the network payload, the cloud provider and the app itself.  While many choose to use native cloud provider security, others, who have significant security objectives, on certain apps have chosen to use OSHEAN’s ability to build MACSec encryption into the payload.  In this case, the NCS network element here encrypts the traffic bound for a provider and, given the industry standard, decryption can happen inside the target node of the provider.  We expect to follow the cloud security challenge along with our members as this functionality becomes more prevalent.