I lead developer relations strategy at Fastly, and I’m currently working on figuring out a more structured way to look at our support for add-ons: libraries, frameworks and integrations that run on top of Fastly.
- observability tools like OpenTelemetry
- application frameworks like Express.js, Next.JS, Nuxt or Remix,
- programming languages (such as TypeScript) that transpile to languages we already support,
- tools you use in your development process like VS Code plugins,
- plugins that run within other platforms and help them integrate with Fastly, like Wordpress, Drupal and Magento.
- modules that perform useful functions within an edge application, like ESI, image transformation, authentication or templating.
Some of these are things we make and maintain, some are third party stuff, but one thing all of these things share is they are not Fastly products and don’t form part of our primary service. Essentially, when you buy Fastly service, you are not buying support for these things. Yet, many people run services on Fastly precisely because these things work really well.
So I’m now looking at all the ways we can show support for these kinds of add-ons, and help customers succeed with them, as well as have the confidence to invest time and money in Fastly knowing that it will work out.
Here are the kinds of support that I’ve come up with so far:
- Kept up to date by Fastly
- Gets fixed if it breaks
- Guarantee that support level won’t fall without formal process
- Example usage provided in docs
- Overview information provided in docs
- Officially recognised within the ecosystem
- Fastly customer support engineers trained to help with it
- Supported in Fiddle
- Public issue tracking for Fastly-maintained components
- Compatible with all native Fastly features
Of course, the more of this support we commit to providing for every thing you might want to use with Fastly, the fewer things we can actually support. So my question is: for the addon/library/framework/plugin that you care about, what do you expect from us? What’s the minimum you would consider as ‘support’?
I love the idea of working towards a shared definition of support in how we integrate with ecosystem tech. This is such a tricky thing to negotiate with any developer tooling because the possibilities are endless and the tech you’re integrating with is essentially beyond your control!
Honestly keeping the stuff the team builds maintained and up to date is all I think I’d expect, and even then there can be very reasonable cases where you can’t justify the resources, perhaps if it’s a legacy integration and isn’t receiving much usage. Beyond that, clear communication about changes in support level are also great, at least then people know about changes they’ll need to respond to. So I think I’d see the first three items on the list as top priority…
Inclusion in learning resources and support is a huge bonus imo, mega helpful but not something I’d expect by default!
Am very curious to hear other takes on this… any comparisions with other dev products might help provide context too. What do you expect when you adopt a product, especially if you use it on the basis of an integration that lets you make best use of it…?
I would like so share some of my personal experience. In past, I used to work on geospatial web applications and many times that ecosystem feels like patchwork. Meaning, we relied heavily on tools without which creating our apps on that platform would have been near impossible. Similar to Fastly Labs some of the best tools were initially experimental built by a company (like Mapbox). Naturally, over the course of months and years some tools got community traction, and some didn’t.
To me support means looking for obvious indicators if a project is active and healthy - “Can I confidently say that this tool will be around long-enough for me use reliably?” All things that you’ve listed in the kinds of support absolutely provide that confidence.
Other signals that influence my decision include:
- Frequency of updates and last update: There may be official docs, but if a library is stale I’ll think twice before considering to use it.
- Maintainers on the project: Are majority of contributions made by single or multiple people?
- Awareness of who is using it: Knowing that there are products/customers using the tool reassures that it will be actively maintained
- Trainings and learning resources: 100% agree with Sue’s comment.
I definitely agree with the motivation here, but having been in the position of supporting things like this in prior roles (including things marked as “Labs”)… in the end these support statements are only a guide, and if a paying customer decides to adopt something that is marked as ‘minimum support’ and then has a problem with it, you’ll end up providing more than ‘minimum’ support
I’m Gustaf, principal engineer from Ingka Digital.
This is not an easy problem…
I think the biggest challenge is around governance and communication. Here I see two parameters:
- A Tech Radar:y categorisation/visualisation, where you communicate for example Adopt/Trial/Assess/Hold
- Supported/maintained by Fastly or Community
Things can change quite quickly in the technology space. It reminds me of this picture:
For example, things based on standards are much more safer bets than new web frameworks.
I would categorise the examples from Andrew like this:
- Open Telemetry (standard) – Fastly
- ESI (standard proposal, existing Varnish capability) – Fastly
- Authentication (based on OAuth, standard) – Fastly
- TypeScript – Fastly
- VS Code plugin – Fastly
- Templating libraries – Community
- Application frameworks – Community
- Plugins – Community
- “Community” would involve both community contributors and Fastly contributors. Investment/involvement/contribution from Fastly is chosen depending on the value/effort/volatility/risk
- Things in Trial could be ok to not have full support, but it needs to be stated what level of support is included and what’s not