Download to read offline
Uploaded byKamyar Mohager
Foundations of a Successful Developer Platform - DeveloperWeek 2015
This document discusses key considerations for building a successful developer platform. It covers platform strategy, API architecture and development, documentation and support, and monitoring and operability. For platform strategy, it recommends defining the platform's value and determining who it targets. For APIs, it suggests consuming internal APIs externally and treating APIs as products. For documentation, it advises decreasing time to first API call through clear documentation. And for monitoring, it stresses the importance of monitoring platform health internally and externally.
More Related Content
Similar to Foundations of a Successful Developer Platform - DeveloperWeek 2015
![Always Mind Your [Developer] Surroundings - API City 2018](https://cdn.slidesharecdn.com/ss_thumbnails/apicity-alwaysmindyourdevelopersurroundings-181004161507-thumbnail.jpg?width=640&height=640&fit=bounds)
Foundations of a Successful Developer Platform - DeveloperWeek 2015
- 1. Foundations of aSuccessful Developer Platform Kamyar Mohager (@kamyarsayshello) Engineering Manager, Partner Engineering LinkedIn
- 3. What We’ll Cover •Platform Strategy • API Architecture & Development • Documentation & Support • Monitoring & Operability
- 4.
- 5. Define what yourplatform offers • How do you define success for your business? • Decide what you want your developers to do in order to contribute to the success of your business • Try to determine this early on but be nimble if your market changes
- 6. Now you candetermine the who of your platform • How do you get your developers to engage? • Best case scenario: Your product already has enough pull on its own to get devs to start building apps • Otherwise… – Business Development team = Partnerships – Evangelism (e.g. Hackathons) = Hackers / Organic Ecosystem
- 7. Lessons Learned @LinkedIn • 2009: – Build it and they will come! – Let “professional apps” flourish; no focus on the what and the who of our platform • 2015 – Primary focus on partnerships that align with LinkedIn’s product and business goals – Continue to support broader developer community but give more guidance on use cases that our platform supports – Bloomed new partnerships and use cases beyond supporting “professional apps”
- 8.
- 9. Eating Your OwnDog Food Write API Once Practice What You Preach I’m not only the Hair Club president; I’m also a client No matter how you say it, ideally you should consume the same APIs internally as you expose externally
- 10. Lessons Learned @LinkedIn • Domain knowledge belongs to product teams, not platform team • Difficult to maintain a platform codebase separate from the core stack – Getting buy-in from other teams to maintain their APIs was critical • A growing disparity between what the core LinkedIn products offered and what our platform offered
- 11. Some Challenges toConsider • Your API Gateway should be configurable to modify access control for external vs internal consumption • API management tool – Build vs Buy?
- 12. Treat Your APIas a Product • Write the API doc before building the API • Gain valuable insights and developer feedback • This influences both API development and the product itself • Letting your developers sandbox the APIs while still in development = faster iterations
- 13.
- 14. Goal: Decrease Timeto First API Call • Regardless of how well your APIs are designed, poor docs discourage developers • Focus on decreasing time to first API call with clear & concise documentation
- 15. Clear Communication OnThe Do’s and Don’ts • Communicate supported use cases clearly in context of the API documentation • Provide a separate FAQ if necessary • Write your Terms of Use clearly to avoid any confusion on what is/isn’t supported – Developer empathy: wasted time, annoyance, anger b/c of confusion on unsupported use cases – Try to avoid too much legalese if you can
- 16. SDKs and Libraries •Pros: – Easily handle authentication and API requests – Especially important for mobile developers if you’re implementing web-based auth (OAuth) • Cons: – Engineering investment is costly – Harder to maintain the more languages/frameworks you support
- 17. Giving Developers theSupport They Need • Provide channels of support for your developers – Developer forums – Stack Overflow – Support Ticketing Systems • Clearly define your support SLAs to set expectations • If you have an open platform, be prepared for a wide variety of technical questions • Staff your team appropriately to answer these questions on a timely manner
- 18. LinkedIn Developer Support •Open developers: Stack Overflow • Partners: Zendesk • Our partner engineers cover all support channels • SLAs vary
- 19.
- 20. Always Have aPulse On Your Platform • Internally: Always have the operational metrics and instrumentation on the health of your APIs. Know when your APIs are down before developers do • Internally: Be able to solve the key business questions of your platform • Externally: If possible, provide some level of monitoring / alerting to developers so they’re not left in the dark
- 21. Twitter – APIHealth (external facing)
- 22. Partner Monitoring Dashboards •We can monitor by: – API Endpoint – Application – Partner Program (set of applications) • Alerted of any issues based on a given dashboard • Optionally have our NOC alerted when necessary
- 23.
- 24. InSummary • Strategic decisionshave a lasting impact • Treat Your API as a Product • Developer communication is critical • Platform uptime and monitoring is a priority • Remember to always be nimble
- 25. Kamyar Mohager (@kamyarsayshello) EngineeringManager, Partner Engineering LinkedIn THANKS!
Editor's Notes
- #6 Determine the “what” of your platform. Decide on what you want your developers want to do that will equal success for your business Increased engagement? User growth? Increased revenue? This will influence your overall strategy. Do you build an open platform to let developer “run free”, hoping an organic ecosystem will flourish? Are you only focused on enterprise partners? Big name consumers? Determine this early on but be nimble if your market changes
- #7 * Best case scenario is your product already has enough pull on its own to get developers to start building applications. * Do you go out and hire a business development team? Do you run hackathons in hopes developers will come? Knowing your developer audience will help influence these decisions
- #8 Through trial and error we realized supporting strategic partnerships on our platform added the most value to our company while continuing to support open developer community. Evolved to figure out what’s accretive to our overall business. This led to structured partner programs. That also brought us to the realization of use cases that we weren’t supporting. That made us much clearer with our communication with our developers Bloomed different partnerships – drove new APIs developed and we have a platform that have apps that are much more beyond “professional apps”
- #10 Advantage: Needing to maintain and QA just one codebase (if it fails for the desktop, it fails for all external applications). Advantage: Helps attain parity between your developer platform and core stack Design perspective: If an internal developer won’t integrate, then an external developer certainly won’t
- #11 We were RPC based so we ended up building our own RESTful APIs. In the beginning this worked since the Platform team owned and maintained these RESTful APIs. Over time, since the team lacked domain knowledge of these APIs (e.g. profile api) we had other teams assume ownership of their respective APIs. Disparity between API and core products Lesson learned: SOA architecture would have solved these problems
- #12 *Internal consumption != excuse to cut corners on design It’s not only your coworker using the API, but also an important strategic partner to your business
- #13 We borrowed the “working backwards” approach from Amazon -> write your blog post first Example at LI: For Sponsored Updates we wrote our dev workflow and documentation first and shared with developers to get feedback - By doing this first we better determined from the customer’s standpoint whether what we were about to build had value
- #15 * You’re lucky if your product is fantastic enough to keep developers coming back regardless of bad docs. Most of the time, they won’t come back. Your docs are your best chance to attract developers, so make it good the first time How long does it take from the time your developers first start reading your docs, provision an API key, then make their first API call? Focus on decreasing that time spent by writing clear, concise documentation
- #16 Be really clear on what they can and can’t do within context of the API documentation itself; have a FAQ; at the end of the day we still need a legal doc to address the few bad apples in a ToS
- #17 If you do decide to build your own SDKs/Libraries, try to decouple them from your API interfaces as much as possible
- #18 Establishing SLAs clearly for your developers will set expectations. Figure out what the right channels are for support If you have a mostly open platform, you most likely need to provide a developer forum to compliment your developer portal Large enough platforms can rely on Stack Overflow
- #21 Business metric to answer key business questions: Eg. Which application POSTs shares to LinkedIn the most?
- #23 Alerts by Application throttling 4xx/5xx errors 0 QPS
- #24 We can measure requests per second to our platform, in addition to downstream dependencies. This also helps with downstream capacity planning (fanouts) Leveraging Apache Kafka as pub/sub messaging system All messages of a specific topic (platform) are consumed by monitoring system Messages also ETL’d to HDFS for offline data reports; provides developer relations with insights on API usage
- #25 While not meant to be exhaustive, my hope is that I’ve covered the foundational concepts of what makes your developer platform successful