Navigating the container ecosystem can be confusing. Deciding where to dip your toes is challenging for those stepping into container and microservices waters. Even those who have already ventured knee-deep still wade through many questions as they progress in their cloud native journey.
+ Also on Network World: Containers: Most developers still don’t understand how to use them +
Recognized for their expertise, Cloud Native Ambassadors are individuals who belong to a CNCF member organization and are selected based on their passion for cloud-native technology and willingness to help others learn. Most ambassadors also organize or are involved in community meetups oriented toward technologies and projects governed by the CNCF. Forty-one meetups worldwide have joined the program to date. (Disclaimer: I'm a CNCF Ambassador and an organizer of the Microservices and Containers Austin meetup in Austin, Texas.)
Under a similar program, Docker Inc. provides central community outreach and resources for 228 meetups around the world. The Docker community does not have Ambassadors, rather it has Captains. Docker Captains are community leaders, who demonstrate a commitment to sharing their knowledge of Docker open source or commercial offerings with others. (Disclaimer: I'm an organizer of the Docker Austin meetup in Austin, Texas.)
As you would expect, the two programs are alike in many ways. Both are purposeful in how they approach tech communities—each with an emphasis on engineers focused on containers, microservices, cloud native, distributed systems, mode 2, continuously delivering, etc. Both tend to be open source-oriented and developer- and operator-friendly. Both provide project swag (T-shirts, stickers, annotated mugs, etc.) to their respective community organizers (Captains and Ambassadors). In that vein, the CNCF Store was also launched last week, and each Ambassador and their user groups seeded with an initial dose of gear.
Cloud Native Ambassadors and Docker Captains advocate and educate on behalf of their respective and highly related technologies. Docker Captains promulgate the many varied uses of Docker’s projects: Engine, Machine, Compose, Swarm Registry, Kitematic and all of the plumbing projects around these. So do Cloud Native Ambassadors disseminate and advocate use of the two current projects managed by the CNCF: Kubernetes (system for automating deployment, scaling and management of containerized applications) and Prometheus (systems monitoring and alerting tool).
Additional proposed projects are in the pipeline to be considered for first incubation and next adoption, including NATS (pubsub), Fluentd (logging), Heron (real-time stream processing), Minio (storage), OpenTracing (distributed tracing), CoreDNS (distributed systems-friendly DNS), CockroachDB (distributed SQL DB) and more.
Having spent a couple of years participating in and organizing technology meetups, I liken them to functioning as an underground conference circuit, where quality of speakers and content varies similarly to that of the quality of speakers and content in larger industry conferences. In general, technology meetups are surprisingly refreshing in their candidness, content and convenience—three C’s that deliver value to me as an organizer and to regular attendees.
While individual tech meetups don’t typically fall into the trap of being a low-cost marketing pulpit for large companies and small startups to get the message out about their commercial offerings, this occasionally happens. Most meetups screen speakers and their talks. Some are more at luxury than others in being able to turn away blatant sales pitches. Those that have this luxury tend to be located in cities with technology hubs. Irrespective, meetups provide an alternative forum for direct feedback, cross-technology pollination and practitioner-to-practitioner interaction.
Wooing the developer
One of the goals of the Cloud Native Ambassador and Docker Captain programs (whether via meetups or other forums) is to woo the developer. Developer advocacy in this sense goes by many names (evangelism, technical marketing, community organizing, etc.) and is an emergent, purposeful practice that has been established within many vendor organizations.
Developer advocacy becomes critical in that if you understand that as developers write new software, they are defining the infrastructure of tomorrow. It follows then that if as an industry we’ve come to identify the application as king (and infrastructure lesser important in the face of software-defined everything), so might we identify the developer as queen. Even queens don’t define infrastructure in a vacuum or without collaboration from their Ops/Sec/IT partners, however.
This article is published as part of the IDG Contributor Network. Want to Join?