ENSURING UNINTERRUPTED PERFORMANCE

WHAT EXACTLY IS ‘HIGH AVAILABILITY’?

Technically speaking, ‘availability’ refers to the ability of a service or system to provide a specific minimum level of performance. But how can that minimum be defined – or achieved, for that matter? Is it enough if a network component can be ‘pinged’? Is that an appropriate measure? Unfortunately no. Taken by itself, a successful ping response from a component won’t necessarily make for a successful call connection. In fact, there are lots of other factors involved in terms of quality and functionality. Clearly, to ensure availability one must consider the system as a whole.

THE UPDATING (PSEUDO-)PARADOX

Both admins and users of classical IT server environments know the problem: the usual permanent flood of updates, patches, hotfixes and releases poses a huge challenge to service availability. Scheduled (or even unscheduled) downtimes are the highly stressful but necessary downside of keeping these systems up to date and up to standard. As a principle among IT professionals, “never touch a running system” goes only so far, as failing to update can quickly bring a running system to a screeching halt.

Systems with Commend components have a definite advantage in this regard, owing to their hallmark fail safety. But this still leaves us with the question: How to update an entire system that never sleeps? A system like the Symphony Door Call, which people depend on around the clock? Surprisingly, the answer is – by updating it continuously. How is that possible, you ask? Well, luckily the Internet and its cloud-based solutions have given rise to the technical means of solving this apparent paradox.

SYMPHONY COMPONENT REDUNDANCY: HIGH AVAILABILITY BY DESIGN

Cloud ‘native’ systems don’t come in single-block all-in-one units but are made up of numerous ‘micro-service’ components. As a result, complex systems to be broken down into individual, easy-to-manage sub-systems, each performing a specific task and being fine-tuned for optimum availability. This way, database servers can be linked into clusters, redundant systems can be load-balanced for fail-safety, and specific services (such as user authentication) can be pooled or provided ‘as a service’ (aaS) with a guaranteed availability.

For a single customer project, of course, such a technically and financially elaborate setup would never be economically viable. But since its resources (and costs) are shared among large numbers of clients, even small-scale system users can profit from this highly professional IT landscape at affordable rates.

Now, how does the Symphony cloud’s VoIP sub-system make use of this high-profile toolset? For one thing, it runs on redundant Intercom servers which are load-balanced by way of equally redundant gateways. These in turn make use of load balancers that are provided by Microsoft’s Azure cloud platform in a – wait for it – redundant configuration. If all of this makes you dizzy, don’t worry – no need for you as a user to deal with the nuts and bolts.

All that matters is that Commend’s specialists are taking care of everything to make sure the Symphony cloud is there for you when you need it. It’s a nice change, considering the growing tendency of businesses to shift the burden of responsibility and effort to their customers (like self-booking platforms and self-check-in points turning air passengers into “self-loading cargo”).

THE MAKING OF A SYMPHONY

Of course, redundant fallback components and load balancers alone won’t do the trick. A highly available cloud service is only as good as the software that powers it. Faulty software would spread its faults to all components – in a highly available way, mind you, but with undesired or even dangerous results. That said, it’s no secret that 100% secure software does not exist, or at least that above a certain size and level of complexity possible hiccups during the development process cannot be ruled out completely.

Of course, it is possible to mitigate the risk of errors, as Commend does in accordance with its ‘security by design’ product policy, coding guidelines and other measures. As such, these measures go a long way towards ensuring security as a built-in product feature. Accordingly, Symphony software has to run the gamut of some of the toughest trial and testing routines in the business before a single line of its code is released. Each individual change submitted by a developer is subjected to a series of thorough human inspections and automated tests. These include, among many others,

• Unit tests (will the new function work as intended?)
• Regression tests (can unwanted interference with existing functions be ruled out?)
• Penetration tests (has the new function introduced new security vulnerabilities?)
• Load tests (will the function scale to global requirements?)

Only when the software change has passed all these tests will it be allowed to proceed to the next stage. This is where the submitted changes are accumulated and re-examined carefully while continuous automated tests ensure that everything is working as it should. Only after many thousands of test cycles will the change be released to the live system.

DEV[SEC]OPS

But Commend being Commend, this is not where it ends. Of course, the live system is also constantly monitored for performance and availability, using fully automated tests and latest-generation AI technologies. This allows Commend’s Symphony engineers to take proactive action against possible problems.

The technical term for this holistic Development and Operating process is ‘DevOps’ (no surprises there) or “DevSecOps”, which includes the security aspect of Commend’s “Privacy and Security by Design” policy, to become the driving force behind the high availability of Commend Symphony services that users can rely on.

WHAT HAPPENS IF...?

Apart from minimising downtimes, ensuring high availability of Symphony services includes the ability to keep things going in the rare instances when the cloud connection fails. Symphony stations for instance have a few tricks up its sleeves to do just that.

In case of a temporary loss of the cloud connection a special offline mode maintains 'business as usual' via Symphony Mesh, and so the Symphony services run locally, with only a few exceptions (e.g. mobile services and some back-office functions like claiming new devices or registering new users).

Symphony Mesh is an autonomous local ‘network’ consisting of the available intelligent IP-based Symphony Door Call devices (e.g. Symphony concerto touchscreen intercoms).

So, if the cloud connection fails, this failover solution sustains Symphony Door Call communication at all times. This includes, for example, direct audio/video Intercom communication between the main entrance point and individual tenants inside the building.

In the end, all these high-availability measures serve one ultimate purpose: ensuring that - unlike in a symphony concert performance - there is pure Commend Symphony performance without any interruptions.

This concludes our miniseries on Symphony IT Security. Of course, we have not even begun to scratch the surface of this massive topic. So, far from abandoning the world of cyber security, “we’ll be back” to touch on some further aspects of “high availability” in future posts.

In our next post we’ll be looking at ways of allowing legacy Intercom systems to harness the power of latest-generation Commend Symphony cloud services.

If you would like to find out more about Commend Symphony’s features, functions and benefits, feel free to look up more content on the Symphony website  or contact your local Commend provider.