Your Genesys Blog Subscription has been confirmed!
Please be sure to whitelist [email protected] to ensure you receive Genesys emails.
Don't Show This Again.
Please be sure to whitelist [email protected] to ensure you receive Genesys emails.
We’ve all played the game: You look at the sky and try to make meaning of the random shapes in the clouds. And yet, these bodies, which can be hundreds of square miles in volume, are governed by concrete behaviors expressed across a billion copies of tiny components of water called micro-droplets. The Genesys® PureCloud® application was built to emulate the behaviors of a natural-occurring cloud to self-regulate and persist. It can be difficult to appreciate the business value of these advancements without understanding the underlying behaviors in non-technical terms. In this article, we’ll look at scalability, how the PureCloud architecture behaves — and why this matters to you heading into the 2020s.
The technological equivalent of a micro-droplet of water from a natural-occurring cloud is called a microservice. In terms of a cloud contact center, each microservice represents a tiny part of functionality that you’ll be familiar with in the contact center. One microservice is responsible for an agent’s status while another is responsible with connecting a customer to the agent. Still, a third microservice checks the agent’s status before allowing an interaction to connect. Every possible feature and function of a contact center solution is broken down into hundreds of discrete microservices.
A whole collection of microservices brought together to work in concert is called a cloud service or cloud solution. Much like a natural cloud, a properly designed cloud solution relies on massive duplication of microservices. And each body of microservice can grow and shrink to accommodate its local conditions. Let’s walk through that lifecycle.
For simplicity, we’ll start with a microservice that’s dedicated to handle voice interactions and has a capacity of handling 10 customer interactions simultaneously. Let’s start with three copies (instances), so now we have a capacity of 30 customer interactions.
The PureCloud architecture uses load balancing to evenly distribute microservice utility across a given cloud region. If three voice customers come in at the same time, the load balancer distributes those equally across all available voice microservices. So, we have one active interaction on each of our three voice microservices.
Here’s a look at what happens when we get close to capacity.
In our simplified scenario, when call volumes reach 10% of capacity across all available microservices, a brand new copy (instance) of the microservice is created and deployed. Through automation, we have four microservices to meet call volumes: three are near capacity while the newest one is empty and ready to handle 10 more interactions.
The load balancer sends the next call to the newly created microservice because its capacity is out of balance with the others. Over the next several minutes, as interactions are completed and new interactions come in, all microservice volumes are balanced.
This ability to automatically create microservice copies to meet demand is called autoscaling. When demand decreases, microservices are chosen to be decommissioned to an appropriate level of readiness. This expansion and contraction is similar to how natural-clouds behave according to heat and moisture volumes. The difference is that a properly configured cloud service ensures that multiple copies of a microservice are always available for every occasion — from surges in volumes to upgrades or outages.
Upgrades With No Downtime
The PureCloud application continually deploys new features and updates each week. Following modern security practices, it’s not possible to upgrade, patch or modify a live microservice instance. Once a microservice is deployed, it’s permanently sealed to changes. Upgrades in a cloud service consists of creating copies of new versions of a microservice and destroying the old instances — all while handling call volumes seamlessly.
Suppose we have a new voice microservice that uses artificial intelligence (AI) to improve quality. It’s time to start replacing those outdated versions with a new version. We’ll use a cloud service technique called blue-green deployment.
First, a copy of the new AI version is deployed and marked as “green.” This is a live microservice that handles live voice interactions. Then, a microservice with an older version is marked as “blue.” The blue microservice isn’t allowed to receive new customers, but it’s not immediately destroyed because it’s actively handling customer interactions. Once it has zero volume, it will be destroyed. At this point, a new “green” AI version is deployed and the whole process repeats until all of the older-versioned microservices have been replaced.
If volumes suddenly spike during this process, only the enhanced versions of the AI are created to meet demand. Interaction capacity is never at risk during upgrades — and the system remains perfectly equipped to handle any level of demand. This also means that new features aren’t bottlenecked to a specific time when the entire system must be taken down to upgrade a small part. Features and updates can be deployed every hour, if desired. This ability to deliver updates across a live system — and provide a high frequency of these updates — is called continuous deployment.
Resiliency Against Outages
The resiliency a self-regulating cloud service creates is also valuable during outages. When the PureCloud application detects that a microservice has become unresponsive for any reason, it marks that microservice as “sick” and deploys a copy of a new one to take its place. If hundreds of microservices suddenly become sick, then hundreds of new microservice instances are deployed to take their place. There’s no such thing as “rebooting” a cloud system. There’s no single point of failure, so there are no cascading failures traditionally found in on-premises systems. A cloud solution distributes capacity to meet volume in the midst of upgrades and outages.
We’ve focused on a simplified voice microservice. But the real beauty is that every microservice feature of a cloud contact solution behaves this way — from chat, email and WhatsApp messaging to reports, IVR and Kenny G hold music. Every feature you’re familiar with is independently managed through thousands of microservices and massive duplication.
Further, no single system acts as a bottleneck. Your reporting microservices don’t care that your social microservices experience viral surges. Your upgrading workforce management forecasting doesn’t affect your CRM integration.
The Business Value of Cloud-Native Architecture
Consumer behavior has shifted across an increase in preferred channels and consumer interactions. In addition, the speed at which technology advances has exceeded the ability for traditional contact center solutions to keep up.
The PureCloud application was designed with a cloud-native architecture to address these problems — and many others facing a modern contact center strategy. Consider the benefits of the scalability and resiliency described in this article.
No more under-planning or overpaying for capacity: Whether the internet blows up because of your Twitter campaign or because you’re preparing for Black Friday, your cloud contact center capacity is autoscaled to meet any interaction volume. There is no capacity planning in a cloud-native world.
No more worrying that the upgrade will break your business: During upgrades, the system isn’t taken down and your entire contact center is always up to date. Your IT talent can focus on more meaningful activities that increase your customer service experiences rather than being occupied on system-wide upgrades and maintenance.
No more failover systems to maintain: There are always multiple copies of a microservice actively servicing each function at any given time. If one microservice fails, an army of copies is available to take its place. With no single point of failure, the cost and maintenance of a failover system becomes unnecessary.
With the PureCloud application, we’ve harnessed the ability to shape experiences at scale. And that can service employees and customers across the planet. Imagine what meaning you can create with some micro-droplets of magic and a cloud of imagination.
To learn more about the PureCloud architecture, take the online guided tour.
Chip was nearly a high school dropout. With some midnight grit he became a self-taught software engineer with experience in the healthcare and banking industries as well as founding his own companies and partnering with startups. Along the way he gained Genesys patents for contact center and artificial intelligence technologies. Chip is now the Global Cloud Evangelist for Genesys and spends his time as a...
Subscribe to our free newsletter and get the Genesys blog updates in your inbox.