Developer relations down the stack

July 21, 2019 devadvin

IBM recently closed the acquisition of Red Hat for $34 billion, underscoring the huge and growing importance of hybrid cloud infrastructure. My colleague Marek Sadowski has become a subject matter expert in containers, Kubernetes, and server-side Swift, although he started out as a full stack developer advocate, a robotics startup founder, and an entrepreneur.

Marek Sadowski presenting

Marek has 20 years of enterprise consulting experience throughout the United States, Europe, Japan, Middle East, and Africa. During his time at NASA, he pioneered research on virtual reality goggles for the system to control robots on Mars. After founding a robotics startup, Marek came to work at IBM. I talked to him about his experience in DevOps advocacy.

Marek Sadowski presenting in a classroom

Q: One of your focus areas in developer relations (DevRel) is containers. How is advocating for a DevOps technology different than advocating for an API or application?

Good question. When working with containers, engineers think more in terms of the plumbing and ideas of DevOps and the ease of expanding your infrastructure footprint. In contrast, when you talk about APIs, you try to make application development the center of gravity for the discussion.

When discussing APIs with developers, you talk about how one could consume the API in a robust way. Let’s take the IBM Watson API as an example. Our team will talk about how you can create and run SDKs for developers to consume APIs in their own language, such as Swift (for mobile) or Java (for enterprise). You look at the consumer of your API and discuss how you can produce the API, protect yourself, and do the billing.

Getting back to containers, you speak more about plumbing of the cloud when discussing container technology. How do you manage containers? Expand them? Manage their workloads? Deliver and test new versions?

It quickly becomes apparent that these are two separate concepts. Containerization deals with how your back end is working and proper maintenance of your application, which attracts people from a DevOps background. When you talk about APIs, that’s a completely different story. Your thought paradigm changes to be the point of view of the consumer. How does the consumer find the API? How can developers consume the API?

I speak at conferences on both subjects areas. I’ve found that people who develop applications are more interested in the look, feel, and developer experience of the application. Whereas, with containers, it’s more about back end, load balancing, and seeing issues from a system administrator’s perspective.

Q: Many people are familiar with DevRel with a focus on software engineers, but DevOps is a different community entirely. How do you focus on that community?

There is a division. Everybody is interested in new things like Kubernetes and Docker, but not too many want to perfect their skills to the point that it’s their daily job. So many developers want to know how to spin up a container and a service inside the container, put it in their resume, and be done with it. Developers may be interested because it’s fashionable or it’s a buzzword. However, you can find a lot of people who are running services in containers and have specific questions: sysadmins who want to monitor containers and assure security, load balancing, and other aspects of administration. It’s a completely different audience from developers who consume APIs and create a cool web application. They are two different communities and you have to give each community different content.

For example, in a hackathon, it’s very difficult to create large deployments in containers. It’s about an optimization of development and operations more than application coding.

Marek Sadowski with other IBMers

Q: How have you had to change your approach to DevRel when moving to DevOps advocacy?

Previously, when I ran workshops focused on application developers, they usually had a few goals: understand our API, consume data from API endpoints, and create a simple “Hello World!” type of application. Developers in these workshops ask questions about high-level ways of architecting applications, for example with Watson, in mobile applications or web applications, or a chain of processes.

On the contrary, when I speak about DevOps and containers, developers in the audience want to spin up the services, see how they scale up and scale down, investigate how the services behave when something is failing, and how to ameliorate security issues. It’s a completely different approach. They are not interested in building something new; they want to perfect their approach to deployment.

Here’s an analogy I can give to people new to this field. It’s like inviting a painter and a plumber to a party. They both do similar things, yet the painter wants to make a painting that you can hang on the wall, and the plumber will rarely speak about the type of piping he’s using inside your walls. Both are doing something in your house, but the painter is thinking about the people they will attract and the paint (our APIs) to ensure a pleasant viewing experience. Whereas, the plumber just wants to get the job done and never touch it again. The plumber wants to make changes as rarely as possible and focus on stability, while the painter wants to create more new paintings. They have different approaches based on their different goals.

Q: You also give talks on Swift, specifically on the server side. Most people know Swift from the iOS development side, so why is it useful on the server? How do you get developers to think of it as a server language?

Server-side Swift is a relatively new development. I compare the current state of server-side Swift to where Java was 24 years ago. In 1996, I started writing a server-side application using Java. It was a novel concept at that time! The same thing is happening now with Swift, as developers are moving the Swift language to the server. There are a lot of reasons why. One of the simplest is that you write in the same language on the server as you do for your mobile app, and in that way you can use the same data constructs, thought processes, and personnel resources on both systems. You don’t need different systems or frameworks to talk to the database or the cloud.

Every mobile app nowadays asks you to connect to the internet for AI, messaging, and social media. Even simple games allow you to exchange information or have a conversation with people all over the world. If your app and back end are written in one language like Swift, it makes these data exchanges simple and transparent.

Some people say Swift is a fashionable language to learn. Since you have the option to write apps in Java or JavaScript, you can also write them in Swift. Apple made Swift open source, similar to the way Sun Microsystems opened up Java. You can now write applications in the cloud or on any platform. For example, OpenWhisk allows you to write event-based Swift functions in the cloud without any DevOps code.

With Swift, developers are attracted to the beauty of the language and the ability to write one language from mobile to cloud to make your application better and easier to maintain. You can enjoy writing in your language of choice and expand the capabilities of the environment you love. If you are an iOS developer, maybe you can become a full-stack developer. Developers love the story that they can become something more and participate in the full stack development process.

Marek Sadowski at a meetup

Q: How did you get into developer relations?

I had just come to the United States from Poland as the founder of a startup, and the purpose of the move was to expand my company. They say that 99% of startups don’t succeed right away, and founders often need to bootstrap while in an existing job. I was told that working in the cloud is the key factor in a lot of industries, but I had little exposure to those technologies. On the other hand, I had built up skills talking to investors, and as an entrepreneur, I was able to understand what was important to startups. I also had a robust background in Java development and different IT technologies; I had a career as an architect supporting banks and other EMEA enterprises as a Java professional, demonstrating systems to customers.

There was an opening for a mobile-first developer advocate, and despite having no mobile or cloud experience, I convinced the interviewer that I was the perfect candidate due to my ease of speaking with developers and presenting technical subjects in an accessible manner. I enjoy explaining complex topics in a simple way through demos and example projects.

My hiring manager asked me to build a small mobile app as an employment test, which connected to IBM Cloud to exchange information between the user and a back end. I enjoyed the task and found I was good at it! After two years, I migrated to more cloud technologies and more IBM APIs. Eventually, I started to find interest in Kubernetes and containers, and realized containers are a field with amazing growth potential.

I must say, the thing that attracted me the most to DevRel was the opportunity to learn and convey new technologies to developers out there, and use my talent for explaining complex things in a straightforward manner.

Marek Sadowski snowboarding

To get in touch with Marek, feel free to reach out on any of the channels listed on his IBM Developer profile page or see him speak at an upcoming IBM Developer SF Meetup.

Previous Article
Artificial intelligence for minors by minors
Artificial intelligence for minors by minors

Learn how two IBM summer interns created a full-functioning basketball chatbot with IBM Watson.

Next Article
Use a Solution Starter to kickstart your Call for Code submission
Use a Solution Starter to kickstart your Call for Code submission

Use a solution starter to kickstart your Call for Code solution. Submissions close July 29, 2019!


Want our latest news? Subscribe to our blog!

Last Name
First Name
Thank you!
Error - something went wrong!