API Development
What are the boundaries of developer responsibility? One of the potential promises of cloud native development and the growing cloud native ecosystem of tools is “full life cycle” ownership for developers. But is this level of responsibility realistic or desirable for every organization and every developer? Does every developer need to be responsible for the full code, ship, run workflow of cloud native application development?
While we've long advocated for the idea that with a developer control plane, an organization can give any developer full ownership, we know, particularly from our experience talking to thought leaders, CTOs, SREs, field engineers, architects, and more, that no one size fits all. The complete complement of tools exists to support empowering developers with full ownership, but much of the software development world isn't built with a "developer-as-owner" mindset.
While we hear a lot about the buzzy nature of cloud native, we don't hear nearly as much about the daily reality for the 99% developer (the majority of developers working today). The 99% developer works in stable production environments with tried-and-tested solutions. Stability is critical, and experimentation with tooling and possibly unfamiliar cloud native environments, all falling under the developer's responsibility, isn't conducive to many organizations' mission-critical work.
July 18, 2021 | 11 min read
Telepresence
Test your code changes quickly and locally with Telepresence and Jenkins
As cloud-native deployments in Kubernetes increase the challenges for safely updating code and delivering changes are compounding. Developing microservices for Kubernetes applications poses a significant challenge for developers. Effectively testing updated microservice code falls into a few options:
Spin up a new K8s cluster: This has several problems: It’s expensive and time consuming. It’s also difficult to isolate specific code changes in this scenario; multiple changes are often grouped together to save time and resources. This can complicate troubleshooting and root cause analysis.
March 31, 2021 | 10 min read
Kubernetes, Microservices
Tutorial: Learn to debug Go microservices locally while testing against dependencies in a remote Kubernetes cluster
Many organizations adopt cloud native development practices with the dream of shipping features faster. Although the technologies and architectures may change when moving to the cloud, the fact that we all still add the occasional bug to our code remains constant. The snag is that many of your existing local debugging tools and practices can’t be used when everything is running in a container or on the cloud.
Easy and efficient debugging is essential to being a productive engineer, but when you have a large number of microservices running in Kubernetes the approach you take to debugging has to change. For one, you typically can’t run all of your dependent services on your local machine. This then opens up the challenges of remote debugging (and the associated fiddling with debug modes and exposing ports correctly). However, there is another way. Telepresence tool enables this path.
March 30, 2021 | 12 min read
Service Mesh
Service Mesh Interface (SMI) is a Kubernetes-native specification under active development. It’s defining a standard set of Kubernetes Custom Resource Definitions (CRDs) and APIs for service meshes. The SMI development process is open, relying on community participation, and the specification itself is publicly available under an Apache 2.0 license.
As stated on the SMI website, “the goal of the SMI API is to provide a common, portable set of service mesh APIs which a Kubernetes user can use in a provider agnostic manner. In this way people can define applications that use service mesh technology without tightly binding to any specific implementation.” SMI doesn’t include a service mesh implementation; it’s solely a specification that service mesh implementations can use.
Without a standard like SMI, every service mesh technology would have completely different APIs. That would make things more complicated and time-consuming for developers and for platform and DevOps teams. Instead of using SMI APIs, developers would have to write their own code to provide equivalent functionality. Integration with other technologies and tools would take more effort, as would changing which service mesh technology an app uses.
March 24, 2021 | 10 min read
API Gateway
Edge Stack API Gateway uses Envoy Proxy as its core L7 routing engine. Envoy Proxy provides a configurable access logging mechanism. Edge Stack uses the default format string for Envoy’s access logs. These access logs provide an extensive amount of information that can be used to troubleshoot issues.
Reading Edge Stack Access Logs
You can read the log file using kubectl logs:
March 22, 2021 | 4 min read
Developer Experience
Developer relations (DevRel) is, as most tech organizations and developers know, a wide-ranging discipline that demands a multidisciplinary approach to achieve its aims – communication and feedback. But what about internal developer advocacy? In this article, we will explore how internal developer advocacy shapes developer experience, makes developers be successful and helps deliver on organizations' goals.
Inside-Out: What is Developer Relations?
Bridging the gap between technology and user adoption, DevRel is hands-on in driving numerous two-way street activities aiming to advance engineering skills and product engineering. DevRel carries the voice of an organization and its products to developers (and by extension, to engineering teams) and collects and shares the voice of the developer community back to the organization to catalyze product improvements. These activities vary but usually include:
March 15, 2021 | 17 min read
