DEV Community: Dave Nugent 🌉

Three Free Ways to Learn Kubernetes and Red Hat OpenShift

Dave Nugent 🌉 — Wed, 03 Nov 2021 17:26:59 +0000

There are lots of videos and tutorials about how to get started with Kubernetes scattered about online, but what about resources that set you up with your own real Kubernetes environment?

I've compiled a list of three resources where you can get started with Kubernetes and Red Hat OpenShift, Red Hat's enterprise Kubernetes platform. No payment required.

1. OpenShift Open Labs

Want to dive deep into Kubernetes and Red Hat OpenShift? Open Labs gives you six guided walkthroughs to explore scenarios in your own Red Hat OpenShift cluster. These include:

Building hybrid cloud apps by connecting to a Cloudant service using OpenShift operators
Logging with LogDNA
Cloud monitoring with SysDig
Securing microservices

ℹ️ Tip: In order to save resources, you'll have access to the cluster for one hour, after which you can request another cluster.

ℹ️ Tip: There are also Kubernetes-only versions of some labs available here.

https://developer.ibm.com/openlabs/openshift

🧑‍🎓 Good For:

Learning about OpenShift and Cloud services, logging and SysDig
Installing and configuring OpenShift Operators

🤔 Be Aware:

Clusters time out after one hour

2. Earn your Build Smart on Kubernetes Badge

If you only have a couple hours to spare and want to learn about deploying applications to Kubernetes and Red Hat OpenShift, this program will get you there.

You'll learn how to:

Deploy a node.js application using source-to-image,
Deploy a Java microservice application on Open Liberty,
Deploy a machine learning model and use it to classify images

At the end of the workshop, you'll be receive a badge certifying completion that you can share on social media (if you're into that kind of thing!)

ℹ️ Tip: If you're going for the badge, make sure you open the quiz before starting the workshops! The quiz asks for the output of a command from each lab, so it's much easier to complete the quiz as you run through the labs.

ℹ️ Tip: The badges are issued once per week, so you may have to wait up to seven days after completion until your badge is issued.

https://www.credly.com/org/ibm/badge/build-smart-on-kubernetes/

🧑‍🎓 Good For:

Application developers interested in deploying apps to k8s
Sharing your achievement on social media

🤔 Be Aware:

Complete the quiz as you do the labs
You may wait a week for the badge

3. Try.OpenShift.com

Red Hat’s Developer Sandbox contains a number of workshops that give you a deep knowledge of Kubernetes and Red Hat OpenShift, including:

Learn Kubernetes using Red Hat Developer Sandbox

ℹ️ Tip: Red Hat’s Developer Sandbox comes pre-configured with CodeReady Workspaces, Red Hat's productized version of Eclipse Che.

https://try.openshift.com

🧑‍🎓 Good For:

Learning through kubectl and git on your local machine
Working with quay.io, React, and MariaDB
Deploying applications working with Kafka and JavaScript

🤔 Be Aware:

Some of these labs have detailed command line requirements -- but this can be an opportunity for education!

Resources

Free Kubernetes Training links from the Linux Foundation
Keep up to date with the Kubernetes.io blog
David's Twitter
Follow IBM Developer's Crowdcast for interactive technical sessions

Valuing Partner Developer Advocacy and AIOps

Dave Nugent 🌉 — Mon, 26 Jul 2021 15:51:33 +0000

Pooja Mistry focuses on partner developer advocacy, specifically around hybrid cloud and application modernization. She has worked with startups and enterprise-level partners as well as ISVs like Infosys and TCS to promote best practices in AI, Machine Learning and Microservices. I sat down with Pooja to talk about her recent experiences in DevRel and how a focus on partners helps drive metrics for developer advocacy programs.

How does partner-focused DevRel provide value?
Does working with partners improve your messaging?
How do you build DevRel partnerships into an ecosystem?
What is developer advocacy in the context of ISVs?
What tactics are most effective working with partners and ISVs?
What metrics do you use to measure the success of your ISV advocacy?
What is AIOps?
How did you get started in DevRel?
Who is doing developer relations well?

Q: Developer relations programs vary between companies, and each company has their own approach. How does DevRel provide value in the context of partners?

A big value of collaborating with partners is getting their perspective on our technologies and products. It's valuable to see how developers work with our tech in the real world. When I worked with Infosys I saw really solid use cases of IBM's hybrid cloud technologies helping banks and travel agencies modernize their applications. That’s the big take-away and value for advocacy organizations about partner advocacy: while it's tempting to talk about our technology in a vacuum, working with partners lets your audience see the value proposition in the context of the real world, making it grounded and less abstract.

Working with TCS, they’re using IBM Cloud Pak for Integration to build all these integration points for companies in healthcare and aviation verticals. They’ve built their own offering called the Jumpstart Pak for Cloud Pak for integration. You get that from partner engagement: you get to see their perspective on that technology and what brings value to them in their workforce pipeline.

Voice and perspective are important when working with partners. You have to be careful presenting your partner's perspective because it’s not IBM’s voice, it’s IBM and TCS’s voice. Conversely, that can make the messaging more powerful: we’re getting more people in the room and more diverse viewpoints.

Q: Can working with partners improve your DevRel messaging?

It can, but the improvements go deeper than messaging. At IBM, our mission is to work with our advocacy partners to drive interest in our products that leads to revenue opportunities. We choose our messaging based upon how a particular partner works with our technology.

I'm focused on figuring out the interested audience for each particular technology area -- bear in mind, it’s difficult to narrow down that audience to who will actually buy. However, across all audiences we have a lot of interest in our online partner events: we’ve had over 900 people join certain partner events, which shows that some of these integrations involve technologies that customers are critically interested in.

I’ve seen much more interest from audiences when collaborating with partners as opposed to my prior work in "vanilla" developer advocacy. Partner collaboration allows us to learn from their audience what is useful to their end users in this space.

Q: It seems like developer-focused companies are falling over each other to build partner ecosystems. How do you evolve DevRel partnerships into an ecosystem?

It’s empowering to see a partner or client build products as an extension of our products; these show that our products have value in the market. These build-ins evolve in many ways: Instana and Turbonomic were originally partners but then were acquired by IBM. Their technology has been embedded in our ecosystem, strengthening it.

While I don’t have any insight into our corporate strategy, I think that if we are to be considered a hybrid cloud company, when working with partners we provide the technology whereas the partners provide use cases and implementation. To foster a diverse ecosystem, a developer advocacy organization's mission must be to educate and to expand the eminence of our work. That’s what our role is in building the ecosystem: we have to educate partners so that they can educate their clients and expand the reach of our technology to other people.

Q: How do you separate partner advocacy from other ways of interacting with business partners? What is developer advocacy in the context of ISVs?

When you’re collaborating with a partner, you’re also giving them a stage to educate and speak freely. So we are educating the partner, but they are also educating us on the tech that they’ve been working with.

Advocacy is so powerful, but it’s so abstract. It’s about winning hearts and minds, but it’s really about bringing awareness. Technology is moving so quickly and things are happening in the blink of an eye, and people like us, as advocates, can shine a light on trends and people should focus on. There are so many lights out there, and as advocates we are filters that can focus on things that people should focus on.

Partners also validate whether a particular technology is worth IBM's involvement or whether it’s just hype. You can see from partner engagement what the technology's use cases in the ecosystem look like and whether those projects add value for all players. These are crucial data points that can inform whether your technology addresses a particular need or not.

Partner advocacy is the hardest job I’ve ever done. You have to say the right thing, you have to understand what people are looking for, and you have to learn so quickly about different technology trends. Last year I was working on visual recognition and object detection; this year I’m working on partner integrations and AIOps. That’s the only constant with advocacy: you’re trying to hype up things that follow a specific trend, and partner work can validate that focus that you’ve chosen.

Q: Let's get down to brass tacks: what tactics are most effective working with partners and ISVs?

It can be difficult to understand how best to advocate for enterprise technologies through partners. How do I teach some of these enterprise level concepts to developers? Perhaps developers won’t need to know everything that’s involved in deploying a large-scale high-availability suite of microservices, but I can more easily teach a group of them to deploy a small microservice to a Red Hat OpenShift cluster. By breaking down these large enterprise application concepts into bite-size tutorials, developers can more easily understand how they can utilize these technology trends.

Let's look at an example. Through our Cloud Pak for Integration offering we have a number of public cloud services available for developers to use for free: API Connect, App Connect,Message Queues and Event Streams, etc. To simplify their educational journey, I like to take some of these heavier enterprise applications and develop workshops where developers can build something small using one of these free services. In one workshop, I show developers how to take email addresses from Eventbrite, and send emails to attendees and then put that campaign data into SalesForce. As a developer, App Connect lets you automate that process, and you don’t need to have a paid enterprise account to facilitate that level of automation.

To continue the journey, we can show developers how to build a low-code application that can quickly bring these custom integrations together. Our App Connect session with TCS went so well that we were invited to reprise that session at the IBM Digital Developer Conference and Think, and we’re building out another presentation on API Connect and Event Streams.

The nuts and bolts of teaching developers across the world about our technology are to break down these large concepts into digestible units through easy to understand workshops. Here are links to a few examples I've created:

Q: What metrics do you use to measure the success of your ISV advocacy?

One of the most important success metrics is audience engagement. In IBM, we’ve been measuring success by seeing consistent audience attendance to our partner workshops and measuring that against our non-partner session attendance. We also see value in how many times I can re-use partner content at other conferences: Think, DDC,Red Hat Summit, All Things Open. This allows us to save time while also sharing our partner messaging across different arenas and audiences.

One thing I was surprised by was that one of our sessions at Think was the third-top-viewed session, which shows that we’re getting a lot of traction in these topics and following the right trends. This also empowers our partners to continue to collaborate with us and build more interesting content for the community.

Q: What is AIOps?

Inside IBM, I am the integration tech focal for AIOps & Integration. AIOps, at its core, is monitoring. One of our recent acquisitions, Instana, is built around monitoring and observing your microservices. However, at this time, AIOps is still being defined. Integration is connecting data and applications across different clouds. I really like integration, and I’ve given a number of workshops on this front. Here's a code pattern I have written about App Connect, which is the bread and butter of our Cloud Pak for Integration offering.You can create pipelines to automate connectivity between enterprise apps in a low-code environment. I’ll be working with developer advocates throughout our organization to empower them to work with partners and create new integrations.

Q: What codebases have you been working on?

The Bee Travels project. I just spoke about it at the Red Hat Summit. If you’re learning about microservices and you don’t know where to start, this repo is a good place. It takes the form of a travel application with a microservice for each part of the application: one hotel service, one car service, one flight service, etc. it’s a really cool project to clone and spin up; as you dive a little deeper you can play around with each microservice individually. The same application is written in node.js and Python, and we’re also writing it in Go. The idea is that no matter what language you prefer to code in, you can get your feet wet with the concept of microservices and deploying them to kubernetes and Openshift.

Q: How did you get into developer advocacy?

I got into developer advocacy when I started doing a lot of community work outside of my day job; I had been living in Boston at the time and I was an automation engineer. During my day job I would work with people remotely but it was difficult to socialize and find something bigger than myself as my position focused on development. One of my good friends and I started going to different meetups in the Boston area, and we decided to create our own grassroots community in Boston around entrepreneurship. We spearheaded TechStars' Startup Weekend in Boston, and there was a huge amount of interest: we did our first event in the Watson Health building and we had over 175 people attending the event live. It was so great to get a community excited about something, and we ended up doing five more sessions for Startup Weekend, and we even did a partnership with Google for a partner event. All this was outside of my day job, and then I started helping different teams inside IBM with their community engagement, and finally got into a role as a developer advocate in New York City.

Since then, I’ve changed a lot into partner advocacy; back then, I would want to get people excited about building and working in our public cloud. We were doing eight in-person events every month on different technical workshops and topics. The last awesome in-person thing we did was a holiday showcase with 250+ registrants right before the COVID-19 pandemic hit.

2020 has been different as I shifted into partner advocacy and our Call for Code initiative. Being involved in a community and getting people excited about an idea or technology; learning something; teaching something; getting people access to resources and platforms: this is my driving philosophy and something that I want to continue doing throughout my career.

Q: Who in DevRel is doing awesome things that we should know about?

There are so many amazing people doing great work in Dev Rel. Here are a few that I truly admire

Adrienne Tacke: I like her approach to DevRel, which covers a ton of activities including writing books! I’d love to work with her because we use MongoDB on IBM Cloud.
Priyanka Vergadia: I love her approach to advocacy, she makes so many informative videos about cloud technology
Bradston Henry: Bradston is one of my colleagues here at IBM Cloud! He’s writing some awesome blogs and creating some great videos about all things cloud native!

Thank you Pooja for taking the time to share your knowledge with us. You can learn more about Pooja on her LinkedIn, Twitter and on Dev.to.

Adding Google Auth to Kubernetes Clusters with Red Hat OpenShift and IBM AppID

Dave Nugent 🌉 — Thu, 15 Jul 2021 15:49:24 +0000

This document collects some of the links that you'll need in our lab. This is an interactive lab, so we will assume you have some knowledge of Kubernetes.

🎓 What will you learn?

How do I build an application using Java and Open Liberty?
What is Red Hat OpenShift and how does it compare to Kubernetes?
How do I deploy a Red Hat OpenShift/Kubernetes cluster?
We'll conclude with an interactive lab where you'll be able to add IAM to your own Red Hat OpenShift cluster.

This lab was presented live on Crowdcast. Here is a link to the recording: https://www.crowdcast.io/e/hybrid-cloud

Create your IBM Cloud Account
Grab your Kubernetes/Red Hat OpenShift Cluster
Create an AppID Instance
Resources

Create your IBM Cloud Account

First, you'll need an IBM Cloud account so that we can assign your free Red Hat OpenShift cluster to you.

Once you've registered, you'll need to activate your account by clicking a link in your email.

Grab your Kubernetes/Red Hat OpenShift Cluster

Visit https://idlab.mybluemix.net and sign up using the email address you used to sign up for your IBM Cloud account. The key is oslab

Once you've submitted this form, you'll be invited to join our advocacy account. You have to accept the invite by clicking on the notifications icon in your IBM Cloud control panel (it's the bell in the upper right.)

Once you've accepted the invite, you'll be able to see the Red Hat OpenShift cluster we've assigned to you at https://cloud.ibm.com/resources.

Create an AppID Instance

Navigate to: https://cloud.ibm.com/catalog/services/app-id and follow the instructions in the lab

Here is Jenna's GitHub containing the application source code: https://github.com/jritten/secure-openshift-w-appid

Resources

Deploying Scalable Java Microservices to Enterprise Kubernetes using Red Hat OpenShift

Dave Nugent 🌉 — Fri, 04 Jun 2021 16:47:38 +0000

Three of the fastest-growing architectural and deployment models in software today are microservices, Kubernetes and hybrid cloud. In this lab, we'll walk through building a hybrid cloud microservice application using Java and Open Liberty, deploying that application to a Kubernetes cluster running Red Hat OpenShift. We'll do this using free (!) and trial resources on IBM Cloud.

ℹ️ This lab uses parts of the Open Liberty OpenShift Operators Lab, but consolidated and updated with the latest syntax and lab versions.

1. Create your Account

In order to get your free cluster assigned, you'll need to
Sign Up for IBM Cloud

ℹ️ Issues activating your account? Make sure to check your spam folder for the activation email, and if your free email account doesn't work, try another email address, e.g. your work email. For some reason, outlook.com accounts often won't register.

2. Grab your Red Hat OpenShift Cluster

Visit https://olsolab.mybluemix.net and remember to use the following Key: oslab

(For the email address, use the same email address you used to register your IBM Cloud account.)

Now, you'll be able to access your Red Hat OpenShift Cluster through the IBM Cloud dashboard. Visit https://cloud.ibm.com/resources:

Now, click on your cluster name to access the cluster details page on IBM Cloud:

In the upper right corner, pull down the Actions menu and select Connect with CLI

After clicking Request Token, you'll see a custom command created under Log in with this token. Copy that to the clipboard, we'll use it in a second!

Back to your IBM Cloud dashboard, click on the IBM Cloud Shell icon.

The shell will take a few seconds to spin up. Once it's live, you can paste the oc login ... command that we copied a few steps earlier. Voila, you're now logged in to your OpenShift cluster from the IBM Cloud Shell, and you can run commands using oc!

3. Installing your Red Hat OpenShift Operators

First, let's create a new project. I'll call my project guide. You can do this through the Red Hat OpenShift UI, or through the CLI:

oc new-project guide

Next, we'll install two operators: Strimzi for Kafka and Open Liberty. For this install we'll be using the latest Open Liberty operator, but specifically we'll use version 0.22.1 of Strimzi.

First, click the OpenShift Web Console link on your IBM Cloud cluster page:

From the left menu, click Operators >> Operator Hub.

Then make sure you change to the appropriate project, which we've called guide.

ℹ️ You can use any project name, just make sure to be consistent.

Now that we have the correct project selected, let's install the latest version of Open Liberty and version 0.22.1 of Strimzi.

3. Clone the code!

Let's utilize the example code provided by the Open Liberty project in order to deploy some simple microservices. We'll clone the code using these commands:

git clone https://github.com/openliberty/guide-cloud-openshift-operator.git
cd guide-cloud-openshift-operator
cd start

We'll modify the files in the start directory in this lab. Eventually it will resemble the finish directory, but you can skip ahead to finish if you want to :D

4. Create kafka.yaml

You can configure the specifics of the Strimzi Operator-controlled Kafka deployment with a YAML configuration file.

Ensure that you are in the start directory, and create the file kafka.yaml in your favorite editor.

ℹ️ Note: Due to new api incompatibilities, this kafka.yaml file is different than in the Open Liberty tutorial.

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: kafka-cluster
spec:
  kafka:
    version: 2.5.0
    replicas: 1
    listeners:
    - name: plain
      port: 9092
      type: internal
      tls: false
    config:
      offsets.topic.replication.factor: 1
      transaction.state.log.replication.factor: 1
      transaction.state.log.min.isr: 1
      log.message.format.version: 2.5
    storage:
      type: ephemeral
  zookeeper:
    replicas: 1
    storage:
      type: ephemeral
  entityOperator:
    topicOperator: {}
    userOperator: {}

ℹ️ Note: having issues with vim and indentation? Try setting :set paste before pasting, then :set nopaste after you're done.

Now, let's deploy Kafka based on this file:

oc apply -f kafka.yaml

5. Building the Microservices

Run the following commands to package the system and inventory microservices:

mvn -pl models clean install
mvn clean package

Now, let's create a build.yaml file:

apiVersion: v1
kind: Template
metadata:
  name: "build-template"
  annotations:
    description: "Build template for the system and inventory service"
    tags: "build"
objects:
  - apiVersion: v1
    kind: ImageStream
    metadata:
      name: "${APP_NAME}-imagestream"
      labels:
        name: "${APP_NAME}"
  - apiVersion: v1
    kind: BuildConfig
    metadata:
      name: "${APP_NAME}-buildconfig"
      labels:
        name: "${APP_NAME}"
    spec:
      source:
        type: Binary
      strategy:
        type: Docker
      output:
        to:
          kind: ImageStreamTag
          name: "${APP_NAME}-imagestream:1.0-SNAPSHOT"
parameters:
- description: The application name [system|inventory]
  name: APP_NAME

Run the following commands to create the objects for the system and inventory microservices:

oc process -f build.yaml -p APP_NAME=system | oc create -f -
oc process -f build.yaml -p APP_NAME=inventory | oc create -f -

Finally, let's trigger the builds:

oc start-build system-buildconfig --from-dir=system/.
oc start-build inventory-buildconfig --from-dir=inventory/.

6. Deploying the Microservices

Next, it's time to manage the deployment. Create a deploy.yaml file:

apiVersion: openliberty.io/v1beta1
kind: OpenLibertyApplication
metadata:
  name: system
  labels:
    name: system
spec:
  applicationImage: guide/system-imagestream:1.0-SNAPSHOT
  env:
    - name: WLP_LOGGING_MESSAGE_FORMAT
      value: "json"
    - name: WLP_LOGGING_MESSAGE_SOURCE
      value: "message,trace,accessLog,ffdc,audit"
    - name: MP_MESSAGING_CONNECTOR_LIBERTY_KAFKA_BOOTSTRAP_SERVERS
      value: "[kafka-bootstrap-address]"
---
apiVersion: openliberty.io/v1beta1
kind: OpenLibertyApplication
metadata:
  name: inventory
  labels:
    name: inventory
spec:
  applicationImage: guide/inventory-imagestream:1.0-SNAPSHOT
  service:
    port: 9085
  expose: true
  env:
    - name: WLP_LOGGING_MESSAGE_FORMAT
      value: "json"
    - name: WLP_LOGGING_MESSAGE_SOURCE
      value: "message,trace,accessLog,ffdc,audit"
    - name: MP_MESSAGING_CONNECTOR_LIBERTY_KAFKA_BOOTSTRAP_SERVERS
      value: "[kafka-bootstrap-address]"

You'll notice this file has a value missing, [kafka-bootstrap-address]. You can find this in your pod configuration on OpenShift, it should look like this: my-cluster-kafka-bootstrap:9092

You may be able to get the correct value by running:

oc get kafka kafka-cluster -o=jsonpath='{.status.listeners[?(@.type=="plain")].bootstrapServers}{"\n"}'

Replace [kafka-bootstrap-address] with the new value.

Next, deploy the application by running

oc apply -f deploy.yaml

7. Accessing the Live URL

In order to get the public route, run:

oc get routes

You'll see an output similar to:

NAME        HOST/PORT                                    PATH   SERVICES    PORT       TERMINATION   WILDCARD
inventory   inventory-guide.apps.lights.os.fyre.ibm.com         inventory   9085-tcp                 None

Visit the inventory microservice by going to the following URL: http://[HOST]/inventory/systems (making sure to substitute the host name with the host value from the above command.

Congratulations! You've just finished setting up and deploying an Open Liberty microservice on Red Hat OpenShift!

Resources:

Enterprise Java Developer Relations and Community Engagement

Dave Nugent 🌉 — Thu, 13 May 2021 21:52:14 +0000

Mary Grygleski is a Java technologist and software engineer. She works on technical community outreach as a Senior Developer Advocate at IBM. Mary works with hands-on code to architectural overviews. She focuses on the Java ecosystem, especially Liberty, Microprofile and Reactive, as well as Enterprise Java. She is also knowledgeable about hybrid cloud Java deployments using Kubernetes and Red Hat OpenShift. She transitioned from Unix and C to Java and Open Source in the new millennium, and has worked for different software vendor companies as well as several major IT shops in the corporate world.

How has Kubernetes changed Java DevRel?
How is Java developer relations unique?
How does Open Source impact developer relations?
How did you get started in DevRel?
What motivates your interest in community?
Who is doing developer relations well?

Q: You've worked a lot with Java. How has Java developer relations changed with the introduction of hybrid cloud and Kubernetes?

Kubernetes is good stuff! Working with cloud native and cloud technology has expanded my horizons. To give you some background, I used to work with what used to be called J2EE, then JEE, and now the rebranded name of Jakarta EE, and I spent a ton of time in that ecosystem, working with Java Swing, EJB, servlets, and so on. Looking at cloud native and Kubernetes, I see similarities between Red Hat OpenShift, Linux command-line clients, and containers. Interacting with Kubernetes resembles interacting with an operating system. Kubernetes is like an OS on steroids -- a simple implementation contains many instances! It’s an abstraction: you can create virtual machines that run in parallel processes on the same hardware. Docker is another novel technology that has changed the way we deploy software.

This has changed not only how we build applications; it has social impact too. There used to be people on J2EE teams who focused on release management. These teams had a number of detailed processes involving tons of people working on different types of builds for different environments - dev, QA, prod, pre-prod, etc. Such processes wasted a lot of time: for example, reproducing bugs in different environments was difficult because those bugs were produced in different ways. When Docker came out, you would just pull the image and plug it into any environment, which changed the way how these things were being done. At the same time, as the process improved, people lost their jobs -- you didn’t need a huge team to execute release pipeline tasks. From the point of view of a mechanical pipeline of efficiency, the whole containerization and devOps movement has made the delivery much more effective.

At the same time, using Kubernetes in production is not yet plug-and-play. You can't yet roll out of bed and build a Kubernetes cluster without any experience. Some level of intricate setup is still needed, and that requires knowledge, skill and experience.

I did a joint talk with another speaker from Ukraine and built an example of using reactive sockets for building pipelines, pumping in machine learning data from a multi-player Pac Man game and using RSocket to do that. I spent a lot of time understanding machine learning concepts too, picking a reinforcement approach with case-based reasoning, even though AI/ML isn’t my focus area. I also demoed some code using genetic algorithms.

I’m interested in concurrent distributed systems and event driven architectures. At the same time, I don’t restrict myself to one specific paradigm; it’s all about solving problems with concurrent distributed systems.

Q: How is Java DevRel different from developer relations for other languages or audiences?

Java has definitely carried with it a higher overhead as a web frontend language than other more popular web-based languages like JS or Python. In fact, I recall Java being described as an old-fashioned Cadillac, versus JS or Python like driving a more modern and efficient car. But the strength of Java lies in its backend, its platform independence, and its enterprise capabilities.

Now, with the newer releases and faster release cadence, Java has become a lot more efficient, but there is still some “Java way of doing things” that involves a type of ceremony. (Of course if you’re using Spring Boot, then it’s a bit different …) In Java, you don’t need to follow an opinionated way of doing things, which is also the “beauty” of Java, yet, because of that, it can be harder too especially for anyone not as familiar with Java and not having any “framework” to guide her/him to start.
In terms of developer advocacy, I’ll go out and do presentations, and with a Java audience, if you talk about some conceptual idea that applies to all languages or frameworks, for example, Microsoft has a reactive framework called Orleans, the conversation in my presentation applies to that as well as all other reactive frameworks.

When I give a presentation I pay close attention to the language and how the language gets deployed, and there are expectations about how you’ll do things and how you’ll deploy the application; if you get this right, the audience will understand what you’re doing without a lot of cognitive dissonance. Java DevRel is a little more difficult to understand in the beginning, but once you get over the hump, it’s not so bad.

I remember when I first learned Python using the Flask API at a hackathon, I built it out in three hours; they’re set up to be easier to get hands-on experience without a lot of environment setup. The benefit with Java is that you get more control over what you want to build, which Enterprises love.

Q: How does Free/Open Source software impact developer advocacy efforts, especially in the Java ecosystem?

I think open source has become so prevalent these days, it’s almost like a standard of all environments. It’s becoming a natural way of doing things, especially with Java and the Apache software foundation and the Eclipse foundation, both of which have a strong Java focus. Open source software became a natural part of the ecosystem.

When I first started working with Java, we would use Apache Common library to do things, and we’d always use open source projects like Tomcat. Because these are so easy for any person to setup and configure, it became an obvious goto for advocacy.

The Java Community Process is the open way of encouraging the community to contribute to its specification. That’s how I view it: a very natural part of the community and how Java works hand in hand with Open Source.

Q: How did you get started with developer relations?

I only started doing formal developer relations at IBM in 2018. Before that, I spent two and a half years volunteering with the Chicago JUG, which actually went back to 2013/2014, when I wanted to get more involved with the technical community. The best way to do that is to join a user group, right? I chose Java because I’d been using it since 2000.

Volunteering for the JUG is almost a precursor to being an advocate. You’re trying to advocate for the community, and you’re also choosing speakers who come in to talk about technology and new things. I was attracted by that, and we may call that a calling? Prior to that, I went to a conference in Chicago, No Fluff Just Stuff, and saw several well-known Java speakers present their talks, such as Pratik (Patel) and the one-and-only-one amazing Venkat (Subramaniam). But it never occured to me that I would do advocacy at that point. I was excited simply because I was being exposed to new ideas and concepts which I wouldn’t have been exposed to in the office at work. There were so many new things coming up in technology with frameworks and toolkits that I was missing. I remember thinking, “It would be nice if I became a speaker one day!”. After joining the JUG, I became a user group junkie. I started attending different groups and becoming more involved with the community. CJUG eventually asked me to help as an organizer, and I was then nominated as a meetup director as of 2016. As a result of that, I got to meet more people from the community as well as a lot of great speakers, and I started speaking myself. I was never one for public speaking — that was the scariest thing in my life! However, CJUG has encouraged members to give five minute lightning talks. I remember my first presentation took two weeks to put together! Once I got over that initial fear, I started relaxing and was able to present to other meetup groups, such as women in tech. I was able to get the job in developer advocacy through my speaking experiences at meetups and conferences — that’s how I became an advocate!

Q: What keeps you going? What motivates you to wake up every morning and make the world a better place?

I have an abiding love of technology. I love emerging technologies, and I love to stay on top of the latest trends while also getting my hands “dirty”. Software engineering creates so much opportunity to leverage creativity. While I love working with people and mentoring, I don’t feel that I want to move away from engineering into management.

I love my developer advocacy work: doing presentations, creating content and sharing information. Before starting this job I felt I was in a shell and I wouldn’t be able to break out and do public speaking. At conferences, I would sit in the back and not interact. After years in the community, I’ve found that community engagement was a suppressed aspect of my personality that has blossomed! Now that I have found my passion, I am committed to helping other people engage in their communities and make technological communities open and productive spaces.

Q: Who in DevRel is doing things that you want to call out?

Trisha Gee and Mala Gupta of JetBrains
Matt Raible of Okta
Alina Yurenko of Oracle
Josh Long and Mark Heckler of VMware
My colleagues at Red Hat: Steve Poole , Burr Sutter and Edson Yanaga
Many more :)

Thank you Mary Grygleski for sharing your thoughts on Java developer relations with us.

Massively Scalable Realtime Voting Deployed on Hybrid Cloud

Dave Nugent 🌉 — Mon, 08 Feb 2021 18:03:17 +0000

Hybrid cloud deployments offer the easy scaling of public cloud services combined with the privacy and security of an application deployed on a private cloud or on a private server.

In this article, we'll walk through how to deploy a Node.js application that allows users to vote and see a visualization of results. This application will be hosted on a Red Hat OpenShift cluster, which can be deployed on a private or public cloud. We'll also use Twilio Sync, a public cloud service that is scalable and will manage the real-time communication between browsers.

Who should read this post?

This post & lab is intended for developers, software architects, DevOps professionals and anyone who wants to know more about Kubernetes or Red Hat OpenShift.

Step 0: Sign Up & Get Your Red Hat OpenShift Cluster
Step 1: Get Started with Twilio Sync
Step 2: Deploy Your Application to Red Hat OpenShift
Step 3: Link it all Together: Run your Hybrid Cloud Application
Conclusion & Next Steps
Resources

Step 0: Get your Red Hat OpenShift Cluster

Red Hat OpenShift is the Enterprise Kubernetes platform. In order to get the benefits of running Red Hat OpenShift you'll need to spin up multiple nodes and pay for a license -- but today, we'll be taking advantage of a free cluster offered by IBM Cloud through their Open Labs project.

1. Sign Up for IBM Cloud. This will give you an account that you can use to get your cluster.

❗❗❗ Remember to confirm your email address by clicking the links that are sent to your email address.

2. Sign Up for Twilio

Twilio is a cloud-based messaging service that we will be using to create a chatbot. We'll be using their Autopilot service, which is free, but the link above will give you some credit that you can use for other Twilio services in the future.

3. Launch IBM's Red Hat OpenShift Lab

Visit the IBM Open Labs page and click on Launch Lab under Lab 1.

ℹ️ Having issues accessing the OpenShift Labs page? Try clearing any cookies from ibm.com and logging in again, or using a private browser window. Sometimes, cookies can confuse the Lab bot.

Step 1: Get Started with Twilio Sync

Create your Twilio account and create a Twilio Sync document.

Step 2: Deploy Your Application to Red Hat OpenShift

Red Hat OpenShift makes it ridiculously easy to deploy an application from a GitHub repo, even if you don't have any experience creating a container image. In fact, it will create the image for you using its source to image feature. In this step, we'll use the code we've already been looking at as well as source-to-image in order to deploy our hybrid cloud application.

3. Here is Lizzie's GitHub: https://github.com/drnugent/twilio_voting (we'll use the tree/3stocks branch)

Step 3: Link it all Together: Run your Hybrid Cloud Application

Conclusion & Next Steps

Congratulations on deploying our massively scalable real-time voting application in a hybrid cloud environment! 🎡⛱️🚀 Just to cover what we've done:

We deployed a Red Hat OpenShift cluster on IBM Cloud, running Kubernetes to make effective use of our compute resources
We deployed an application directly from our GitHub repo, automatically building a container image and spinning it up into our production environment
We used Twilio's cloud services to

In future posts, we'll explore more about Red Hat OpenShift, hybrid cloud deployments, and cloud native software architecture. Please if you'd have ideas for future integrations!

Resources

Global Developer Relations with Empathy and Compassion

Dave Nugent 🌉 — Tue, 08 Sep 2020 22:02:09 +0000

Johanna Koester is Director of Worldwide Developer Advocacy for IBM, where she oversees a team of dozens of developer advocates around the world. Their mission is to promote open source and cloud services. I sat down with Johanna to discuss developer relations in enterprise companies and the value of open source and empathy to developers, to developer advocates and to managers and executives.

How do you prove the value of developer relations?
How does open source advocacy work?
Why is empathy and compassion important?
What's the importance of addressing "blockers?"
Are cross-functional teams more affected by blockers?
How did you get into developer relations?
What is IBM's career path for devrel professionals?
What issues do global DevRel teams face?
How do you address D&I globally?
How do you develop a team culture?
Who is doing developer relations well?

Q: We both work at IBM, which is a massive company. How difficult is it to prove the value of developer relations to executives above you in the corporate hierarchy?

Today in IBM, I’m happy to say that we don't have those arguments about whether to focus on developers. When we get into any business justification discussions, it’s around specific initiatives for developer advocacy, not whether to invest in developer advocacy -- the buy-in on the importance of developers is ubiquitous up and down the hierarchy in a way that I've never seen before. Several years back we started our developer advocacy program in earnest which was a natural evolution for IBM since we have been involved in open source and open source advocacy for about 30 years. When we started the advocacy effort, this developer-focused mindset wasn't quite where we needed it to be across the company. At that time, IBM was more of a product-led, C-suite focused company when it came to client engagement. During those early years, our team drove most of the conversations across IBM about the importance of developers and the value of winning their hearts and minds.

As a result, today you can see the importance of developers emphasized in weekly videos and blogs from our senior leaders IBM CEO Arvind Krishna, IBM President Jim Whitehurst and Developer Ecosystems Group leader Bob Lord. This means we spend less time evangelizing the importance of reaching developers and more time on how to reach developers.

Q: These days, many enterprise companies place high value on adopting open source solutions as opposed to proprietary ones. From a developer relations perspective, is it easier to advocate for open source solutions?

Yes definitely. We engage with developers on the business and technical problems they need to solve, and the more we can teach them how to solve those problems with open technology, the more flexibility they will have to adapt their solution to future needs. This resonates with developers because they're typically concerned with solving problems for their company as quickly and effectively as possible regardless of the platform. Open technologies can help them achieve that goal: in addition to solving problems quickly, those same problems can be solved in a platform-independent way supporting interoperability and portability.

Q: You run a very large team, and something that always comes through in your communications is empathy and compassion. Why do you devote so much time to messaging these topics?

Empathy is one of my favorite topics and I'm very passionate about it. I do hope my passion comes across in the weekly pleas to the team to take the weekend off to rest, relax and recharge.

I find that empathy is an interesting formula: the more you lean in to your teams with empathy and urge them to take care of themselves, with the mindset of "you come first" and "you're the most important part of our business," the more you create a healthy culture and as a result the more the team wants to lean back in to help the organization. Empathy in management is a lot like practicing random acts of kindness, the more you give, the more you get in return.

Building trust through empathy in our culture doesn’t start with me; there is a dependency on this focus coming from the top. I’m fortunate because my manager Willie Tejada is this same kind of leader for me: family first, take the time you need, make sure you disconnect while on vacation. This approach has such an important ripple effect. Not only am I grateful for this culture which drives my productivity levels higher but it also fortifies me as a leader to share these values with my direct reports. There is no big secret here: if you take care of the team, truly, honestly and empathetically, your team will show up and take care of the business.

It's interesting to watch how this approach unfolds: the more I lead in this way of empathy and blocker tackling, the more my team members have the space, energy and mental peace to do their best to deliver and drive innovation. If you’re interested in learning more, I recommend
Jim Whitehurst’s new video series on LinkedIn about culture to drive innovation.

Q: Some issues can't be solved by individual contributors, and these "blockers" can impact productivity. How important is eliminating blockers?

Resolving organizational and business blockers is my main value-add as a senior leader, it’s a big part of the job. These can be smaller issues like a critically important purchase requiring approval or resolutions to tool or infrastructure issues required to do their job. Blocker-busting and inspiring our teams helps keep morale and productivity high. It's the most important thing that I can do and it feeds into the trust of the team. With this bank of trust, if a leader does have to make an urgent request, the team is more likely to do everything they can to respond in a timely manner. It's about showing up for your team each and every day, not ignoring the daily problems that need attention whether big or small. Even if in some cases I have to say "I don't know how to solve it" , I always commit to research and do my best to knock down the blocker.

Q: Is developer relations more affected by blockers because of the cross-functional nature of DevRel teams?

Perhaps this question circles back to your original question about convincing the executives about the value of DevRel. For executive line management and our business leaders, we don’t spend a lot of time convincing them of the value of developer advocacy. That inherent understanding however doesn’t always translate to other areas of IBM’s business that may not live and breathe devrel every day, yet their support is needed to overcome blockers internally. So yes, there are sometimes situations internally where I may need to go back to foundational value statements of developer advocacy in order to inform on the importance of the blocker in question whether it’s technical support or perhaps event expense.

As developer advocacy evolves and matures as a discipline and as we continue to prove value across the company, the nature of these conversations will continue to change, for the positive. The good news is that all the way up to our CEO, Arvind Krishna, the importance of developers and open source is top of mind. I’m optimistic that this viewpoint will continue to waterfall to everyone in the company. I think a good case in point is an evolution of our sales teams who now understand that authentic developer advocacy lends a great deal of credibility when engaging client developers. More than ever our sellers are engaging us to participate in client and partnership discussions. This momentum will only continue to grow across sellers and other stakeholders in IBM.

Q: How did you get into DevRel?

I spent most of my early career in IBM’s Retail Store Solutions which for me evolved into a role leading retail standards as part of IBM’s Open Standards organization. This organization in IBM held key leadership roles and influence in major open standards groups across the world including OAGI, OASIS, DMTF, NIST The Open Group, W3C and of course ARTS where I spent most of my retail standards time. With this experience, this team was perfectly poised to assume leadership for the many new cloud open source initatives including OpenStack, Cloud Foundry, CNCF, Node.js and more. I’m still very proud of the work we did as a team led by Todd Moore to found these very important organizations rooted in open governance, open bylaws and meritocracy. I loved open source work from the day I stepped into my first OpenStack event. I still remember seeing signs at that conference that said "no suits allowed", sectioning off work areas where people collaborated to build open tech based solutions which would run across platforms, regardless the company that employed them. I simply loved the concept that open source code is developed by a community, freely downloadable for that community and was very proud that my core role was to promote sponsorship, participation and contributions to these open source foundations.

This whole era was the beginning of developer advocacy inside IBM before we even called it “developer advocacy” because our developers spent dedicated time contributing to these communities, achieving committer status and building their own technical eminence within the communities. This is where our developer advocacy group began, performing acts of advocacy even before it was cool to call it developer advocacy or devrel. About six years into that journey when Willie Tejada became our leader as GM, Chief Developer Advocate, we had the engine primed and ready to accept his leadership, aggressively building a worldwide team of dedicated developer advocates teaching the world’s developers about open technology.

Fast forward to today. Now I have the great fortune to lead a team of developer advocates around the world who engage with developers in their local communities. They are able to blog or lead workshops or speak onstage with a focus of altruistically teaching developers the tools and technology they need to solve technical and business problems. Yes of course we represent a large business with important business goals and so yes, there is a benefit to IBM to teaching developers, winning hearts and minds and staying top-of-mind for them. However I take great pride in the fact that the primary goal of our organization is to teach the worlds developers because each and every day I feel that our team helps make the world a better place for developers.

Q: IBM recently rolled out a career path for developer advocates, so that they can progress and be promoted without being categorized as programmers or managers. How important was this to your team?

IBM has a long history of career paths for many technical professions including programmers and developers which is the foundation for developer advocacy however it is only recently that IBM explicitly defined the developer advocacy career path. It was important to define this level of specificity for our developers working in advocacy to ensure their career progression across the IBM company through defined job levels. This definition outlines job responsibilities and expectations level by level for progression in developer advocacy specifically. I do want to be clear here: developer advocates were never without a career path and we have promoted many team members through the past years. What is new here is that we now have more specificity about what developers can and should do day to day as well as long term to progress their careers.

Q: Your team easily spans a dozen time zones. What are some difficulties you've overcome growing a team to this size?

What makes managing a worldwide team interesting is the diversity of culture and developer communities. A huge part of my job is listening and learning these differences through conversations with people around the world. As an example, when we started this COVID journey, the whole team immediately switched to digital events and conferences, however one of the first conversations I had on this topic was about how some individuals might not be able to lead events from home if they lived in a place where infrastructure was not reliable. Other people were living in shared spaces which can make it quite challenging when leading virtual events. We see dynamics like these surface across different geographies, and so as a leadership team we are constantly in listen mode to understand the challenges that people are facing and working to resolve. I’m proud to say that the team has overcome many of these issues, mostly due to their own creativity in balancing the workload and assignments across their team. Bottom line, every geography is going to have a different set of criteria and dynamics when it comes to DevRel, so you have to constantly listen and seek to understand in order to respond and help.

Q: How do opportunities for diversity and inclusion manifest themselves in global teams?

Similar to many of the topics we’ve discussed today, it's important to make time to listen and digest what your leaders in these respective geographies are saying about diversity and inclusion. Geographies and cultures across the world are certainly not cookie-cutter: diversity and inclusion can have different meanings across teams. One thing is universal however, diversity and inclusion is critically important and requires consistent focus.

A couple of years ago, I delivered a keynote at the Open Source Summit in Edinburgh focused on diversity and inclusion. The approach I took for the presentation was to feature profiles of three women working on our open source initiatives. Here’s the interesting thing about their diversity stories, they weren’t always about being the “only woman in the room” as one might expect. Their stories ranged from "I'm in China and it's hard for me to be included when our team calls are East coast-centric US time" to “I have always found it challenging to be a quiet person in open source meetings.” I was fascinated because I thought these women would talk about how difficult it was to be a woman in open source yet it turned out to be more focused on being a quiet person or feeling geographically isolated, both of which make inclusion a huge challenge.

When it comes to our current global team, I think these same two topics surface again. I think that time zone inclusion is probably one of the most important topics to ensure inclusion for our global team. How do we help team members feel included while also working a balanced, time zone appropriate schedule? There are a lot of tools we can leverage as leaders whether it’s call recordings or virtual teaming tools like Mural however at the end of the day, it seems there is always someone who has to take the early or late call. I’m sure I will be working this issue for years to come but the important point is to stay focused on it, always thinking about the team members in other time zones and cultures and what we can do to help them feel more included.

Q: You headed a culture project for the advocacy group that helped empower and engage employees. Can you talk a little about the importance of an inclusive culture?

Within our organization at IBM, I lead an important culture project that I’m proud to say has helped drive positive culture change in our organization in the last year. We started this project about 2 years ago when employee engagement scores were reporting at lower levels than we found acceptable. To address engagement concerns, I proposed and led an organizational wide culture project -- which is managed, by the way, as any other high priority project and not as a “when we have time” project. We stood up this culture project alongside many other internal high priority code projects, and the result of that first wave is that we created our own code of culture, which is all about how we treat each other, respect diversity, and respect each other in our engagements. You can think of this just like a "code of conduct" in an open source community, but focused specifically on our organization and culture values. Another result of this first wave was our workload prioritization guidelines. Engagement was suffering a few years ago because many felt like the "fire drills" were coming too fast and frequent, so we created a guide to help us avoid fire drills and also successfully navigate those fire drills if and when they occurred. Last but not least, we developed a career workstream with a focus on ensuring managers had all the resources they needed to support career growth for their team members as well as a new roadmap for developer advocate careers that I mentioned in an earlier question.

Our work continues because with the new year came new cultural challenges. Fueled by a global pandemic and social injustices, we’ve defined a new slate of culture workstreams for 2020.

New ways of work - staying productive and engaged in a work-from-home world
Diversity and inclusion - increasing D&I support especially in light of recent social injustices
Driving innovation - internalizing open source principles to drive innovation

Every year, we're going to keep looking at how we can help positively grow our culture. It's the most important thing we can do as an organization and company overall, because as I said, if you take care of your team, they can and will take care of the business.

Q: Who out there in developer relations would you like to call out as doing an effective job?

Burr Sutter at Red Hat has been a fantastic partner working with us. He's an amazing, outspoken advocate in his own right. I think very highly of him and as busy as he is, spends so much time with us building bridges to the mutual benefit of both our developer advocacy initiatives.

Someday when I'm no longer at IBM? What I will be most proud of will be the inclusive culture we've fostered and the relationships I've made with this great team. Forging and maintaining these relationships is the best part of my job.

Thank you Johanna for sitting down with me and sharing your thoughts.

Build an Edge-enabled Intelligent Chatbot with PubNub and Watson Assistant

Dave Nugent 🌉 — Thu, 13 Aug 2020 16:25:07 +0000

Chatbots are a rapidly growing market for applied artificial intelligence. But what separates a smart chatbot from a virtual assistant that's just not helpful? We want to make sure our chatbot understands the end user's intents and is able to effectively respond in an intelligent manner. At the same time, we want to make sure our chat infrastructure is globally-distributed for a low-latency and high-availability experience.

In this tutorial, we'll combine the Watson Virtual Assistant technology with PubNub's global data stream network to build a React-enabled chat application that can intelligently respond to user queries.

Create your Watson Assistant
Get your PubNub Keys
Remix your Glitch code
Next Steps

Sign Up for your Free Watson Assistant

Click here to sign up for your IBM Cloud account. You'll need to provide your Email address and choose a password:

ℹ️ Unable to verify your email address? Sometimes outlook.com and gmail.com domains get flagged as spam. Try using another email account.

Verify your email address by entering the verification code in your confirmation email.

Enter your personal information, click Next and then click Create account.
Acknowledge the IBM Privacy policy.
Congratulations! Your account was created, and now we can create our Watson Assistant. On the top right of your screen, click Create resource +.
Now you'll see all the Services and Software you can create. We'll type assistant into the search box and press enter. Then click the box for Watson Assistant.

Make sure the Lite plan is selected -- you'll get 10,000 messages per month free. In the bottom right corner, click Create.

Congratulations, you've created your own Watson Assistant! For the rest of this lab you'll want to take note of the API key and URL under Credentials. Then, click Launch Watson Assistant so we can configure the assistant.

Now we can take a look at the different ways we can configure your assistant:

Let's go over these briefly:

Intents are purposes or goals that are expressed in a customer's input, such as answering a question or processing a bill payment.
Entities represent information in the user input that is relevant to the user's purpose.
Dialog is where you'll add nodes that define how your assistant will converse with your end users.
Options is where you'll hook in your webhook URLs, if you decide to do other integrations in the future.
Analytics tells you the metrics of the conversations, and how well your assistant understands what end users are saying to it.

We could spend a lot of time building our own skill, but instead, we can import a pre-built one!

On the left of your screen, click on the Assistants icon.

Click on your assistant (mine is called My first assistant)
Click the triple dot menu and click Swap skill.

Click Use sample skill and then click Customer Care Example Skill.

Yay, we've populated a sample skill with intents, entities and dialog notes!

Now let's grab our API details. At the top of the page, click the left arrow next to Assistants.

Click the triple dot menu in your assistant and click Settings.

Take note of your Assistant ID and API key.

Create your PubNub Account

Next we'll create a private PubNub channel and get our keys by creating an account. Click here to get started.

You'll need to copy down the publish key and subscribe key from your PubNub project. Keep a note of these keys, we'll use them to send and receive messages inside our project.

Remix our Glitch Project

Glitch is a fun, collaborative coding environment that makes it really easy to re-use, or "remix" in Glitch parlance, other people's code.

Please visit our Watson PubNub Chat Project on Glitch. Once you click Remix, you'll duplicate that code into your own project.

After that, follow the instructions in the README.md in order to complete the workshop.

Next Steps

Red Hat Marketplace is a collaboration between Red Hat and IBM that allows you to buy, deploy and run applications across your public, private and hybrid cloud deployments. If your company makes cloud software, you can also sell your software direct to customers through Marketplace.
Check out other Watson posts on the PubNub blog.
Bother Dave on Twitter

Everything You Need to Run a Meetup from Home

Dave Nugent 🌉 — Mon, 27 Jul 2020 19:20:14 +0000

Over the last couple months, I've created a pretty sweet setup for running meetups -- including the IBM Developer SF Meetup -- and the ForwardJS conference series from my home. Let me show you how!

Desk
External Monitor(s)
Webcam
Lighting
Headphones
Microphone
Wireless Charger
Desk Chair
USB Hub
Water Bottle

ℹ️ Note: There are no affiliate links on any of these products, and I have not been compensated to recommend any of them. Buy what you want! Use what you have! Buy secondhand if you can! Support Black-owned businesses!

Desk

When I first started working from home, I used a desk familiar to many work-from-home warriors: the dining room table. It's expansive, the appropriate height for a keyboard, has easy access to electricity and an abundance of natural light. However, I have four roommates, and the socialization that comes with everybody working around the same table could sometimes be distracting, especially when one or more of us took a video meeting.

Enter: the desk. I purchased a smaller model off Amazon to fit in my small bedroom. Since I'm average height and I don't have any specific ergonomic constraints, this worked well for me. When my mom started working from home, she needed a desk that would support her if she was sitting or standing, so I got her a slightly more expensive model. For each desk, remember to get something with a thin surface under your keyboard; no drawers, no keyboard trays, and nothing else that could cause an obstruction or raise/lower your hands more than necessary. When purchasing a standing desk, you have three options to adjust the height:

Manually-set height (pins or friction)
Manual Crank
Manual Counter-balance
Electric Motor

I would not recommend a manually-set height desks if you want to switch quickly between sitting and standing, as you'll have to clear the desk surface in order to re-set the height -- and let's face it, you are not going to do that.

Additionally, I would not recommend manual cranks or counter-balances (where you have to apply pressure to raise/lower the desktop) unless you are particularly fit and able-bodied.

Option 1: Inexpensive Fixed-Height Desk

SHW Home Office Computer Desk

Option 2: Standing Desk

Autonomous SmartDesk 2

External Monitor

When I was working at the office, I never used an external monitor, but now that I'm running meetups from home, I consider it essential. One amazing benefit of having an external monitor:

Screen Sharing Improvements

Now, I can share my laptop screen, while still having my speaker notes, chat session and webcam stream on my external monitor. This makes it easy to monitor what people are saying (including private messages from my coworkers) without taking up valuable screen real estate.

Productivity Improvements

When I'm not actively running a meetup or conference, I can also use my extra screen real estate to view my email, Slack, to-do list and other applications which are lower-priority but which I like to keep an eye on.

ℹ️ Note: Make sure you purchase a monitor that won't look too pixelated. After using a 27" monitor with 1080p resolution, it ended up looking much more pixelated than my Macbook Pro, and I returned that monitor in exchange for a 32" 4K display. The resolution on the 4K display was indistinguishable from my Macbook Pro. Don't go cheap -- you'll be staring at this for hours a day!

32" External 4K monitor: Monoprice

Monoprice 32in CrystalPro Monitor - 4K UHD, 60Hz, HDR, Aluminum Bezel, Ultra Slim, Height Adjustable Stand, IPS

Webcam

I know what you're thinking: "I already have a camera, Dave -- built into my laptop, FOR FREE!" Yes, you do! But beware free things: sometimes they are worth just what you've paid for them.

Here is a comparison of my Macbook Pro's picture of my face, versus my external USB webcam's picture:

I emphasize: these were taken at the same time, in the same location, under the same lighting conditions. However you'll notice that in the webcam shot, I look sullen, bored and tired (my friends will probably tell you this is what I look like in real life, but then my friends are jerks.) The quality of the webcam picture, however, is quite good. As long as I'm making recordings that will live on the internet forever, I think investing in an external webcam is a good idea.

ℹ️ BONUS: Invest in a small tripod to hold your webcam.

Vitade 1080p Webcam

Lighting

As good as your camera is, you will still look like a gray blob if your face is not properly lit. In fact, in some ways, lighting is even more important than your camera.

Even if you are blessed with an office with excellent natural light, it may suffer from issues regarding angle and color temperature. The angle that light hits your face can create shadows and light/dark contrasts; the color temperature of daylight is quite high (~6000K,) and sometimes you may like to balance that with a warmer color temperature (2700K) which can make you appear less zombie-like and reduce the appearance of bags under your eyes.

I originally bought this lighting kit to illuminate my speakers at in-person conferences, but these days I use it to illuminate my own mug. Probably overkill, but I'm sure you can find a 2700K light that costs less -- this could even be a lamp with a directional light bulb.

External Lighting Solution

Neewer 3 Pieces Bi-Color 660 LED Video Light and Stand Kit

Headphones

Anybody who has spent time on conference calls knows that attendees who don't use headphones produce the most feedback. Annoyingly, they don't hear that feedback themselves, so most of these people don't realize that they are the culprit.

When I first started working from home, I used a pair of AirPods Pro to participate in calls. However, these would run out of power after a few hours and I would have to recharge them.

Eventually, I plunked down for a gaming headset. This contains an integrated microphone boom that you can use during conference calls, and over-the-ear headphones that won't press your ears against your head for the entire day.

Dave's Headphones:

SteelSeries Arctis 5 - 2019 Edition

ℹ️ Tip: American Express Business Platinum cardmembers who purchase these headphones through the Dell store can get them for free, utilizing the Dell $100 credit. You'll need to follow the link from the AmEx benefits center and use your AmEx card to complete the transaction.

ℹ️ Tip: If you do continue to use AirPods Pro, set the noise cancellation setting not to Noise Cancelling, not to Transparent, but to Off. You will extend the battery life of your AirPods before they need to be recharged.

Microphone

I mentioned that the headphones I purchased came with an integrated microphone, but there is some benefit to the sound quality that comes with a dedicated condenser microphone. This is the type of microphone that you see radio personalities and podcasters use, and it actually requires an external power source in order to be sensitive enough to use.

Dave's Condenser Mic Setup

Aokeo 48V Phantom Power Supply Powered by USB

Zingyou Condenser Microphone Kit

Wireless Charger

You probably already have one of these, but I've found myself spending more time making sure my phone is plugged/unplugged as I walk around my house during the day. I also want to be able to look at my phone to see notifications, or potentially use it as a third screen. The solution? A wireless, slanted charger. You can keep your eye on your phone while it charges, and you can grab it immediately if you need to go for a walk. It's the perfect parts of both worlds!

Dave's Phone Charger

Ubio Labs Wireless Charging Station

Desk Chair

I'm so happy that I'm no longer sitting on the chairs in my dining room! I purchased a very inexpensive desk chair since I don't have many ergonomic requirements. I've found that I don't need adjustable armrests, and I don't need many adjustments on the angle or height of the back. My main goal was to get a chair on casters (rollers) that had an easy height adjustment and comfortable seat. You can probably find an acceptable one at your local home office store for well under $100.

USB Hub

Now that you'll be plugging in all these peripherals, it'll be nice to have them all plugged in at the same time. I ended up purchasing a USB hub and an additional Thunderbolt 3 to Dual-HDMI adapter to keep all my peripherals working together without any nasty plugging and unplugging.

In the middle of hosting a meetup, nobody wants to say "Thank you for the comment -- now let me unplug my headset and plug in my microphone so I can respond."

Aukey USB-C Hub

Water Bottle

Finally, and perhaps most importantly, I purchased an insulated water bottle. It's important for me to stay hydrated throughout the day, and a bottle of ice cold water (that doesn't cause condensation!) by my right hand is a constant reminder of that fact. During meetups, having water on hand is absolutely essential to keeping your throat lubricated and stopping your voice from sounding hoarse. Taking a minute to walk to the kitchen and refill it with water and ice is a great way to take a quick break and stand up from your desk, and drinking ice water is a healthy (and inexpensive) alternative to soda.

If you're a cyclist like I am, you can also re-use your cycling water bottle for desktop duty. These bike water bottles often have the added benefit of not spilling when they are tipped over!

Camelbak Podium® Ice 21 oz Bike Bottle, Insulated

Conclusion

That's how I used equipment and technology to conquer hosting meetups and working from home. In a future blog post, I'll cover the non-technical side of things and talk about how to create engaging content and connect with your attendees.

Driving DevOps Engagement with Cross-Functional Teams, Metrics & Authenticity

Dave Nugent 🌉 — Fri, 24 Jul 2020 23:14:06 +0000

Kris Bondi is a CMO who is very focused on adoption and developer or DevOps community engagement. She has served as CMO of Neura Inc, LogDNA and Bitnami, which was acquired by VMware. Since 2016, she has been a program advisor to HeavyBit Industries, helping early stage companies refine their go-to-market strategies. Kris and I worked together when she was vp of global marketing and I was a developer advocate at Iron.io. I'm grateful that she's able to sit down with us about the often controversial relationship between DevRel and marketing.

What traits to DevRel and marketing share?
How can DevRel and marketing enable each other?
How do you remain authentic?
As a marketer, what's your golden rule?
What can't you do any other way?
How do you measure community engagement?
How is DevRel perceived in the boardroom?
How do you build out a strong DevRel team?
Who is doing developer relations effectively?

Q: Kris, you come to DevRel with the trained eye of a CMO. What traits do effective developer relations and effective technical marketing have in common?

Both developer relations and marketing programs work best when you are not obsessed with the short term sale, but rather focused on how your product works within a larger ecosystem, and why developers use your product. So for example, if my company is in the Cassandra space, my DevRel and marketing teams may focus on the Big Data communities adjacent to it. Your company doesn't stand alone, it's always part of a larger ecosystem.

As an example, when you look at a really good CNCF project, you'll notice a lot of people contributing either independently or part of different companies. Those contributors and community members have come together and decided that they're going to use this project as a way of contributing to a common cause. They're contributing to a community effort. A company that focuses solely on their own products doesn’t understand that isn’t the way the world works anymore. Even if that company is initially successful, it will never reach the same level of success as if they genuinely care about the community. (This also applies in the consumer world as well, but that’s not where I spend my time.)

If someone is looking to get into the right mindset for this, there’s a great book that is seemingly unrelated called It Takes a Tribe, by Will Dean, the creator of the Tough Mudder racing series. He talks about creating races that are purposely designed not as a competition but as something most people can’t complete without the help of others.

Q: With so much common ground, how can developer relations and marketing teams enable each other?

Developer relations is a marketing function. Developers will often say that they hate marketing; I argue they hate bad marketing. If I am selling to you and pushing, pushing, pushing-- well, that’s just sucky marketing. Your most effective marketing efforts will be built around education, because that lays the groundwork for future communication. Providing valuable information to targeted developer communities is marketing. Even when it isn’t officially part of the marketing team, DevRel is performing a marketing function and needs to be integrated with the marketing functions.

On the other side, developer relations teams often don't get enough credit for users and customers who have signed up or increased usage as a result of their DevRel efforts. For example, if a developer advocate has been on a podcast, or written an article, or run a workshop with a partner organization and that effort generates a future customer, DevRel should get credit. Unfortunately, these efforts are not always effectively tracked. Doubling down on this narrative, the users that come from DevRel efforts are often more valuable than a lead acquired from what is assumed to be traditional demand gen such as a white paper download or someone responding to an ad. The contacts coming out of the DevRel experience are more educated and more loyal because they’ve had a more authentic experience. The reality is you need both types of experiences.

Q: How do you remain authentic in developer relations and marketing?

Authenticity is about who you hire. I’ll give you an example of authenticity done poorly: A number of years ago I was at a Go conference, where my company had some speaking spots and a booth. I was at the booth with our developer community manager, Cassandra Ferrara, who has gone on to an impressive career as a DevRel leader. Cassandra is not only smart, she truly loves the developer communities that she’s a part of. Next to us was a booth of a vendor whose booth staff casually said something to imply that he did not think highly of the conference attendees: “Oh I drew the short straw, now I have to stand here and deal with developers all day.” My response was “Our company founders are developers, and developers are the reason we have a company.” He happened to be a salesperson, but no matter their role, that attitude infuriates me. If your company and staff are not supportive of the developer community, then you need to find a different industry! Engaged developer communities are the reason your company exists. If you are rolling your eyes and thinking developers are difficult, there are plenty of industries for you. Go sell insurance. In our world, it is necessary to truly love technology and respect the community.

I realize that because of my title as CMO there are limitations of what kind of authentic communications I am effective at, so I take a lead from the dev advocates where I work. Our developer advocates function as a feedback loop into the company. The reason why I have started giving people the title of developer advocate as opposed to developer relations is that these people are not only evangelizing about our products, but are also advocates for developers or DevOps inside the company. In other words, their job is to not only communicate about the company and our industry, but to give feedback to our company, our product team, and the marketing team overall about what’s happening in the community.

Your company and staff remain authentic by becoming engaged in your community. That means you need multiple people in the company engaged in the community, whether it’s attending meetups, online events, writing articles, tweeting, going to events, etc. Part of the secret to doing this well is to have people engage in whatever way feels the most comfortable to them. Not everyone is comfortable presenting or writing, but if you have a team member who wants to become involved, you can find a way that works well for them. This again speaks to the need for an integrated approach. If you have one person or a group of people who are off to the side as your DevRel team and not integrated, it’s difficult for the company to be authentic, no matter how effective that DevRel team is.

One of the favorite things about Bitnami, was that so many people in the company were engaged with the community. Bitnami didn’t have an official DelRel title, but many people in the Kubernetes community will know Adnan Abdulhussein for all his project contributions. Adnan was a software engineer at Bitnami, but he does everything I love in a DelRel pro. He participates in the community because he truly cares about it. At every company I join, I encourage employees throughout the organization to care and engage with the communities we serve. Being part of external communities seems to bring an internal community into the company, and makes the company a better place for everyone to work. It also attracts other enthusiastic talent.

Q: As a marketer, do you have a golden rule when approaching developers or DevOps?

I started my career as a journalist, so everything for me starts with a story. From that story, you identify how to engage people and why they care. The core of each story is always the same, but how you communicate it is different depending on what your audience cares about and their priorities. For example, If I’m a developer, and I have five urgent things on the list of things that I need to focus on, just because your tool will enable me to do a sixth thing, that doesn't automatically make me care. Make me care! Tell me, for example, that I can easily drop code into a YAML file and it’ll enable something needed in the build and deployment process, and will get me the end result I want. Don’t just tell me “Oh you’ll be able to do this thing in deployment” that I don’t care about. A lot of what marketing needs to do is focus on the full business and the full business includes education and adoption. In fact, if you’re in a DevOps world that should be a core piece of your efforts.

Q: In your optimal world, what are you able to accomplish with DevRel that you can’t do any other way?

I often talk about engagement and adoption and how they’re interconnected, but there is something that goes a step farther. There’s a drum I’ve been beating that is sometimes misunderstood. The ideal approach to communities is to be part of a movement, but I don’t mean a sales movement. I think it’s more important than ever for people to feel that they’re part of something bigger. Kubernetes, I would argue, is not only orchestration but a movement: it’s a different way of approaching things. We have it in our regular lives, being part of the Black Lives Matter movement, that’s bigger than yourself. Companies do themselves a disservice when they focus so much on themselves that they don’t think about how they fit into the rest of the world or what they’re really enabling. They also hurt themselves if they consider DevRel function the “other.” If they have a DevRel function as an afterthought or a separate piece as opposed to “this is who we are,” they are doing a disservice to their users, their potential users, and quite frankly to the people on the DevRel team.

Q: You've spoken emphatically about the value of community engagement, and also some common missteps. On the flipside, how should companies approach measuring the value of their community engagement?

Laura Santamaria is a great developer advocate with whom I worked who used an engagement tracking form when she was out and about. It’s pretty straightforward with questions such as: How many people attended my talk? With how many people did I speak one-to-one? How many of these people signed up for a trial? How many talks or written pieces have come from me helping someone else in the organization? For most organizations, I don’t think this level of detail is needed, but if an organization is KPI- or MBO-heavy and looking for a results-oriented approach to measurement, this is much better than tracking how many times someone presented at a meetup.

Beyond the initial engagement, DevRel, and marketing overall, should be affecting the selling process. For example, if someone is in a sales cycle and they engage with DevRel, they are likely to move fast in the selling or onboarding process. This is where attribution and advanced attribution comes in: not only tracking from where a lead comes, but also tracking the trigger point that caused them to be more active. Because DevRel may contribute to adoption, it has revenue implications, particularly for companies with a usage-based billing. It also helps reduce churn and contributes to upsell.

There’s another tactic I actually hate: when young companies try to go-to-market through hackathons. I came into a company and their initial approach was to do a lot of hackathons. While reviewing the adoption trend numbers with the operations person, I asked “On this chart, I see that in December there’s a big upswing in usage, then it falls in February and again in March. The usage in March looks like the usage in November. What happened?” The answer: it was a hackathon go-to-market approach.

If people don’t see any long term value from using your technology and are just using it for a prize at a hackathon, you’ll end up with a bunch of unsupported apps and no real growth — from that perspective it was a waste of time. Hackathons are good for education, but not as a go-to-market strategy. Once we put a true go-to-market strategy in place, you could see a steady increase. We went from 5,000 end users deployed (where the company was after those hackathons) to a million end-users within nine months. If I was just measuring initial engagement, I would be happy with hackathons. That leads to my last measurement-related point: measure based on how an action can affect something (engagement, conversion timeline, adoption), not just to collect data points.

Q: One perspective I think many DevRel professionals would be interested in is your knowledge of how developer relations is perceived at the executive level and in the boardroom. What can you tell us?

From a high level, from the business perspective, we look at DevRel as the engagement and adoption function. To have a successful DevRel program, you need other things to be happening in parallel. For example, the best developer or DevOps-focused companies have a clear business model, enabling them to know from where their revenue is actually coming. They understand how to move from users to buyers. That’s not a DevRel responsibility, but without the engagement and adoption work the buyers won’t purchase.

The companies that aren’t successful expect DevRel to be sellers (that’s never a good thing). These companies haven’t thought through their path to revenue. There was one point a few years back where “every company should have open source and then the revenue will just come.” Obviously, there needs to be actual thought into licensing and an actual business plan.

When you ask about how DevRel is seen at the board level, it ultimately comes down to the experience of the board members. Many board members, because they are investors, have become more sophisticated about what the business plan is and how the developer community fits into it. However, it takes a go-to-market person to come in and explain how DevRel fits into the company’s plans. The board’s job isn’t to dictate; the board approves.

Q: How do you build out a strong DevRel team?

It's important that your developer relations team knows what’s expected of them. My approach has always been to customize the DevRel role to that individual person. If you’re somebody who loves to write, I’ll make a chunk of your role writing-based. If you are someone who loves to do presentations but is less interested in writing, we’ll lean on you to do more presentations. That’s not something I knew originally, but that’s a way I’ve grown as a manager: I’m much more flexible around playing to somebody’s strengths rather than writing a job spec and expecting somebody to be a perfect fit.

I also think that for smaller teams, the first person in the door has to establish things, but they also get to select which part of the role they will specialize in, especially if you know that a second and third hire is coming. This specialization can help guide who you look for in future hires, and can make your team members happier overall and improve their work quality. There are some people who want to code and want to be involved in projects — if I can have somebody on my team who is spending a lot of time contributing to one or two open source projects, and have my company listed as a contributor to those projects, that is incredibly valuable. Your software engineers are probably already doing this; even if they are not listed with a DevRel title, they are doing developer relations work.

Q: Who in DevRel would you like to call out?

OpenTech Response OpenTechResponse is the group that has created the open community’s crisis response framework. Like any open source collaboration, it came out of a driving determination to fund a way for technology to help a larger need. In this case, it was how the open communities can respond to COVID-19 as well as future crises.

While OpenUK CEO Amanda Brock, DataStax VP of DevRel Patrick McFadin, and OpenTeams CTO and Co-Founder David Charbonbeau, and myself have each brought our expertise to shape OpenTechResponse, ultimately it’s the developers who are volunteering for COVID-19 response-related projects that will make the difference. To help people find projects in need of their skills, OpenTechResponse now has a dev volunteer-to-project matchmaking tool created by OpenTeams.

Formulating a DevRel Strategy for your Early-Stage Startup

Dave Nugent 🌉 — Fri, 17 Jul 2020 01:44:56 +0000

A friend of mine is starting a developer relations department inside their startup and asked for my advice in fostering a community to grow awareness and sustainability. While I wrote this for their company, I have a feeling this could spark ideas for others, so I'm lightly obfuscating it and publishing it here. In case you're not interested in DevRel, I'm also including a bunch of pictures of Steve Ballmer. Enjoy

First, let's narrow down the business goals we will drive.

DevRel can help with these high-level business goals:

Drive adoption of the product as a useful tool
Raise awareness of the company as a thought leader for the developer personas you are targeting
Decrease time-to-deployment/time-to-revenue

Next, we can formulate our ideals. These will guide us as we create our community and interact with it.

We will interact with our community adhering to these ideals:

Authenticity - Show our whole selves as advocates for the developer.

Advocacy - Become a touchpoint for their interests and goals.

Community - Identify with the kinship of goals of our customer base.

Gratitude - Be thankful to the community for feedback and insights.

Measurement - Justify our assumption with numbers when we can.

We drive goals and adhere to ideals with...

Strategies

Build authentic relationships.
Help, mentor & inspire developers.
Collect feedback and surface internally.
Automate these strategies with tools.
Empower the community to achieve our goals.

Tactics to achieve these strategies:

Blog Posts
- On Our Blog
- Partner Blogs
- External Syndication
Webinars
- Interviews
- Panel discussions
- Twitch coding sessions
Virtual Conferences
- Third-party
- Run your own
Virtual Meetups
Email Newsletter
Whitepaper / Technology-adjacent Book
Relevant Website CTAs
Community
- Developer feedback
- Developers help developers

And measure this with (these are kinda straight to the point but that's how I like it)

Metrics:

Unique views per artifact
New users per artifact
Paid users per artifact
MRR per artifact
Total revenue per artifact

This is a lot to unpack. How do you focus? Make a timeline. Here's an example for your first month and first quarter:

First Month:

Craft content calendar and webinar schedule
Identify external contributors and internal collaborators
Establish metrics
Identify call-out potential through existing content
Identify strategies to amplify content
Clarify long-term content goals
Identify customers for interviews

First Quarter:

Measure & iterate on first month goals
Use content data to begin hosting webinars
Schedule 2nd quarter content to build a series to thread into an e-book
Choose platforms to build out peer-to-peer community engagement
Identify external syndication sources & development partners
Start customer interview series
Plan 3rd quarter virtual conference

Hopefully these will give you some ideas for your first developer relations hire.

Before we go...

There are a few non-traditional points I'd like to make in closing:

Don't let your first developer relations hire do things entirely as they've done them before. Every product and company is different, and you don't want to tie yourself down to strategies, best practices and tactics that may not work for your own company. You know more about your product and customers at the outset.
Start measuring. It's never too early, but it's tempting to focus on completing deadlines instead of building a successful long-term program.
Focus on your Ideals. Building a supportive and sustaining community built on gratitude will do a lot for your long-term program. If you build a program directly on metrics and content, that's marketing, not DevRel.

Next Steps:

Check out Sarah-Jane Morris's interview DevRel Engineer One: Building a Developer Relations Team from The Ground Up
Get a retrospective from someone who started a DevRel team in Seven Years Scaling a Data-Driven DevRel Team with Brian Munz

Seven Years Scaling a Data-Driven DevRel Team

Dave Nugent 🌉 — Thu, 16 Jul 2020 19:11:50 +0000

Brian Munz built and scaled the developer relations team at Qlik, a data analytics and visualization company. In his time at Qlik, Brian inaugurated and scaled the DevRel team with more full-time hires, organized Qlik's approach to developer events and content, and built out the 40,000-strong developer community Qlik Branch. After leaving Qlik last week, I caught up with Brian to get his thoughts on the benefits of community, the perils of managing a DevRel team across departments and his advice for anyone spinning up a DevRel team today.

How did you build a community for 40,000 developers?
Where does DevRel fit inside a company?
How do you balance authenticity with business value?
How has open source affected developer relations?
How do you hire for DevRel?
What should a new team do to prove value?
Who is doing developer relations effectively?

Q: Your team built and curated a 40,000-strong developer community around open source projects. How did you manage that?

When I first joined Qlik ten years ago they had just opened their first "web developer" piece of the product. This part was brand new and not widely used, but myself and a few other Qlik employees saw that it could be very powerful and started building solutions for it. It became very easy to add complex functionality to Qlik with a background as a JavaScript or web developer, and we would get requests from inside and outside the company for the code behind these solutions. Eventually we were getting so many requests, we decided to aggregate all these projects in one spot and further open source these extensions.

The user base and community grew organically based on the value these open source extensions provided. Occasionally, corporate customers would find our developer portal and get frustrated because they’d think these open source extensions were actually a supported part of the product, and we would have to gently tell them “this isn’t for you, this is for developers.” This is one reason it's important to differentiate between developers and “power users” of your product. At Qlik, these power users were actually also called “developers."

As the community continued to grow in number of users and number of open source projects, I founded a DevRel team to accommodate this new, different community that was turning out to be pretty useful to developers.

One of the missions of our DevRel team has been to grow and foster the Qlik Branch community. I remember being up all night until 6a.m. hand-coding a landing page so that developers could get early access the morning of the announcement of the program. We got 600 people to sign up for early access that morning. Now, it’s up to 40,000 developers and 750+ extensions open sourced on the platform. With that kind of growth comes challenges: how do you make sure the cream rises to the top? How do you ensure that developers are still finding the community useful? Those are tough questions that still need to be answered, honestly.

The Branch community sped up innovation in the ecosystem for extensions, and created a rising tide that lifted all boats. Consultants made a bunch of money by uploading open source extensions and then upselling support, or gaining leads from the community visibility.

Q: Where does DevRel fit inside a company? I've seen it placed under Marketing, Product, or even reporting to the CTO.

DevRel has been in five different verticals inside Qlik in the last seven years. This may sound chaotic or inefficient, but there are few reasons where moving DevRel to different teams can make a lot of sense. I mentioned previously that our team was small and scrappy, which made our jobs a lot of fun -- however, it also caused some friction when it came time to define KPIs and objectives after changing teams.

When moving teams, in some cases we were in certain parts of the organization when we needed to be there. For a while we were aligned with the Partner organization, which makes sense because at the time our partners were getting their heads around the value of the open source extensions we were curating. Later, we moved under Product, which was helpful as we were gathering feedback from developers and bringing it back into the product. There’s no one answer as to where DevRel fits, and I encourage you to think that DevRel could be most effective in different departments at different times.

However, DevRel teams can run into trouble if you’re reporting in a category where your goals are mis-aligned. For example if our team were to report into a less technical sales organization, our goals of serving the community could conflict with the goals of the organization. You also want to make sure you have the ability to grow a community with the right kind of leads instead of just aiming for a number. Growing a community haphazardly can make the community too “fluffy” and the community VIPs can get lost in the mess.

Q: How do you stay authentic to your community while providing value to the business?

Our approach was to use honesty and transparency to foster a vibrant community where developers provided value to each other, and by proxy, to the Qlik ecosystem.

Our Qlik Branch team was always scrappy, moving fast and asking for forgiveness instead of permission. There was some word-of-mouth that salespeople would worry that our team would "ruin" sales calls because we were always honest with developers -- we placed community and developers over marketing and hype. If we saw that a potential customer had bad information -- for example, paying for ten servers when they only needed one -- we would politely inform the customer that there was a more effective way to accomplish their goal. Philosophically, developer relations needs to serve the community that they build.

That honesty can pay itself back because it engenders loyalty to the program. When you’re honest with somebody who is used to being spoken to politically, it is refreshing. Our development partners would sometimes read press releases and product announcements, and then come to us and ask “what’s really going on?” “Is this feature ready for us to code something with it?” If it wasn’t ready, we would always tell them, because if they tried to build on a feature or API that failed while they were building it, it would be immediately clear that we were not being straightforward, and their time was wasted as a result. A number of these people are now close friends. You may not be able to quantify honesty and loyalty in terms of KPIs, but you see the community sticking around, and you generate invaluable buy-in from developers because you’ve made and valued those relationships.

One of our DevRel hires was actually somebody who was too outspoken for a role elsewhere in the company -- but inside our team, we saw that transparency as an asset, not a liability.

One reason for this is that developers deeply value honesty. Everybody says developers don’t want to be marketed to, which is somewhat true depending on how you define marketing, but what developers really want is an honest proposition that gets to the core of how your product can help them and what they’ll need to do to be successful. If you're able to provide that honesty, in the future when a developer needs your software, they’ll use it. This makes it sound like it’s easy to market to developers, but it’s not: I’ve worked with really skilled developer marketers who are experts at their craft. But you do have to tread a line where if you get too cutesy or dishonest you can shoot yourself in the foot. The value you create here plays out in the future where developers will know they’ll get the answer they need by consulting you, even if the answer isn't "use my product."

Q: Developers can be huge boosters of open source inside a company. How has an open source philosophy affected your DevRel work?

Today, Qlik open sources a lot of the libraries that power their APIs, which is a big change from when I joined. I’m not going to take any credit for that change, but my point is to illustrate that it can be a slow process to convince people that open source is a good thing. Seven years ago, I would have to put material into my presentations about what open source means and why open source is a good thing. Some old school companies didn’t see the value.

In fact our first incarnation of Qlik Branch was built on a proprietary tool: some management at the time was uncomfortable with open source, to the extent that they wanted us to use a paid product that had support; we later found out that the support was not effective at all. I preferred to use an open source tool, and when you look at the two communities the open source one was incredibly active. Eventually, we decided to rebuild Qlik Branch ourselves on our own engine and open-source the code. So, we were running Qlik Branch on Qlik’s products. We wanted the community to know that we believed in the product so much that we incorporated it into Qlik Branch, and the community could even clone and modify the Qlik Branch source code for their own use.

Q: Let's talk about someone starting a developer relations team today. Who should your first hires be? How would you approach building out the team?

I would break this down into skills, diversity, flexibility and empathy.

First, a note about roles and classification: In larger companies it can be difficult for human resources to understand differentiation between a DevRel engineer versus a regular developer. Occasionally you'll need to list a DevRel hire as an engineering hire for bureaucratic reasons. Make sure that the role is senior enough to match the responsibilities of a position in developer relations -- there can be a tendency to mis-classify developer relations engineers as junior developers. In fact, I consider DevRel engineers a different type of role because you have to be able to speak, communicate and teach effectively, on top of engineering responsibilities. DevRel requires extra skills and it can be tough getting corporate hierarchies to understand that.

Skills
Hiring a devrel team today, I would start by defining what you’re looking to get from DevRel. Based on those goals, what are you going to focus on? I’ve found that some DevRel hires have been good at hanging out with customers and helping them architect a solution, while others were better at going and speaking at a high level to a large audience. So not only do you have to define what you’re trying to get out of DevRel, but also: what skills that you need do your candidates have? It’s very rare that people will have all the skills you're looking for (although these people do exist!) Perhaps you'll find someone who is just incredible at cranking out videos and webinars, and they can focus on that and not be distracted with traveling to conferences. Don’t think of it as having each member do the same thing; he or she needs to be managed to focus on their skills.

Diversity
Focus on the diversity of your team. Years ago, there was less attention on diversity at a corporate level, but these days you really shouldn't build a non-diverse DevRel team. The parts of the developer community that I love tend to be more vocally inclusive and vocally compassionate, and open to diversity and accepting people who are different. By portraying yourself that way and architecting a team that way, it makes your team more open to developers out there who are approaching you.

Flexibility
When looking to build out a team and hire, another thing would be to hire people who are flexible. You can put DevRel hires into an inflexible system, but really you need to take opportunities as they come. People need to be free to follow the paths that present themselves; maybe you’ll meet somebody at a conference and be able to build out a great collaboration.

Empathy
Also, it has to be people you get along with. I’m not breaking new ground by saying this, but I’ve come across some genius developers who I know I will never get along with; having that person on a team and their toxic presence will outweigh the benefit of what they’d be able to produce.

Q: What advice would you give to a person or company starting a DevRel team who is concerned about the value proposition?

Ask yourself what’s the reason you want your company to develop a DevRel specialty. Some companies have been told that they need DevRel but they don’t necessarily understand it. There are many misconceptions about DevRel, especially due to the focus on community and fun integrations. DevRel can be goofy: a drone that controls a toaster!

There will be people in the company who won’t understand the value of that, and will want to use those resources to sell more products. In some companies DevRel's customer interaction comes at the conclusion of the sales cycle, helping customers who have already purchased the product; in other companies it’s at the other end, handing off leads to the sales team. You have to make sure expectations are set properly: if everyone believes that getting eyes on the product will get the product sold, and you put your KPIs around that, good for you; if it’s thought leadership, then that’s great too, but make sure you have consensus.

An effective DevRel team can be this rough-around-the-edges, adaptable system: it’s always able to be fully engaged with the community and serve your KPIs. Developers are always developers at heart, and you won’t lose the enterprise developer if you decide to do a weird wacky project. Even if the developer’s boss doesn’t understand a blog post that comes across as "wacky" or "fun," the developer will understand the abstraction, and the developer can translate those expectations to the enterprise.

Q: Is there anybody out there in the DevRel world who is doing something great that you want to shout out to?

Donald Farmer said we had empathy with the developer community, and the people I admire are along those lines. I appreciate people in the community who are nice, have empathy, and don’t take crap from anyone but also represent in that way which is pretty important and should be valued more for sure, being able to see people as they are. Every developer has to be new at some point, even new to the community. Have empathy for them and they’ll be loyal to your community, and you’ve been able to help lift someone up into a new level in their career. It’s a long process and it’s difficult to track metrics on a member by member basis, but you can see the value in the value of the community. The benefit of creating these relationships, whether the bigwigs understand it or not, is to create loyal users of your product and making hundreds of empathetic, positive relationships in your life.

Here are some people I'd like to specifically call out. Most of these people aren’t “deep cuts” to the DevRel community, but they’re the ones inspiring me most nonetheless:

Sarah Drasner
Cassidy Williams
Scott Hanselman
Tomomi Imura
Of course all the DevRel people I’ve worked with at Qlik Nick Webster Alexander Thor Ana Nennig Rey Riel Wuzhong Zhu Tracy Russel-Beck and this weirdo named Dave Nugent

Thank you Brian Munz for giving this interview.

DEV Community: Dave Nugent 🌉

Three Free Ways to Learn Kubernetes and Red Hat OpenShift

1. OpenShift Open Labs

2. Earn your Build Smart on Kubernetes Badge

3. Try.OpenShift.com

Resources

Valuing Partner Developer Advocacy and AIOps

Table of Contents

Q: Developer relations programs vary between companies, and each company has their own approach. How does DevRel provide value in the context of partners?

Q: Can working with partners improve your DevRel messaging?

Q: It seems like developer-focused companies are falling over each other to build partner ecosystems. How do you evolve DevRel partnerships into an ecosystem?

Q: How do you separate partner advocacy from other ways of interacting with business partners? What is developer advocacy in the context of ISVs?

Q: Let's get down to brass tacks: what tactics are most effective working with partners and ISVs?

Q: What metrics do you use to measure the success of your ISV advocacy?

Q: What is AIOps?

Q: What codebases have you been working on?

Q: How did you get into developer advocacy?

Q: Who in DevRel is doing awesome things that we should know about?

Adding Google Auth to Kubernetes Clusters with Red Hat OpenShift and IBM AppID

Table of Contents

Create your IBM Cloud Account

Grab your Kubernetes/Red Hat OpenShift Cluster

Create an AppID Instance

Resources

Deploying Scalable Java Microservices to Enterprise Kubernetes using Red Hat OpenShift

1. Create your Account

2. Grab your Red Hat OpenShift Cluster

3. Installing your Red Hat OpenShift Operators

3. Clone the code!

4. Create kafka.yaml

5. Building the Microservices

6. Deploying the Microservices

7. Accessing the Live URL

Resources:

Enterprise Java Developer Relations and Community Engagement

Table of Contents

Q: You've worked a lot with Java. How has Java developer relations changed with the introduction of hybrid cloud and Kubernetes?

Q: How is Java DevRel different from developer relations for other languages or audiences?

Q: How does Free/Open Source software impact developer advocacy efforts, especially in the Java ecosystem?

Q: How did you get started with developer relations?

Q: What keeps you going? What motivates you to wake up every morning and make the world a better place?

Q: Who in DevRel is doing things that you want to call out?

Massively Scalable Realtime Voting Deployed on Hybrid Cloud

Who should read this post?

Table of Contents

Step 0: Get your Red Hat OpenShift Cluster

Step 1: Get Started with Twilio Sync

Step 2: Deploy Your Application to Red Hat OpenShift

Step 3: Link it all Together: Run your Hybrid Cloud Application

Conclusion & Next Steps

Resources

Global Developer Relations with Empathy and Compassion

Table of Contents

Q: We both work at IBM, which is a massive company. How difficult is it to prove the value of developer relations to executives above you in the corporate hierarchy?

Q: These days, many enterprise companies place high value on adopting open source solutions as opposed to proprietary ones. From a developer relations perspective, is it easier to advocate for open source solutions?

Q: You run a very large team, and something that always comes through in your communications is empathy and compassion. Why do you devote so much time to messaging these topics?

Q: Some issues can't be solved by individual contributors, and these "blockers" can impact productivity. How important is eliminating blockers?

Q: Is developer relations more affected by blockers because of the cross-functional nature of DevRel teams?

Q: How did you get into DevRel?

Q: IBM recently rolled out a career path for developer advocates, so that they can progress and be promoted without being categorized as programmers or managers. How important was this to your team?

Q: Your team easily spans a dozen time zones. What are some difficulties you've overcome growing a team to this size?

Q: How do opportunities for diversity and inclusion manifest themselves in global teams?

Q: You headed a culture project for the advocacy group that helped empower and engage employees. Can you talk a little about the importance of an inclusive culture?

Q: Who out there in developer relations would you like to call out as doing an effective job?

Build an Edge-enabled Intelligent Chatbot with PubNub and Watson Assistant

Table of Contents

Sign Up for your Free Watson Assistant

Create your PubNub Account

Remix our Glitch Project

Next Steps

Everything You Need to Run a Meetup from Home

Table of Contents

Desk

Option 1: Inexpensive Fixed-Height Desk

Option 2: Standing Desk

External Monitor

Screen Sharing Improvements

Productivity Improvements

32" External 4K monitor: Monoprice

Webcam