Cloud Native Debugging Challenges: From Local to ‘Remocal’
Cloud technologies have yielded a number of positives for software development — a certain ease by tearing down the monolith and letting developers work with smaller, decentralized parts that can be used across multiple applications. In some ways, it creates fewer dependencies. Decentralized and distributed services let developers work on individual microservices rather than working from a single codebase, which helps strip risk to a minimum.
Cloud technologies also enable flexibility that empowers development teams to move faster, test and roll back when something does not work as expected. They also benefit from tighter, faster feedback loops to safely ship software more frequently, with the caveat that the right cultural approach and tools need to be in place to facilitate this flexibility.
Container and cluster management technology like Kubernetes offer standardized orchestration for packaging, deploying and rapidly scaling applications, and everything can be decoupled to create more efficient workflows. However, not every workflow in this new paradigm ends up being as efficient as developers would like.
Cloud Native Complexities: More Microservices, More Headaches
Cloud native development introduces new complexities. In a microservices-based architecture, the number of microservices created can quickly balloon, making it difficult for developers to configure development environments that mirror a realistic setup to detect issues before they end up in production. Scaling container-based application development poses real challenges — only so many microservices can be run locally before blowing up your laptop.
This leads to developers asking for more resources, often in the form of much more powerful hardware, which is expensive and doesn’t solve the problem in the long run. Or they request spinning up pay-as-you-go cloud environments, where cost can escalate quickly and negate the promise of cloud native efficiency.
Neither approach is an effective or long-term solution to the dual need for local development (and fast feedback) with remote Kubernetes clusters and Kubernetes debugging and issue analysis.
Rethinking Remote Debugging
One clear challenge that has been added to the mix is remote debugging. With cloud technologies, debugging applications, which has never been easy regardless of the underlying technology, is remote. And containers and Kubernetes — while adding value and speed to the package, deploy and scale equation — add a layer of difficulty and distance.
The cloud and Kubernetes were supposed to make things faster and possibly easier, so why are troubleshooting problems and debugging so time-consuming and difficult? It’s a fair and common question frustrated developers might ask.
There is a solution. It’s the approach to remote debugging that needs to change, with traditional approaches transforming to make the remote local, or “remocal,” and allowing developers to access cloud services from their local machine. This changes the cloud native game.
Creating the Remote Local Workflow: Go Remocal
A remocal approach guides the way to combining fast feedback from local development and the ability to interact with additional services running on a shared remote Kubernetes development environment. Tools like Telepresence that are built for this task are designed specifically for developers who need to code, test and ship their application into Kubernetes but need to debug locally — and let them do it without changing their workflow.
Maintaining the existing developer workflow is a key concept here. Changing a developer’s workflow without optimizing it can typically lead to decreased developer productivity. For developers, this has repercussions, including having to learn new tools, which takes time, or not having access to the tools in their current workflow, which can be inefficient or require a certain amount of context switching. Ultimately the developer experience takes a hit from a changed developer workflow, especially if the change doesn’t add any value or slows things down.
By extension, these changes lead to a slower feedback loop and slower software releases — again detracting from the purported benefits of cloud native development.
For organizations, this is part of a larger question about supporting the developer experience to get the most value from their existing resources and achieve what cloud adoption promises. In that sense, going remocal is as much an organizational culture and developer experience consideration as it is technical. Organizations need to ask: What tools, practices and patterns will make developers, and the development team overall, most effective and remove barriers to shipping software safely and faster?
Real-World Tools: Telepresence Tackles the Remote-Local Challenge
One example of a tool tackling the remote-local challenge is Telepresence, an open source Cloud Native Computing Foundation (CNCF) project that is custom-built for Kubernetes debugging and local development. Kubernetes developers can code as though their laptop has teleported directly into their Kubernetes cluster.
Telepresence runs locally and forwards requests to and from the remote Kubernetes cluster, which bypasses the biggest speed bump — waiting for containers to build, pushing to a registry and deploying before seeing the effects of a code change.
Exterminate Bugs and Go Remocal from Wherever You Are
The bottom line is: What gets the developer, the team and the organization to frictionless and fast feedback loops and software releases? Take a look at and prioritize the biggest challenges of cloud native development and barriers to achieving safe, fast and frequent releases. This will lead to clearly identifiable solution needs.
Making remote clusters accessible as though they are local, and giving developers the tools to work locally in familiar workflows is one of the key ways to exterminate bugs and accelerate the shipping of software.
