We will focus on comparing Airflow and Flyte implementations at Lyft: dive into the architecture and summarize its benefits and drawbacks.

Lyft moves people through space and time. But where those people move, and why, is up to them. Lyft’s riders use our services to get to and from work, go out to dinner, visit family, and get to the airport. When and where they do so tells us a lot about urban mobility — whether and how the notions of neighborhood, geography, and landscape shape how people move through space.

Here we share what we can learn from long-run patterns on Lyft’s operations in major US cities. We see that cities vary a lot internally in how people travel, where, and when. That diversity implies a need for a diverse range of products and services. But, strikingly, we also see how cities resemble each other — that sometimes, common patterns, like urban downtowns, look more like other cities’ downtowns than they do their companion suburbs.

This is the fourth and final post in the series on how we scaled our development practices at Lyft in the face of an ever-increasing number of developers and services.

Vulnerability management is important, but can be incredibly time consuming. We have to scan our systems and then fix the vulnerabilities that we’ve discovered. In a large software engineering organization this becomes more challenging — service owners are responsible for fixing vulnerabilities in their systems along with all their other work, and security has to track this work, nudge engineers to actually fix things, and report to CISO/compliance/etc. Fortunately much of this work lends itself to automation, letting security engineers focus on understanding and fixing vulnerabilities! In this post we’ll focus specifically on web vulnerabilities, and some of the fun automation challenges this process poses.

This is the third post in the series on how we scaled our development practices at Lyft in the face of an ever-increasing number of developers and services.

In our previous post, we described our laptop development workflow designed for fast iteration of local services. In this post, we’ll detail our solution for safe and isolated end-to-end (E2E) testing in staging: our pre-production shared environment. We’ll briefly recap the issues that led us to this form of testing before diving deeper into implementation details.

Our journey to scale incentive campaigns to unlock high experiment velocity for Growth.

This is the second post in the series on how we scaled our development practices at Lyft in the face of an ever-increasing number of developers and services.

This post will focus on how we brought a great development experience right to the laptop to allow for super fast iteration.

Late in 2018, Lyft engineering completed decomposing our original PHP monolith into a collection of Python and Go microservices. A few years down the road, microservices had been largely successful in allowing teams to operate and ship services independently of one another. Separation of concerns that microservices brought about enabled us to experiment and deliver features faster–deploying hundreds of times each day–and provided us with the flexibility to use different programming languages where they work best, have stricter or looser requirements based on service criticality, and much more. However, as the number of engineers, services, and tests all increased, our development tooling struggled to keep up with an explosion of microservices, eroding much of the productivity gains we had strived for.

This four-part series will walk through the development environments that served Lyft’s engineering team as it grew from 100 engineers and a handful of services to 1000+ engineers and hundreds of services. We’ll discuss the scaling challenges that caused us to pivot away from most of those environments, as well as a testing approach based predominantly on heavy integration tests (often approaching end-to-end), in favor of a local-first approach centered on testing components in isolation.

• Part One: History of development and test environments (this post)
• Part Two: Optimizing for fast local development
• Part Three: Extending the service mesh in staging with overrides
• Part Four: Gating deployments with automated acceptance tests

In Q2 of 2021, Lyft served 17.1 million active riders through our suite of mobile applications. At this scale, every crash, frozen frame, or hiccup can translate to thousands of hours of wasted time and frustration. Given the potential to impact millions of Lyft’s customers, we doubled our efforts in 2020 to improve our applications’ speed and stability by launching an internal mobile performance initiative.

This is the first in a series of stories detailing our journey to materially improve the speed and stability of our applications. We hope that this can be used by other companies as a reference and inspiration for their own investments in this space.

In this post, we will explore both how and why we started investing in mobile performance at Lyft, and we will dig into our team’s philosophy — everything from how we select projects to how we evaluate success.

How we built at Lyft a gradient boosted tree package to predict travel time more accurately.

One of the Security Team’s projects this year has been to make it easy to generate reports and dashboards from Cartography, Lyft’s security intelligence graph. Cartography links together various entities like compute, permissions, Github repositories, users, etc. and has powerful query capabilities, but it does not integrate with our analytics tools out of the box. To remedy this we’ve leveraged Lyft’s data infrastructure to build an ETL solution that extracts data from Cartography and transforms it into something that can be consumed by our analytics tools. Our solution improves on older approaches by being both significantly easier to work with and more powerful.

The Android engineering team at Lyft exclusively uses IntelliJ to develop new Android features (Android Studio is on the horizon, but that’s for another article). The IntelliJ platform offers a powerful SDK that enables developers to build plugins that enrich the IDE’s feature set, and a few years ago the team decided to take advantage of this SDK by building a plugin.

How Lyft improves on device location tracking with map data.

即使是一个精心制作的交接文件也不能取代你与开发之间良好的语言交流。这应该与开始、移交和书面文档一起使用。你越让开发了解你的设计，还原的结果就越接近实际发布的产品。

A/B tests, controlled experiments to measure performance differences between groups, are ubiquitous tools in data science and represent the gold standard in business measurement. At Lyft, A/B tests are found in nearly every product, from measuring the performance of marketplace algorithms and app designs, to engineering infrastructure changes. The units of analysis for most A/B tests are users, and sometimes markets or times of day. In this post, we are going to describe a new type of A/B test we are performing on our hardware team at Lyft. We will also illustrate a couple of A/B tests which we have done to safely and confidently improve the user experience, lower costs, and provide the best possible service for the cities in which we operate.

在之前的一篇博文中，我们讨论了Feature Service的架构，它在Lyft管理机器学习（ML）的特征存储和访问。在这篇文章中，我们将讨论LyftLearn的架构，这是一个建立在Kubernetes上的系统，负责管理ML模型训练以及批量预测。