For about a year I have been meaning to write a long-form blog post about my career advice for ICs Twitter thread… and it still hasn’t happened. 😄 I still get asked about this thread and receive comments on it quite a bit, so in the interest of making it easier to find I created this Medium post which simply links to it!
I also spoke about this thread/topic in two podcast episodes which I recommend listening to for more color:
Today we are thrilled to announce the initial OSS preview release of Envoy Mobile, an iOS and Android client network library that brings the power of Envoy Proxy to mobile platforms. This is the beginning of a journey that we hope mobile developers around the industry will join us on.
When Lyft originally announced Envoy in 2016, the project goal was simply stated as:
The network should be transparent to applications. When network and application problems do occur, it should be easy to determine the source of the problem.
I’ve increasingly noticed a disturbing trend in software engineering: the idea that any total program crash (via segmentation fault, panic, null pointer exception, assertion, etc.) is an indication that a piece of software is poorly written and cannot be trusted.
Although it’s true that, in some cases, crashes may be an indication of unreliable software and subpar development methods, crashing is also a valid error handling method that if used correctly can increase rather than decrease the overall quality, reliability, and velocity of a piece of software.
Ultimately, every line of code in a program is a liability that may…
Here we are at the beginning of 2019 and I’m engaged in yet another discussion on the merits (or lack thereof) of keeping all of an organization’s code in a “monorepo.” For those of you not familiar with this concept, the idea behind a monorepo is to store all code in a single version control system (VCS) repository. The alternative, of course, is to store code split into many different VCS repositories, usually on a service/application/library basis. For the purpose of this post I will call the multiple repository solution a “polyrepo.”
I began the day with a very short welcome and brief history of the project. We then had a series of end-user and deep technology-focused talks. The day ended up with a brief road map discussion, followed by a Q&A session with all of the maintainers. I’m not going to highlight any particular talk because honestly, they were all fantastic! …
Today we are thrilled to announce that Envoy has become a CNCF graduated project, joining Kubernetes and Prometheus. The successful graduation demonstrates Envoy has reached a project maturity level that reflects a sustainable open source community, thus making it amenable to widespread enterprise usage.
Envoy began life at Lyft in May, 2015, a time in which the company was struggling to stabilize its rapidly growing microservice distributed architecture. Deployed in production at Lyft since September, 2015, Envoy quickly became an integral building block that allowed for more efficient human and technical scaling of Lyft’s architecture.
Last week, Redis Labs announced a change in how they will license some extensions to the core Redis project (see here and here for more information on the change). This prompted substantial dialog about the efficacy of the new license as it relates to Redis the OSS project as well as Redis Labs (the business trying to generate revenue on top of the OSS).
In response I wrote this Twitter thread:
As I recently wrote on Twitter, I’ve been spending a considerable amount of time lately thinking about the human scalability of “DevOps.” (I use quotes around DevOps because there are varied definitions which I will cover shortly.) I’ve come to the conclusion that while DevOps can work extremely well for small engineering organizations, the practice can lead to considerable human/organizational scaling issues without careful thought and management.
The term DevOps means different things to different people. Before I dive into my thinking on the subject, I think it’s important to be clear about what DevOps means to me.
Warning: This post might make you incredibly angry. On the other hand, it might make you incredibly happy. 😉
I’m not going to spend a huge amount of time in this short post discussing the pros and cons of using exception versus return code based error handling. Much has been written, many arguments have been had, and many relationships have been destroyed.
My personal philosophy on this topic is nuanced. I think the least convoluted code uses both exception and return code based error handling. …
One of the fundamental design tenets of Envoy is eventual consistency, permeating nearly every aspect of the system from the threading model to service and configuration discovery (see also here and here for more info).
As powerful as the eventually consistent paradigm is when applied to SoA networking, I’ve noticed over the last several years that many find it counterintuitive. This is not surprising — eventual consistency makes sense in theory, but when practically applied to many real world problems becomes quickly confusing.