Real-Time Debugging in Production with Bluemix Live Sync

Detecting production issues

No matter what language is being used or what application is being developed, there’s one thing developers commonly experience. It’s reproducing bugs in production, according to Eugene Melnikov, IoT Engineer at Altoros.

“Sometimes, it’s easier to find aliens in space than investigate an issue in a production environment.” —Eugene Melnikov, Altoros

To identify and reproduce a bug, a developer commonly tries out either of these efforts (or all of them at a time):

• Redeployment. There could be no issue and you just forgot to deploy.
• ENV variables. There could be some missing environment variables.
• Logs. You can check the logs or add more logs if you find nothing.
• Foreign code. There may be issues with transition dependencies or different versions of dependencies in the local and production environments.
• Production database. It could be a data storage issue, so you may try to use the production database.
• SSH. Finally, if the bug still cannot be detected within a local environment, you may connect to production and try reproducing the issue there.

So, it takes a while to find the roots of a problem. Ideally, the process of investigating bugs should be carried out in the environment with same dependencies, buildpacks, and ENV variables.

Prior to the event, Eugene had investigated Facebook and Chromium bug trackers. In his words, it usually takes “up to 3 days to reproduce and assign an issue to an appropriate team. Of course, I understand that there is a queue of issues, but just imagine: 3 day just to reproduce an issue!”

“The ideal investigation process should be in the production environment or really close to it.”
—Eugene Melnikov, Altoros

However, according to Eugene, there is no vital necessity to stub or run something on localhost, while what one really may need is an advanced debugger. At Cloud Foundry Summit 2017, he described how IBM’s Bluemix Live Sync may be used as an alternative to the above-mentioned scenarios.

Live code syncronization

Bluemix Live Sync was designed to aid developers in building and debugging Node.js apps running on the IBM Bluemix platform. The tool enables developers to automatically synchronize the code with a web IDE workspace and deploy it to a running Bluemix app in real time. The in-built debugger allows for reproducing and fixing bugs right in the production deployment.

“When you change the code in the web IDE or your own IDE, it uploads the changes to the workspace,” explained Eugene. If you are satisfied with the result, all the changes can be applied immediately with a click of a button.

As an example, Eugene delivered a story of a customer who had a meeting with an investor in 5 minutes and called for urgent assistance, because his simple web prototype wasn’t working properly. The meeting was eventually cancelled, because redeploymemt would take at least 10 minutes.

Another story involved Eugene looking for a bug all night long—until he found that the issue was with secret keys in the production environment.

With Bluemix Live Sync, the both problems could have been solved much faster. Of course, debugging in production is risky and needs to be carefully covered with tests later on, but when an app is already operating online and some of its functionality gets broken, speed really matters. Or, when you are creating a prototype/POC, this approach may be really handy.

A workflow of Bluemix Live Sync

What makes Bluemix Live Sync work is Eclipse Orion Web IDE behind it; the IDE is integrated into IBM Bluemix Continuous Delivery service. As Eugene noted, the Orion IDE supports a Chrome debugger and also provides a web shell and logs.

The main features of Bluemix Live Sync include Live Edit and Live Debug.

Live Edit allows for introducing changes to a Node.js app and checking if they work in real time—right in the browser. With an app in the Live Edit mode, one is able to shell into the environment and debug the app. There are two major options to establish the debugging process. One uses Live Edit to propagate changes in a cloud-based project workspace to a running application or switches to the Live Edit mode, thus instantly debugging the running app.

With Live Debug, a user can dynamically edit code, insert breakpoints, step through code, restart the runtime, etc. Live Debug includes three major features: application runtime control, debugging via node-inspector, and shell access.

A Node Inspector view

Debugging in practice

Demonstrating a workspace, Eugene enumerated the main features of the editor:

• Hotkeys
• Drag-and-drop file upload
• Split mode to manage multiple files
• Integration with Git
• ESLint directives

Eclipse Orion Web IDE editor view

To get started, one needs to create a toolchain. As Eugene emphasized, you’d better create a custom toolchain rather than use pre-existing ones to avoid having tools that are not going to be exploited.

On creating a toolchain and configuring the deployment, a developer will have the following utilities installed by default:

• Devconsole to restart applications and get access to shell or inspector
• Shell for your container
• Inspector for Node.js
• Proxy/Noproxy enabled by devconsole
• Hc integration with Bluemix Health Center
• Trace for setting up logs

To enable these utilities, an ENV variable needs to be set from the CLI or put into manifest.yml.

Using debugger, developers can redeploy, open or stop the app, check logs, and view the application dashboard. Alternatively, developers have the option to view and fix issues through the web shell. However, before using a shell or a debugger, developers have to enter credentials or provide a one-time passcode, because the sources are secured. The passcode can de generated online on the go.

“Nobody can access your web shell and nobody can debug your application without your permission.” —Eugene Melnikov, Altoros

Different debugging clients are available depending on the Node.js version being used:

• The Node Inspector
• Chrome Developer Tools
• Visual Studio
• JetBrains WebStorm

Eugene pointed out that it was possible to synchronize workspaces without a web IDE previously—by using the Bluemix CLI. However, this functionality was removed with Bluemix’s transition from JazzHub to toolchains. He explained that once this feature gets reintroduced, developers would no longer need a web IDE.

A web shell view

Conclusions

At the end, Eugene summed up the pros and cons of using Bluemix Live Sync for debugging. In addition to being fast and easy to use, the tool allows for debugging right in a production environment without redeploying the app. However, Bluemix Live Sync is currently supported by only two buildpacks: Node.js SDK and Liberty for Java. For other languages, developers will have to create SSH tunnels using the cf ssh command.

What can also cause some inconvenience is the tool’s availability only on the web—in case you prefer to work in a local IDE. However, it seems to be temporary, since the Bluemix team is working on addressing this.

To get started with the product, check out Bluemix Live Sync docs, IBM’s toolchain how-to, and this Orion Web IDE tutorial.

Related video

Related slides

More from CF Summit:

• Top 100 Quotes from Cloud Foundry Summit Silicon Valley 2017
• From Hybrid to Multi-Cloud: Seeking Order Amidst Enterprise IT Chaos
• Which of the New Cloud Foundry Features Save DevOps Time Most?
• Over-Engineering: When Microservices Are Too “Micro”

About the speaker

Eugene Melnikov is a senior software engineer at Altoros. He mainly specializes in Ruby and Ruby-based frameworks, as well as in JavaScript development, including Node.js, jQuery, and AngularJS. Working at Altoros, Eugene has also designed and implemented a variety of SQL and NoSQL database solutions. He recently became engaged in creating data-driven software for IoT applications. Check out Eugene’s GitHub profile.