FFaaS (Feature Flagging as a Service)

How we wrote a feature flagging service in Node.js at Condé Nast.

Transcript

1. FFaaS Feature Flagging as a Service // Eric Weinstein // EnterpriseJS // Condé Nast // 15 December 2015
2. Part 0: Hello
3. About Me const ericWeinstein = { employer: 'Condé Nast', gitHub: 'ericqweinstein', twitter: 'ericqweinstein', website: 'ericweinste.in' };
4. Flaggregator • What is feature flagging & why do we need it? • Why a full-fledged, RESTful service? • Why Node.js? • What tools did we use? • What did we learn?
5. Part 1: Why
6. { "_id": "561c6b93f96475d979402ab5", "author": "omontalvo", "expiry": "2038-01-19T03:14:07Z", "modified": "2015-09-01T14:30:00Z", "name": "konami", "environments": { "ci": { "enabled": true }, "stag": { "enabled": true }, "prod": { "enabled": false } } }
7. What is Feature Flagging? A technique that allows software teams to control application behavior independently of deploys; you can continually ship partially finished features that are flagged "off" and only activate them when they're ready for prime time.
8. Why? (Cont’d) Experimental features can also be flagged on or off based on time of day, user role, and so on. Feature flagging allows an organization to practice continuous delivery, which means shorter release cycles that help ensure code is ready to ship at any time.
9. Why a Service? A service offers flexibility and scalability (at the cost of latency and complexity). Let’s talk about some options we didn’t go with.
10. Why Not a File? • Requires a deploy and process restart • Doesn't allow multiple projects to share flags (without duplicating configuration) • Not easy to sync across machines/environments • Doesn't allow us to schedule flags • Generally requires an engineer to make the modification
11. { "name": "konami", "environments": { "ci": { "enabled": true }, "stag": { "enabled": true }, "prod": { "enabled": false } } }
12. Why Not Just NGINX? • Great at serving static files, which is why it's the upstream proxy • Doesn't handle flag persistence (the datastore consists of a file on the local filesystem) • Doesn't provide a framework for flag creation, modification, and deletion (letting people munge flags by hand means a critical human error is simply a matter of time) • Generally requires an engineer to make the modification
13. { "name": "konami", "environments": { "ci": { "enabled": true }, "stag": { "enabled": true }, "production": { "enabled": false } } }
14. Why Node? • Condé Nast has bet big on JavaScript and Node • Maximum number of developers can understand and contribute • Large pool of developers from which to hire • Shared code (e.g. Flaggregator is using a homegrown tool used for our CMS services for API auth in production) • Evented I/O makes sense for a feature-flagging service
15. We’re Hiring!
16. Why Mongo? • MongoDB stores documents as JSON (well, BSON), and JavaScript speaks JSON • The feature flag schema is still in flux, and since Mongo is schema-less, continually modifying the schema is relatively painless (for now) • Feature flags actually do make sense to store as documents (at least for now)
17. Part 2: How
18. The Process • Focus on developing a minimum viable product (MVP) • The tech: Babel, Flow, Node • Write the README first • Develop routes with fake responses, iterate on API • TDD models (e.g. early win with Mongoose/Mockgoose) • Red, green, refactor
19. RoBoT README-driven development Behavior-driven development (Cucumber) Test-driven development (Jasmine)
20. So Far, So Good
21. Part 3: What
22. What We’re Getting • Coordinated deploys • Faster feature/development velocity • develop branch is always in a deployable state • Faster deploys
23. TL;DR • Feature flagging enables faster, smoother, continuous delivery • A RESTful service has some overhead but scales very well • Modern JS (Node, ES6, Flow) is great • Open-sourcing soon!
25. Questions? eric_weinstein@condenast.com github.com/ericqweinstein @ericqweinstein