This blog is a collaboration between lead author Quinn Snyder, Developer Advocate, Cisco DevReland Ravi Balakrishnan,Senior Marketing Manager.

Within the Developer Relations ecosystem, a lot of focus (both in terms of creation, as well as discussion with others) is on the content that allows people to explore and develop their skills. Naturally, this tilts outreach (and blogs like these) towards our amazing sandboxes and thorough learning labs. It is also completely understandable why we would bias ourselves towards these modalities; we are technical people, and we love to learn and teach people through hands-on exploration, whether its guided or self-paced. "See it, learn it, code it" has served the community very well and it is something we are proud of.

However, we want to writethisblog rounding out the complete portfolio of work that supports our infrastructure developers and automation engineers, when the sandboxes and learning labs do not provide all the answers to the questions they have.

The Developer Centers

The Developer Centers (or DevCenters) for short serve a single source landing page for all things programmability related to a product or tool. From updates to product APIs, announcements from the business entity supporting that product, webinars and how-to, and documentation pages -everything needed by an infrastructure developer can be found here.

As part of our commitment to developer experience, these Decenter are kept up to date with any latest information or changes to the APIs to ensure that everyone has access to the relevant content they need, when they need it. We have DevCenters for data center technologies, such as ACI, NX-OS, Nexus Dashboard.  We also have specific DevCenters for Infrastructure as Code, including one specifically for cloud networking, as well as for each IaC tool supported within the DevNet ecosystem, Ansible and Terraform.  There is a ton of information that can be gleaned just from these resources -but this is just the beginning.

API Documentation

We have touched on this in previous blog posts, but still would like to dive a bit deeper into how we are making improvements to our API documentation, providing for a better developer experience. Every API-enabled product (and the cloud networking product lines are no exception) has an API documentation microsite. This microsite (an example for ACI is shown below) contains not only the API guide, but background and context about the APIs and their design principles, model references (where appropriate), and links to external pages, such as IaC modules/providers, sandboxes that can be used to explore the APIs, learning labs, and developer community support forums for questions that may arise during API exploration.  These documentation pages also support multiple versions of the API -meaning that regardless of the version you are running -you can find an API reference for it on our portal.

While these pages may not be as visually "flashy" as our DevCenters, they contain a wealth of information and provide lots of external links to other useful tools. Some of our most popular documentation pages include:

• ACI
• NX-OS
• Nexus Dashboard Fabric Controller (NDFC, formerly known as DCNM)
• Nexus Dashboard Orchestrator (NDO, formerly known as MSO)
• Nexus Dashboard Insights (NDI)
• Nexus Dashboard

But continue to check back, especially as new products or services are released. If it exists -you can be sure we have API documentation for it!

The CiscoDevNet GitHub Organization

While notdirectlyhosted on our own website, many of our links (especially to resources for Ansible and Terraform) redirect to our Github organization for that specific repository. Because we like to practice the principles that we teach to our customers and partners, our GitHub organization is the single source for all code samples, third party IaC resources, and sample projects within DevRel. These public-facing repositories can be forked to your own organization, modified, or improved upon, and submitted for merge into the main upstream branch via a pull request (PR). To top it off, it is not only DevRel advocates and engineers within these repositories, but members of the technical sales, engineering, and product management teams -enabling you to have unfettered access to the teams that are developing automation and programmability solutions.

The other added advantage of using our GitHub organization is that it allows us to use the "Issues" page as a reference for the changelog of our infrastructure as code resources. While TAC does support the resources, it is possible to engage with our developers to work through enhancements or bugs within Ansible modules or Terraform providers without opening a direct service request with TAC. These issues will be aggregated, fixed, and mentioned as part of a given release of the resource and the barrier to opening an issue is incredibly low -showcasing how using a VCS like GitHub can prove invaluable to a developer's workflow.

Our current list of IaC resources on GitHub are:

• ACI Ansible modules and Terraform provider
• DCNM/NDFC Ansible modules and Terraform provider
• MSO/NDO Ansible modules and Terraform provider
• Nexus Dashboard Ansible modules

But again -keep checking -as we are constantly adding specific actions to those resources, as well as adding new resources all the time!

Code Exchange and Automation Exchange

One final (and often overlooked) component within the DevNet website is the Code Exchange and Automation Exchange platforms. Each of these platforms allow you to search for curated content relevant to your needs and use-case, each with a different bent: Code Exchange (CE) focuses on simple code samples that can be used as a starting point for creating a larger solution, while Automation Exchange (AE) focuses on driving a single use-case through to its automated completion.  Both CE and AE help developers, both novice and experienced alike, get started on a project by using other prior work as a source of inspiration or a building block for further tasks. I know that I have been inspired on several occasions to create something using someone else's work as a starting point (with proper attribution to the original developer, of course). You can find Code Exchange and Automation Exchange by clicking on the embedded links in their names.

Putting It All Together

From the list above, you can see that there is more than the impressive learning and sandbox content that we create within DevRel. Everything that we do is meant to drive up the developer experience, lower the mean-time-to-API-call (MTTAC, something I just made up), and ensure that our cloud networking infrastructure developers are supported at every step of their journey and in every way possible.

We would love to hear about your experiences using any of the DevRel resources, not just the ones listed above. Good, bad, indifferent, or otherwise -we are here for it all. You can find Quinn on Twitter @qsnyder or on LinkedIn and we'd love to have a conversation about what is working for you, what isn't, or how we can improve to drive the best developer experience possible.