Clearing Up Some Cloud Confusion

Melissa Swartz | No Jitter | May 19, 2016

Cloud experts offer guidance for differentiating between cloud offerings and the questions you need to ask.

The allure of the cloud has been, for many, the hope that the cloud will be the equivalent of the “Easy button” that will resolve challenges such as scalability, complexity, and resource constraints. But as the cloud marketplace matures, it’s apparent that not all clouds are created equal. In fact, the term “cloud” seems to have so many definitions that it has become an imprecise catch-all phrase, open to interpretation and marketing spin.

During his keynote at Enterprise Connect 2016, Rowan Trollope, senior VP and GM of Cisco’s Collaboration Technology Group, referred to Cisco Spark as having a “true cloud” architecture (view video recording here). Others have talked about “Cloud 2.0.” But what makes that different from Cloud 1.0? And what is that, anyway? More importantly, when an organization is making a decision about which technology to use, what questions should be asked to highlight the differences among offers so that everyone understands the capabilities they are actually getting?

I went searching for answers. I looked at three companies within the industry who have a history in premises solutions. However, they have also more recently introduced cloud services that are a complete departure from the legacy architecture: ShoreTel (Connect), Interactive Intelligence (PureCloud) and Cisco (Spark). All three companies have introduced cloud services that have significant overlap with previously existing on-prem products. All three essentially started over, rather than adding on to existing software. Obviously, that’s a lot of work. What made them decide it was necessary?

I spoke with executives at all three companies, and during our conversations, I found several common themes:

Why Write New Software?

“The old code wouldn’t work,” said Dan Rood, evangelist for Interactive Intelligence’s PureCloud Platform. “Well, some would work, but the way it was built was the problem. The old code was written to work with the data layer instead of calling APIs (as PureCloud does).”

“Spark was purpose built, by design, as a mobile and cloud paradigm,” Chris Wiborg, director of Collaboration Portfolio Marketing at Cisco, told me.

All described their new offer as a platform. They are all multi-tenant by design. “Everyone gets the same service,” ShoreTel CMO Mark Roberts said. . “A single tenant can be customized, but it’s more expensive and difficult to manage.”

But What If An Organization Wants Customization?

That’s where APIs (Application Program Interface) come in. APIs are one of the most common ways technology companies integrate with each other. Common integrations include Salesforce, Microsoft Dynamics, and other CRM systems, as well as emergency notification systems, property management systems, and many other applications. Access to APIs allows organizations to customize a cloud service to meet their individual needs. As Cisco’s Wiborg stated, “The platform is designed to work with APIs.”

Increased speed of development is another common element. “There is a continual evolution of the service,” ShoreTel’s Roberts said. “Think of Google or Salesforce — what version are you on? No one has a clue.” Glenn Nethercutt, an architect for Interactive Intelligence’s PureCloud, remarked, “In three years of development, PureCloud will surpass capabilities of CIC (the ININ premises system) that has had 20+ years of development.”

In these cloud services, software is updated constantly — not every two weeks, but constantly. “Customers like incremental features that are learnable and immediately consumable with direct ROI,” said Randy Carter, senior marketing content architect with Interactive Intelligence. “They don’t have a huge learning curve that they would have with a new software release on a premises system. They have small changes that are manageable.”

But if an organization has customized its service by connecting to other applications using APIs, isn’t there a risk that when new features are deployed, something will break? “APIs are not changed (with new updates)”, Interactive’s Nethercutt told me. “We may give access to more data than previously, but the old capabilities are kept the same.”

What About Scalability?

“Software virtualized in a data center is not a cloud,” according to Mark Roberts. “Even if it’s multi- tenant, there’s no elasticity built in. It’s a matter of philosophy and approach. A true cloud is able to go small or large without any architectural changes. An architecture that is developed as a cloud has no concept of how many users it will support. In contrast, a premises system is based on ‘X’ number of users”.

“If there are problems with scalability, it has to do with architecture,” Interactive’s Rood added.

Are There Differences in Failover Capabilities?

“Yes!” they all agreed. “Some ‘cloud’ solutions are not based on a true active/active architecture with automatic failover,” explained ShoreTel’s Roberts. “In some cases, failover is manual.”

I asked all these cloud experts what questions an organization should be asking to uncover what type of cloud services they are being offered. Their recommendations are what follow:

Platform

• Is the platform based on a microservices infrastructure (which provides resiliency) or is it monolithic (software virtualized in a data center)?
• Is the architecture a virtual infrastructure, or is it services-based?
• Is it AWS- or Azure-based? If AWS, what parts of AWS (how many microservices, or what percent of services offered) are being used?
• How is maintenance done? Are customers shut down for maintenance, or is there continual up time?
• How is the offer referred to? If it’s referred to as a “product” or a software version is stated, it’s not a true cloud service. Versions don’t exist in a cloud.
• Are hybrid options available? How do they work?
• Is the platform supportable? As the number of customers on the platform has increased, how much have the number of support tickets increased? If the number of support tickets remains constant (or decreases) as a percentage of the number of customers, this indicates the stability of the platform.

Customization

• Does the architecture provide access to APIs and the underlying data?
• What are the customization options?
• Are connectors/APIs or heavy customization offered?
• Can the services be federated with outside organizations or individuals?

Feature Velocity

• How are upgrades/new features delivered? Automatically?
• How often is software updated? Every 2 weeks or constantly?
• What is the upgrade path (large disruptive chunks, or iterative small bites)?
• How big is the deployment team? (A small team is indicative of a true cloud solution.)

Security

• If AWS is being used, are the parts of AWS that enhance security such as VPC (Virtual Private Cloud) being leveraged, or are virtual firewalls just being used?
• Is secure signaling offered?
• Is the data stream encrypted?
• Is e-discovery provided?

Scalability

• If there are problems, can more VMs be added to scale cheaply?
• Explain what happens when loads increase in a significant way for ‘Part X’ of the architecture. (You want to hear that it expands/contracts automatically.)

Failover

• Do they do active/passive with failover or active/active, load balanced with automatic failover?
• How long does it take to switch to another data center?
• How is the architecture tested?
• Is chaos testing utilized?
• Do they have a site reliability team?