1. What are four keys for great DevOps? Collaboration: DevOps requires collaboration, both within teams and between teams. Good communication between teams implies to break down silos, which can be harder than it sounds in organizations where a leader and their team are rewarded for individual achievements, discouraging them from collaborating and sharing information with others, and often encouraging politics at the expense of the company’s success. Blameless Culture: It also requires to internalize that we learn from our failures.

Ardan Labs (a leader in building Go enterprise software) is excited to announce that we have partnered with Light Code Labs and Matt Holt to bring Caddy into the Ardan Labs family of products and services. Caddy is a lightweight ingress service written in Go that provides automated security features and a plugin environment for extensibility. With the service being free open source (FOSS), small and large Go engineering teams finally have the ability to own and maintain their ingress and load balancing software with ease.

Prelude This is the third post in a three part series that will provide an understanding of the mechanics and semantics behind the garbage collector in Go. This post focuses on how the GC paces itself. Index of the three part series: Garbage Collection In Go : Part I - Semantics Garbage Collection In Go : Part II - GC Traces Garbage Collection In Go : Part III - GC Pacing Introduction In the second post, I showed you the behavior of the garbage collector and how to use the tooling to see the latencies that the collector inflicts on your running application.

“Once a language gets complex enough, programming in it is more like carving out a subset from an infinite sea of features, most of which we’ll never learn. Once a language feels infinite, the costs of adding further features to it are no longer apparent". - [Mark Miller] (https://medium.com/@erights/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9) The new try proposal is an addition to the language that introduces a second mechanic to handle errors. It is being introduced in response to data gathered from the 2018 Go Survey and a review of proposals that were submitted during the Go 2 proposal process.

Prelude This is the second post in a three part series that will provide an understanding of the mechanics and semantics behind the garbage collector in Go. This post focuses on how to generate GC traces and interpret them. Index of the three part series: Garbage Collection In Go : Part I - Semantics Garbage Collection In Go : Part II - GC Traces Garbage Collection In Go : Part III - GC Pacing Introduction In the first post, I took the time to describe the behavior of the garbage collector and show the latencies that the collector inflicts on your running application.

Prelude This is the first post in a three part series that will provide an understanding of the mechanics and semantics behind the garbage collector in Go. This post focuses on the foundation material on the collector’s semantics. Index of the three part series: Garbage Collection In Go : Part I - Semantics Garbage Collection In Go : Part II - GC Traces Garbage Collection In Go : Part III - GC Pacing Introduction Garbage collectors have the responsibility of tracking heap memory allocations, freeing up allocations that are no longer needed, and keeping allocations that are still in-use.

One of the traps of concurrency is “incomplete work” which occurs when a program terminates before outstanding Goroutines complete. Depending on the program, this may be a serious problem. This post demonstrates the trap and discusses possible solutions.

Integration tests give insights to the end-to-end operation of web services. In part 1 of this 2 part series over integration testing in Go we explore how to run integration tests in restrictive environments, such as Jenkins.

Goroutine Leaks are a common cause of memory leaks in Go programs. In my previous post, I presented an introduction to Goroutine leaks and provided one example of a common mistake that many Go developers make. Continuing that work, this post presents another scenario on how Goroutines could be leaked.

Prelude This is the third post in a three part series that will provide an understanding of the mechanics and semantics behind the scheduler in Go. This post focuses on concurrency. Index of the three part series: Scheduling In Go : Part I - OS Scheduler Scheduling In Go : Part II - Go Scheduler Scheduling In Go : Part III - Concurrency Introduction When I’m solving a problem, especially if it’s a new problem, I don’t initially think about whether concurrency is a good fit or not.