When cloud-based applications aren’t performing as well as is needed, investigating “cloud accelerators” might seem to be a logical next step. But that term means different kinds of products and services, depending on the context.

“Cloud accelerators” sounds like a generic term for solutions that might provide better performance of cloud-based applications. While it’s true that it’s used that way, simply googling those words and sitting back to page through the options isn’t going to be as simple as it might appear. These remedies have the goal of speeding up app performance but dissimilar methods and points of use.

Of course, the drawback isn’t the concept itself. Improving the performance of cloud apps, sooner or later, becomes a stopping point on any road to a better cloud environment, whether that environment is private, public, or hybrid. The benefits of improved performance most cited are more dependable services (better connectivity between cloud services and corporate users, as well as limited downtime because of redundant resource availability), flexible scalability (the ability to add virtual environments on demand at peak activity periods), cost savings (avoidance of paying for just-in-case extra capacity when it isn’t needed), and faster migration potential when expansion is warranted. Other benefits can be unique to certain enterprise types (e.g., faster response for e-commerce portals, enhanced customer browsing, faster data transfers and general communication), nor are the potential gains limited to these few examples.

However, “acceleration” in the cloud sphere refers to a whole spectrum of activities. Understanding how broadly the term is currently applied is worth a brief survey to see how complicated selecting a cloud performance solution type might be.

The Burgeoning Cornucopia

Accelerators of a fundamental type have to do with hardware. Graphics Processing Units (GPUs), for example Advanced Micro Devices’ AMD Instinct MI100 Accelerator or NVIDIA’s RTX 40 Series, are considered “accelerators” because they can simultaneously run processes that are capable of operating in parallel but in which those processes aren’t dependent on the speed of producing each other’s results. That could mean, in the right situations, faster parallel processing of individual users’ requests to access cloud applications, resulting in faster response times for any users concurrently using those applications. Edge computing applications (as this sample product page of Dell Technologies illustrates) even go beyond use of mere processors to include gateways and servers engineered to accelerate edge functions. If a hardware upgrade seems to be the solution for slow response times from cloud apps, this could be the first path to investigate.

At what we might call the conceptual level are solutions for enterprises that don’t yet have a cloud presence but are planning to move some or all their apps to a cloud environment. One way to do that would be to provide the organizations’ programmers with a software structure and an accompanying methodology that would help developers build a hybrid or multi-cloud environment that emphasizes both scalability and reliability, such as Persistent Systems’ Cloud Automation Stack (CAS). How does one refer to this structure? Persistent itself terms CAS “a library of proven accelerators.”

Perhaps, though, an organization is planning to go with a large Web services provider, such as Amazon, and doesn’t have the IT infrastructure necessary to handle the transition to cloud alone. In that case, something like Amazon Web Services Application Migration Program for Windows (MAP) would more be useful. Here, the migrating enterprise has a wealth of software products and services to choose from to help manage their transition.

Alternatively though, an enterprise may want to avoid relying on a single company for both transition software and the overall cloud services by seeking a third-party solution such as, for example, Trianz Software’s EVOVE (software that helps automate the cloud transition process) or the same company’s AWS Athena Federated Query, which enables users to make queries across multiple databases both within and without the AWS cloud environment. Similar software can also set up abstraction layers between enterprise systems and the cloud, as well as take advantage of other cloud management services or Infrastructure as a Service (IaaS) platforms. But whether an organization favors a software approach or a combined software and services approach to hasten its migration to cloud, the general term used to refer to members of both these solution types is, perhaps a bit awkwardly, “cloud accelerators.”

While we’re talking about services, we should at least mention cloud-related user training, offered by numerous companies, which can reduce the cost and improve the efficiency of accessing cloud-based apps. While not an exact match, that’s not far away from Techopedia’s definition of “cloud acceleration” as being achieved via “optimizing and fine tuning the Internet-based delivery network for enhanced performance and lower latency,” recognizing that users themselves, from the organization’s point of view, are part of the cloud delivery network.

Next to note are cloud acceleration services. A browser search for that term will turn up links to Microsoft Azure, Dell Technologies’ APEX Cloud Services, Trace3, and others. These services offer such cloud optimization options as AI-directed routing of queries and responses, high-speed data transfers, algorithms that reduce latency, and monitoring of all available Internet destinations to enable optimum hopping and avoidance of packet losses. Such services control traffic from hosts to destinations, leverage network performance metrics, streamline application code so there are fewer instructions for cloud apps to execute, and seek to exploit bandwidth availability opportunities to enhance communication speeds. Closely related are software-defined wide-area networks (SD-WANs), which speed communications by using encrypted tunnelling protocols to access predefined internal enterprise locations on the fly.

Finally, if an organization is looking not so much to adapt existing applications to a cloud environment, but rather to start a new business that is cloud-based, there are many companies that seek to provide financial help (although often for a percentage of ownership), advice, access to useful contacts or new customers, and sometimes even office space to such startups. Although sometimes called “incubators,” these helper groups are also termed…well, at this point, most readers can probably guess the word most often used to describe them.

Finding the Right Cubbyhole

No matter how you package it, “cloud accelerators” as a concept has inadvertently become a pretty big tent. The first step in finding an accelerator type that can best resolve a particular situation becomes a matter of choosing the cloud integration level that best describes an enterprise’s current position on the cloud-migration evolutionary scale.

If an enterprise is in the beginning stages of a cloud migration, or even just contemplating it, going with an established service provider will provide the expertise and a methodology for approaching the transition in a manner that’s already worked for many of the provider’s other clients. While the risks of getting involved in a vendor lock-in situation might be greater, it may be better to put that problem off until later rather than trying to reinvent a wheel others have already designed. Going with Amazon’s MAP system, or one that’s compatible with one of the other major providers, would be a good place to start at this level.

If circumstances or organizational priorities dictate that finding an in-house migration path is paramount, taking the route of using an application development system like Persistent’s CAS (or one of its competitors) to structure an initial effort could be helpful.

Organizations that already have a cloud structure in place but haven’t gotten satisfaction via their current cloud service provider have a more complicated road ahead that may require some reassessment of their cloud ecosystem to narrow down a specific acceleration path to follow.

An analysis team needs to define what specific functions are lagging in the existing cloud ecosystem. What activities are creating the most serious bottlenecks? What are the characteristics of the times when cloud traffic is most severely hampered? Are there different user functions in the cloud environment that seem to be interfering with each other? Are there some aspects of the enterprise’s application infrastructure that could benefit from being added to the cloud environment? Such factors need to be pinpointed rather than being bundled into a general performance complaint. Lagging response at certain times of day or when apps are making heavy use of cloud databases might make a hardware solution the first path to investigate. Alternatively, streamlining code within the applications themselves, investigating how communications are being routed at peak times, or some kind of traffic-control service might be a fruitful approach at this level of existing cloud interaction.

Consider also if the ultimate goalposts for the organization’s overall cloud migration strategy might need to be moved. Has the number of business transactions, or the numbers of users being served, increased over the life of the existing cloud structure? Has the enterprise added new lines of business that have expanded services demand and are straining some aspects of the cloud ecosystem? Is a new CSP with more capacity or services called for? Does there need to be a new balance in a hybrid or multi-cloud environment? A “yes” answer to some of these questions might call for a committee or task group to further explore the acceleration question, or even to extend enterprise capacities or goals.

Although answering some of these questions may be complex, it’s a necessary exercise to determine at what level of “acceleration” a particular enterprise might best start exploring ways in which it can improve application performance in its existing or planned cloud environment.                                                                                                

John Ghrist has been a journalist, programmer, and systems manager in the computer industry since 1982. He has covered the market for IBM i servers and their predecessor platforms for more than a quarter century and has attended more than 25 COMMON conferences. A former editor-in-chief with Defense Computing and a senior editor with SystemiNEWS, John has written and edited hundreds of articles and blogs for more than a dozen print and electronic publications. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

Primary storage vs. secondary storage: What’s the difference?

Planning for Multicloud Environment Management

Data Quality Management in the Cloud Too Important to Ignore