Hello, everyone! Today, I will discuss the impact of the development cycle's speed on business and the importance of feature flags, as well as how to select the right technology.
DORA (FourKeys) and the Speed of the Development Cycle πββοΈ
Let's begin with the findings from the extensive research program, DevOps Research and Assessment (DORA), run by Google. According to DORA's studies, it's evident that as the speed of the development cycle increases, so does the business value. Isn't this an interesting result for many developers and business owners?
The Need for Trunk-Based Development βΊ¦
To achieve this rapid development cycle, trunk-based development is gaining attention. However, to implement trunk-based development, the technology of feature flags is essential. The reason being, among various factors, feature flags particularly allow the safe and swift release of new features.
As trunk-based development progresses, there's a need to manage new features dynamically using flags to minimize any adverse effects on users. That's where feature flags come into play.
newFeature = true
if (newFeature == true)
provideNewFeature()
else
provideOldFeature()
Choosing a Feature Flag System π
Currently, there are numerous feature flag systems available. Options include our own company's open-source system, "Bucketeer", and the renowned SaaS "LaunchDarkly" among others. When comparing these, the following considerations might come into play:
- Cost: Many services are expensive.
- Operating Environment: Can it be used in diverse environments such as server-side, client-side, mobile apps and the edge?
- Richness of SDKs: Offering SDKs to facilitate implementation by teams.
- Performance: Whether it has low latency (processed at the edge).
Comparison of Feature Flag Vendors in Late 2023 βοΈ
| Vendor | Server SDK | Client SDK | Real-time Update | Edge Processing | Open Feature | Free Tier | Seat/Month | 1000 MAU | 100k MAU | 1M MAU |
|---|---|---|---|---|---|---|---|---|---|---|
| DevCycle | 9 | 6 | β | β | β | 1000 MAU | - | - | $60 | $420 |
| LaunchDarkly | 25 | 12 | β | πΊ | β | β | $16.67/seat | - | Inquiry | Inquiry |
| ConfigCat | 12 | 5 | β | πΊ | β | 10 features | - | - | - | - |
| Split.io | 8 | 9 | β | β | β | 10 seats | $33~ | - | - | Inquiry |
| Optimizely | 7 | 5 | β | πΊ | β | - | - | Inquiry | Inquiry | Inquiry |
| VWO | 7 | 6 | β | β | β | 50k MAU | - | - | $549 | $3563 |
| Statsig | 10 | 9 | β | β | β | 1M Event Count | - | - | - | $150~ / 1M Event Count |
| CloudBees | 9 | 4 | β | β | β | 15 seats | $1325 / 16 seats | - | - | Inquiry |
| Apptimize | 3 | 6 | β | β | β | Inquiry | Inquiry | Inquiry | Inquiry | Inquiry |
| Molasses | 4 | 3 | β | β | β | 1000 MAU | - | - | $200 / 25k MAU | Inquiry |
| Harness | 9 | 7 | β | β | β | 2 seats 25k MAU | $12.5/seat | - | - | Inquiry |
| Firebase Remote Config | 0 | 7 | β | β | β | - | - | - | - | - |
| Growthbook | 7 | 5 | β | β | β | 3 seats | $20/seat | - | - | - |
| AWS Evidently | 13 | 3 | β | β | β | - | - | - | - | $5 / 1M Event Count |
| Bugsnag | 8 | 8 | β | β | β | 1 seat | $65 / 5 seats | Inquiry | Inquiry | Inquiry |
| PostHog | 5 | 7 | β | β | β | Limited Features | - | - | - | $1/10k Downloads |
| Flagsmith | 8 | 4 | β | πΊ | β | 1 seat | $200/5 seats | - | - | $200 / 500k Downloads |
| Unleash | 20 | 11 | β | β | β | OSS Self-host | $80/5 seats | Inquiry | Inquiry | Inquiry |
| Flipt | 5 | 1 | β | β | β | OSS Self-host | - | - | - | - |
| Bucketeer | 2 | 4 | β | β | β | OSS Self-host | - | - | - | - |
| Flargd | 1 | 1 | β | β | β | OSS Self-host | - | - | - | - |
| TwoFlags | 1 | 1 | β | β | β | OSS Self-host | - | - | - | - |
* Each vendor has different billing models and multiple plans, making comparison very challenging. This table is just to get the big picture. Any corrections or updates in the comments are appreciated.
What is the OpenFeature Standard?
It is an open standard for managing feature flags. It defines APIs and provides SDKs without depending on a specific vendor. The goal is to solidify the ecosystem around feature flags. Vendors complying with this standard prevent lock-in, making it easy to switch to another vendor if the need arises.
Impressions After Comparing π§
Recommended SaaS Options:
- DevCycle (Outstanding performance, DX, UX)
- LaunchDarkly (Impressive number of integrations, mature, but also pricey)
- ConfigCat (Simple, affordable)
- Statsig (Attractive pricing model)
Well-maintained Open Source Options:
For companies with the operational capacity to self-host, open-source solutions are a viable choice.
- Unleash (Most momentum among OSS but the SaaS version is pricey)
- FlagSmith (Reasonably priced SaaS version)
- Bucketter (Recently released by our company CyberAgent)
- Flipt (Simple, no SaaS version)
No Longer Maintained Open Source Options:
Both of these OSS options were designed for the Edge architecture based on Cloudflare Workers, but unfortunately, they no longer seem to be maintained.
Google & Amazon Options:
Google Firebase Remote Config
The "forever free" aspect is highly appealing, but due to factors like latency, Developer Experience, and the lack of a server SDKs, it's feature are just too minimal to be recommended. Firebase Time-to-Market is too slow, and Reature Releases is too low. Maybe their DORA metrics are not good, or it just lacks of strong Head of Product?AWS CloudWatch Evidently
The worst. No comment. AWS seems to perpetually lack a good DX for developers. It appears that they don't recognize or continually undervalue the importance of roles other than engineers, such as Product Managers or Designers. Very disappointing. However, AWS has recently acquired Fig, so looks like they're now pursuing an acquisition strategy instead. Let's see how it turns it out, and let's hope they don't ruin Fig, since it's such an useful tool.
Importance of UX and Latency β‘οΈ
With the advent of edge computing, user UX has become even more critical. According to the Doherty Threshold (proposed in year 1982), the response time limit for maintaining user productivity was 400ms (before, that the norm was 2000ms).
However, considering the response speed trends of recent popular and loved by their user apps (like Linear and Cron), user expectations are continuously rising, now probably just below 100ms. In a mature market, this is the most distinguishing factor, also one of the reasons for Google's success.
Achieving this 100ms in a standard feature flag system might be next-to-impossible challenge due to the system's architecture. Some SaaS providers cache on the Edge taking UX in account, but the database and processing aren't typically done on the Edge.
This is where feature flag systems implemented on the Edge come into focus.
Introduction to DevCycle π‘
We found the high-speed feature flag system operating on the cloud edge that we were looking for: DevCycle. The benefits of DevCycle include:
- Latency under 50ms: Rapid response.
- Rich SDK offering: Easy to implement.
- Pricing model: Charged by MAU, yet affordable.
- User-friendly: Intuitive DX and UX.
- Real-time updates: Via SSE.
- Compliance with OpenFeature: Avoids vendor lock-in.
- IDE Extension: With DevCycle's VSCode Extension, there's no need to open the admin console, further boosting development efficiency.
- Edge Flags: Offering the Edge DB feature.
DevCycle's Superior Technical Strategy: Edge First and WASM π
The company behind DevCycle is Taplytics. Since 2014, Taplytics has been developing an A/B testing SaaS of the same name. To improve scalability, latency, DX and focus on Feature Flags, they decided to develop a product called DevCycle. They have adopted an architecture that doest works mostly on the Edge. As of today, Processing is done through Cloudflare Workers, DB through Macrometa, and SSE Pushes via Ably. They have made bold takes for performance such as Edge First and WASM.
To maximize the performance of the cross-platform SDK, most of it has been implemented in WASM (AssemblyScript). However, the Go SDK has been implemented in native Go rather than WebAssembly, as it has demonstrated better multi-threaded performance for special cases. This might change in the future when WASI Threads become a reality).
Moving from Container Runtime to WASM Runtime π’ β ποΈ
Jonathan Norris (CTO of DevCycle) has a hot take "WebAssembly runtimes will replace container-based runtimes by 2030."
In short:
Technical Advantages of WebAssembly
- Strict security model
- Extremely fast startup time
- Scalability at the edge
- Extremely lightweight
- Portability across environments
- Cross-language development
- Performance
Cost Benefits of WebAssembly
- Workloads on edge runtimes such as Cloudflare Workers, Fastly, and Netlify have lower costs than AWS Lambda due to their smaller startup time and binary sizes.
- Edge runtimes can start up in milliseconds, while containerized services like Lambda take longer to start and consume more memory.
- By migrating to these edge runtimes, DevCycle says they have achieved significant cost savings. They are also running large APIs at the edge.
DevCycle Support ππ»ββοΈ
On a side note, even though I haven't become a paid user yet for DevCycle, I had some questions. When I reached out on Discord, I received a direct response also from the Head of Product within a few hours. They also informed me that it's already on their recently published roadmap, which I found impressive due to their swift response.
Prioritizing and Roadmapping with ProductBoard βοΈ
By the way, when I was checking DevCycle's roadmap, I found that they were publicly sharing customer feedback and their roadmap on ProductBoard. I wish all product managers would follow suit. Is your Product Manager still struggling with priority decisions on Excel, Miro, JIRA or Notion...?
Conclusion π
The speed of the development cycle is directly related to the business value. Achieving a faster development cycle requires trunk-based development and the use of feature flags. The introduction of the open standard for feature flags, OpenFeature, helps in preventing vendor lock-in. However, the speed of processing, especially at the Edge, is vital for user experience. And for this, solutions like DevCycle are ideal.
Remember, while technology is definitely essential, the main challenge is cultural transformation. It's not just about introducing new tools or techniques, but about how teams work together and understand the value they deliver.
Recent products like Vercel, Bun, Linear and DevCycle understand the real impact DX has in regard to transforming cultures.
Thank you for reading! If you found this post helpful, please share it with your colleagues and friends!
And as always, feel free to drop any questions or feedback in the comments below.
Top comments (0)