Q&A: Microservices on the edge

Component-Edge6.jpeg

Moving towards the edge comes with its benefits—and challenges. Jeyappragash Jeyakeerthi, a co-founder of service mesh company Tetrate who goes by JJ, discusses the advantages of computing at or near data sources, important steps to overcome issues when managing software development and IT operations on edge devices, and his advice for edge deployments.

Give a brief summary of Tetrate and what your company does.

Tetrate enables a safe and fast app modernization journey for enterprises. Built on top of Envoy and Istio, our flagship product, Tetrate Service Bridge, provides a modern service mesh platform that connects any workload from edge to cloud to datacenter. Customers get consistent baked-in observability, runtime security, and traffic management—for all their workloads, in any environment. In addition to the technology, Tetrate offers a world-class team that leads the open Envoy and Istio projects, and provides best practices and playbooks that enterprises can use to modernize their people and processes.

How do you see the DevOps field evolving as more compute power and applications move toward the edge?

It’s not generally about the power of the compute or the distance from the center that changes the dynamics of DevOps. The more important cause behind this shift is the proliferation of the number of applications and services. With edge, application proliferation is particularly high, and this will demand more automation and a more standards-based platform for securing and managing the edge applications. Standards like open telemetry for observability, NIST NGAC for access control security, and other standards around cloud-native are important both for giving confidence to customers and end users and to allow for interoperability with different vendor solutions to avoid lock-ins.

What are some of the unique challenges of managing DevOps on edge devices?

One challenge is lack of easy access to the edge. To address this, it’s important to make sure the install, upgrade, and troubleshooting experience will be as simple and foolproof as possible. This also demands more automation in place.

Second, edge is always compromised on security posture, so providing tight offline security is critical! For edge, it’s especially critical to keep the environment up to date with all the latest security patches. All the data that is handled at the edge should be encrypted both at rest and in transit. It’s also important to rotate keys often, and to push the access logs and audit trail to the central server as frequently as possible. Binaries should be signed and verified on deploy, and shipped often with automatic deployment to the edge.

Finally, the cost of bandwidth can be high, so it’s advisable to keep chattiness to the cloud or datacenter low.

What are some key considerations developers must keep in mind when deploying applications at the edge?

A few tips for edge deployments:

Keep the code small. Store only the data that is needed and delete/sync back when done.

Make sure to have enough instrumentation, with clear details to allow for debuggability. Someone non-technical is going to have to read that information and need to act on it, so developers should have the empathy to communicate that clearly. Also it saves them from getting woken up at 2:00 am.

Don’t make external API service calls. There is no guarantee that a network will be available for the calls to reach out externally.

How do compute and connectivity limitations of edge devices change the way developers must think about their apps and services?

Given the compute and connectivity limitations of edge devices, developers should keep services as stateless as possible; for any critical state, the information should be stored back to the cloud. You want to keep things local, whether it’s data or access to other services. And for edge devices, there’s never enough bandwidth. Wherever possible, send deltas instead of a complete payload. Developers should think about writing apps that have very little dependency on hardware or operating systems. You may not have control over the hardware or OS that’s used at the edge.

Anything else to add?

The considerations mentioned are good practices even for cloud applications. But their importance becomes more acute for edge applications.

Previous
Previous

How Nexar is using AI to improve auto safety

Next
Next

Q&A: Open source on the edge