Cloud computing is all the rage. Yes, the simplicity, agility, and scalability of the cloud are the driving forces of the digital transformation many companies are undergoing. Struggling with a remote workforce in the aftermath of COVID-19 only pushed this trend, with Gartner estimating that public cloud spending will reach over $360 Billion by 2022. But this does not mean that on-premises workloads are going away any time soon. Many applications are natively on-premises, and there is even a swing back with many services being repatriated from the cloud back to on-premises infrastructure. It seems like there’s a 12-lane highway between cloud and on-prem with workloads moving in both directions. So, on-prem is here to stay. The problem is that on-premises deployments create hurdles when something goes wrong. The difficulty of accessing your customer’s infrastructure makes incident resolution in production a painstaking game of trial and error. But there’s hope in sight.
The reasons for going on-prem
Here are some of the reasons companies remain on-prem:
Security: There’s an ongoing debate about the security of the public cloud compared to an on-premises private cloud. Many are opting for on-prem, especially in sensitive industries like finance, military, and health care.
Regulatory compliance: While the public cloud sports many certifications, not all clouds can satisfy all industries. The ultimate responsibility for data privacy and governance remains with you, and the cloud cannot always accommodate you with enough availability regions or account for human error.
Cost: The pay-per-use model with zero CapEx of the public cloud is appealing for many companies moving in that direction. They quickly realize that just lifting and shifting workloads to the cloud does not bring the cost benefits that the cloud promises and find themselves with a cloud hangover.
Edge computing: The number of connected devices we use is exploding, from smart cars to business analytics to automated factories. With more and more data being created by devices, there is a growing need to analyze that data at on-prem data centers near the compute edge.
Resolving incidents on-premises usually means a lot of customer friction
With so many companies keeping or moving their workloads on-prem, it’s likely that at least some of your customers will run your software at their on-prem data centers.
And then your support team gets that call.
Something’s not working right with your software, and your customer wants an urgent fix.
If your customer is willing to give you access to their servers on which your software is running, you can go about your investigation, but that’s not usually the case, especially in sensitive industries. So, you ask your customer to send you logs since you don’t have much else to go on. You try and figure out what went wrong and add more logs to validate your theory, but now you have to reproduce the error with the new logs. You send your customer a hotfix and ask them to deploy it to their production environment. This process causes a lot of friction with your customer. It requires a great deal of their time and interaction, not to mention unplanned deployments to production, which may take days to happen. Worse, you rarely get it right the first time and will have to go through several iterations like this with your customer. More time, more aggravation. By the time you really figure out the problem, you’ve lost quite a bit of trust, and your customer’s upcoming license renewal may be very shaky.
The frictionless approach to on-premises live incident resolution
Ozcode supports on-premises installations. That means you can deploy the Ozcode agent alongside your customer’s software and install the Ozcode server at your customer’s site. If your customer’s site is truly air-gapped, you’ll have to log on to your favorite travel site, book your ticket and a hotel, and get on a plane. If you’re lucky, you might be able to drive there. Without the ability to create a connection to the world outside the customer’s network, there’s no other option. That’s why Ozcode is adding a “technician mode” to its Live Debugger in which anyone who has access to the Ozcode server on site will be able to export exception captures and tracepoint sessions with a single click of a button so your engineers can import them to your local Ozcode installation and time-travel debug in the comfort of their own desks.
This approach to resolving incidents in production related to your software on-premises will go much more smoothly with your customer. There are no repeated hotfixes to deploy just to get more logs and no downtime. Your engineers don’t have to reproduce the issue; they can just play back the autonomous exception capture to analyze, and time-travel debug it. And if they need more logs, no problem. They can use tracepoints to add dynamic logs wherever they need to in the code – no need to redeploy. The bottom line is that you’ll solve that gnarly bug much more quickly without rubbing your customer the wrong way.