Postman – the contract between operations and engineering at Coursera
Coursera is an education platform that partners with top universities and organizations worldwide, to offer courses online for anyone to take. With a mission to provide universal access to the world’s best education, the company pioneered the concept of MOOCs (massive open online courses) in early 2012. Today they support 17+ million learners, 1700+ courses and over 140+ partners from across the globe.
Coursera’s platform caters to 2 sets of users – learners and university partners. While the learners get to pick courses spanning different domains, the partners seed the ecosystem with fresh course content. Internally, Coursera has dedicated engineering teams attached to these sets of users, building up the product in a service-oriented architecture. Every product feature built for the learner side has a corresponding administration feature on the partner side. Due to early investment in their developer ecosystem, they lowered the barrier to easily bring up new services and corresponding REST APIs (modeled using open-source schema language Courier) to communicate amongst themselves. This has resulted in a massive proliferation of 100s of APIs.
With a strong focus on “learner’s first”, Coursera in 2015 went through a massive growth phase and transformed their learner side product based on user feedback. While the corresponding self-serve partner side product was being built, this pace of innovation required a dedicated operations team to help partners quickly on-board new content onto the fast moving learner product. This situation, according to Roshan Sumbaly – engineering lead at Coursera, felt like the Zeno’s paradox, as there was always catch up to play on features on the partner side. The operations team had to request engineers to manually help update the content everytime partners wanted to change or add something to their courses. If not addressed quickly, these interrupts could have resulted in a massive productivity drop for the engineers.
Coursera was quick to adopt Postman and generate collections for critical end-points early in the development phase. Postman’s easy to use GUI made it a perfect tool for operations team – who could then, with minimal knowledge of the internals of REST, use these collections to get their job done. This empowered the operations team to support partners, breaking the tight coupling with engineering. Engineers could liberally share the set of well-documented end-points that were guarded by validation and internal-only auth rules. As these collections are defined fairly early in the development cycle, it is also being adopted as the agreement between front-end and back-end developers.
Just as APIs were initially the exclusive domain of developers, Postman’s initial audience was developers. However, with these new use cases like at Coursera, we are seeing adoption across teams in organizations big and small. Accessible APIs empower entire companies to operate efficiently and we urge everyone to move to an API based workflow system. And anyone who can benefit from APIs, can benefit from Postman.
In the words of Roshan Sumbaly, “Postman became the contract between operations and engineering.”
Are you utilizing Postman in some unique way? We’d love to hear from you.
