FEATUREDApplication Development & Modernization
No man is an Island – John Donne
From John Donne’s 1624 poem “Devotion upon Emergent Occasions,” this line intends to convey the connected nature of mankind – that we are each part of a larger whole.
What does this have to do with cloud readiness? Everything. Clouds are built to host applications, and in most Enterprises, application flows and interdependencies are poorly understood and seldom documented.
Legacy applications are rarely stand-alone systems. In Enterprises, these applications were built over years, so they are highly connected and interdependent. Mapping a set of application flows can be complicated, and the resulting diagrams can look like a Rube Goldberg device.
Separately, there is another issue – Cloud connectivity. A CIO once asked us about a performance problem one of his teams was having with Amazon’s AWS (Amazon Web Services):
‘I have an internet connection, and it’s not saturated; why is Amazon blaming our network?’
Could it be the network?
Yes, because sufficient bandwidth is not enough. Even basic connectivity requires analysis. His company was connected to a small regional provider and, in turn, to a pair of larger providers connected to Tier 1 providers, who were then connected to AWS.
Do you see the issue? They only have Service Level Agreements (SLAs) with the provider they were paying for connectivity – the small Regional Provider. From that point on, the connectivity chain was out of their control.
What else could it be?
A problem with application flows can look like a network issue. To explain, consider that successful projects were often written for the new environment as we migrated to virtualization and containerization within the enterprise. But for a moment, let’s look at the failures.
Failed projects took a piece of an application and virtualized it separately from the other components. This makes sense conceptually, but what if the Virtualized environment is in a new Data Center geographically remote from the rest of the components housed in a Legacy Data Center?
The failed implementations required packet flows between the old and new environments that were previously collocated. This could become a significant issue depending on the distance and numbers.
In one case, the issue was performance in the (partially) virtualized system. The application was several seconds slower, and this supported an online Web-based system. When we pointed out the latency issue, it was initially dismissed. After all, the Data Centers involved were only 40ms apart.
However, detailed investigations showed that the number of packets involved (well over 100) was far larger than initially thought and that the data transfer used the TCP protocol. This requires acknowledgments (TCP sends a window, then waits on an acknowledgment before sending the next window or resending the current). Poor MTU management, link quality issues, and other errors can exacerbate performance issues.
Because the application was only partially virtualized, the packet flow went in and out of the DC where the virtualized system resided. This ‘trombone effect’ in the flow was killing overall performance.
The moral of the story is that when we discuss moving items to the cloud, we must remember that, while the term is an abstraction, the actual systems supporting our apps live on physical servers and infrastructure somewhere.
It is important to know where that ‘somewhere’ is located and how we connect to it. These are details that cannot be abstracted.
If we solved the connectivity issues with the Cloud, – what could be moved there on Day 1?
- Stand-alone apps
- Intact Application Suites
- Software as a Service (SaaS) offerings
Stand-alone Applications
These are special-purpose applications with no interdependence on other Enterprise applications. The exception could be one-time flows, such as using a Single-Sign-On system for credential management, but the rest of the user’s application flow should occur entirely within the cloud.
Intact Application Suites
As the name implies, these are applications that work as a unit. Think of a typical financial management suite – General Ledger, Accounts Receivable, and Accounts Payable. Each of these major systems might be made up of components. For example, the AP system may have a check-writing system and an application that supports connectivity to Banking payment systems.
An Intact system would be defined as a grouping of these component applications that would work together as a unit and collectively look and appear as a stand-alone system.
Software as a Service
Some SaaS Applications are run in AWS, Azure, or Oracle Cloud Infrastructure, but some SaaS Applications, such as Salesforce, run in their own ‘Cloud-like’ infrastructure. Each of these is interconnected with a variety of Mobile and Internet providers. The result is that many companies run systems such as Salesforce separately from their internal IT infrastructure.
Many examples of this exist. Firms are taking their internal ERP and CRM (Customer Relationship Management) systems offline in favor of NetSuite, Email is moved to Office 365 or Google’s GMAIL, etc.
App providers also develop and host apps on general-purpose cloud platforms like Amazon’s AWS.
This form of Cloud is a Hosted Application model. It allows companies to remove the internal apps that are not core to their business (likely candidates are payroll, HR, CRM, ERP, and even email).
So how do I know if I am Cloud Ready?
First, you need to assess your systems.
An ‘Initial Cloud Readiness Assessment’ would look at the following:
- Internet, Cloud, and SaaS Connectivity
- Bandwidth
- Latency
- Peering Relationships
- QoS
- Internal Connectivity
- Bandwidth
- Latency
- QoS
This would be sufficient for analyzing and remediating the deployment of SaaS and Stand-Alone applications. Getting past this stage would require an ‘Application Cloud Readiness Assessment,’ which would require understanding the full mapping of all the flows between all components and subcomponents in an Application Suite.
Imagine a large, complex legacy app that migrates 99% of its components to the Cloud. Sounds perfect? The 1% example might be good if it was a small part of the data flow, but not if it was a client database that required significant flows at several stages.
This subject is complex and often problematic because Application teams are spread across many constituencies. Even when firms have them, Enterprise Architects rarely have the technical networking skills needed to examine the whole picture. The key to success is the right partner who can help you navigate all the choices.
To learn more, contact us about the assessments we can perform to address any concerns and improve your application performance.
Further posts in this series will explore these subjects and illustrate solutions.
