How well do you really know the debugger in your IDE? In this first free module we delve into the hidden features and capabilities within the IDE.
Duration: 93 minutes.
Start
The scientific method that underlies the debugging process...
Duration: 77 minutes.
Start
Use these external tools to get deep insight into your applications, locally and in production.
Duration: 60 minutes.
Start
Learn how to write code that fails in a better way. Code that's easy to debug and fix.
Duration: 53 minutes.
Start
Fixing issues at "Kubernetes Scale" is different. In this module we review the complexities of k8s debugging.
Duration: 32 minutes.
Start
The Problem with Kubernetes (6:06)
Before we reach the debugger and go through the entire process, we need to understand the core problem. A core idea in Kubernetes is that one shouldn't modify container instances. If you do that, you might cause issues as Kubernetes brings up new instances.
Source Debugging in Kubernetes (4:01)
Debugging using the tools we described up until now is great. We can solve many problems using these tools. But they are not debuggers; solving problems deep within the code is hard without debuggers. The best approach is to reproduce the problem without Kubernetes and outside of production, but in some cases, this just isn���t an option.
Kubernetes Configuration Issues (5:29)
We need to understand issues with target containers and what OPS are dealing with every day. If you're lucky enough to have a DevOps engineer on staff, then you probably don't need to know a lot of the problems we discuss here. It's still worthwhile to build some basic knowledge about the problems we can run into with Kubernetes configurations since there's a lot of overlap.
Like many things in software, the benefits of serverless (or Platform as a Service) are great. We can ignore infrastructure complexities and focus on code. Scaling becomes seamless and, when compared to some alternatives: affordable. Performance is also great under the right conditions. Here���s where engineers expect the other shoe, what���s the downside?
Duration: 19 minutes.
Start
Serverless Debugging Introduction (9:48)
Serverless debugging could be viewed as an oxymoron. It���s a managed, deeply controlled, and disconnected environment. We don���t have most of the typical debugging tools at our disposal. The distributed and controlled nature of the environment essentially blocks any chance of remote debugging.
I define fullstack as a process of submitting a pull request that covers all the parts required to implement a feature, backend, database, frontend and configuration. It doesn���t make us an expert in all of these; far from it. It means we work on a vertical feature and enter domains where our knowledge is cursory. This is good, when we have a reviewer who is a domain expert and can guide us through the pitfalls of the domain.
Duration: 42 minutes.
Start
Fullstack Debugging (6:16)
The definition of fullstack is shifting like quicksand to match whatever the observer considers to be the stack. I���ve seen some definitions that include OPS aspects into the mix. A more common definition follows the process of writing both the front end and the backend.
Frontend Logging (8:42)
We discussed logging in the 4th module, but frontend logging is different in many regards. The first big difference is the quality of debugging via printing. As you may recall I���m a big advocate of using tracepoints instead of logging. Tracepoints are still superior to print statements in most regards, but in front end programming the difference isn���t as pronounced.
Frontend Networking and Storage (4:45)
In the 3rd module we discussed Wireshark, which is an amazing tool for observing network traffic. The tools within the browser exceed it for most common use cases and make debugging network performance and bugs stupid simple. Many problems express themselves in the frontend, either via the console or the network monitor. I���ll skip the discussion of performance, since that is a subject so big it warrants its own book. In this case I want to highlight tricks for debugging using these network consoles.
These tools provide actionable insight into our production systems. This isn���t a new idea, but with the rising complexity we have due to containerization, orchestration, and microservices, these tools have become essential. It���s rare to find a modern deployment that doesn���t use several such tools. Tool vendors focus their sales, marketing, functionality and documentation on the DevOps market which makes the tools less ���actionable��� to the developer community.
Duration: 45 minutes.
Start
Observability (5:33)
If you search the web for the definition of monitoring and observability, you���ll end up with almost as many definitions as there are results. Before we go into the nitty gritty of textbook definitions, I���d like to focus on why we need these things at all. What purpose do they serve?
Prometheus (5:47)
Since its release in 2012, it has become the de-facto standard for many monitoring needs. As a result, it became the second hosted Cloud Native Computing Foundation project after Kubernetes itself. The ubiquity, portability, simplicity and performance of Prometheus keep it a popular option even a decade after its release.
Grafana and OpenTelemetry (7:32)
If you search the web for the definition of monitoring and observability, you���ll end up with almost as many definitions as there are results. Before we go into the nitty gritty of textbook definitions, I���d like to focus on why we need these things at all. What purpose do they serve?
Culture of Observability (9:09)
Up until now this module covered a small set of tools that we have at our disposal as engineers. At the very least, the tools we can request from the DevOps team. If I just list all the tools available with a short blurb, this might become the longest and least interesting module. There are many tools. They often have merit, value, and necessity. This is a rapidly evolving field, and even if we dedicated the entire course just to these tools and their capabilities, we might run out of space.
Developer Observability (12:15)
If you search the web for the definition of monitoring and observability, you���ll end up with almost as many definitions as there are results. Before we go into the nitty gritty of textbook definitions, I���d like to focus on why we need these things at all. What purpose do they serve?