These days, containerization is a trendy issue in the tech industry. Although it’s been around for some time, it’s only recently become a prominent trend. You can use Docker or Kubernetes—or even both—to work with containers. Each has its own set of advantages and disadvantages. But which technology is better for which types of projects? To clarify, let’s look at some ways to understand the differences between Docker and Kubernetes.
.NET 5 is a shifting point for the .NET ecosystem, bringing Mono, Xamarin, and .NET development into a single codebase. Almost a year later, however, there’s still some confusion lingering, especially when it comes to migrating your old apps.
The allure of quickly spinning up an app on a platform as a service (PaaS), as opposed to cobbling together a solution on an infrastructure as a service (IaaS), makes Heroku an appealing option for many developers. With the explosive growth in the platform as a service market, new features and capabilities are continually rolling out. Along with the fast-paced evolution of Heroku comes an increase in complexity, which can create challenges for application developers.
There are many methods to help you avoid bugs in your application. You can use linters, write tests, or use an IDE, which will help you spot bugs early in the coding phase. However, no matter how good you are at preventing bugs, they will always happen. And it may not have anything to do with you. You could get hit by a bug in the third-party library you use. Therefore, as important as bug prevention is, it’s also crucial to know the debugging process well.
Syslog is a standard for collecting, routing, and storing log messages. It emerged from the Sendmail project in the 1980s. In 2001, it was standardized as RFC 3164 and then as RFC 5424 in 2009. It’s supported on several different platforms, including Unix/Linux, BSD Unix, macOS, and network devices like printers and routers. Because of the remote syslog capability, the standard has lasted several decades.
Container logging adds some complexities we don’t experience when using VMs or dedicated hardware. With containers, once the container dies, the logs and data for the container also die. This may not be a problem for small applications with little logging. But for more complex applications or applications running in production, you need to start thinking about log persistence and management.
Let’s paint a picture. You’re a developer working on a system broken down into multiple services. These services do their one thing well and all communicate. However, it’s 3 a.m., and you get a call from your boss telling you something’s wrong. People can’t complete the tasks they’re supposed to complete, and there are errors on the webpages they’re using. You’re the first responder and need to figure out what’s going on.
A good application usually has some sort of logging to provide clues when something goes wrong. When it doesn’t, I have to spend time making sure I can get some basic information logged when an issue occurs. In those cases, I used to write files in /var/log for every application or scheduled task. But I came to a point where there were too many files to review when I had to troubleshoot. To simplify troubleshooting, I decided to change my approach to an easier and more convenient system. This post describes what I came up with.
As you automate tasks with PowerShell, those tasks start to become more complex. As a result, logs become larger. Take a look at this huge log that was output from executing commands in PowerShell:
Local Kubernetes clusters are great for both developers and system engineers. When developing applications, programmers can use local clusters to make sure their application can be easily and correctly deployed without the need for configuring real infrastructure. System engineers can use them for testing, creating proofs of concept (POCs), or learning and trying new tools.