Meet Pivotal Field Engineer Joel Rolfe. He believes the days of pager-duty are gone, or can be, with the help of Pivotal Cloud Foundry.
In this post, we have a Q&A with Joel to understand how his background at IBM and PacketVideo led him to Pivotal, how he has scaled apps to millions of requests per day, why he is excited by Pivotal’s product line, and the types of problems he helps customers solve. Joel provides a great profile for people looking to join Pivotal, and has experience realizing “you don’t need to build your own PaaS.”
Also, as you read, if you find interest in these topics that attracted Joel, you should know Pivotal is hiring field engineers!
Would you tell us about how you grew up?
Well, I grew up in Porterville, California, which is a rural Central California farming community. I was an “artsy” kid (or is that angsty?). I wrote a lot of moody poetry, wore funny hats, and told people I was going to be an author. I guess, in a way, I was right—although I didn’t know that I would be writing Java instead of English!
In my senior year of highschool, I got roped into an engineering club and was introduced to mechanical engineering, electronics, and programming. That led to enrolling in the Computer Engineering program at Cal Poly in San Luis Obispo, CA. I went in thinking that I wanted to work in hardware and robotics, but I found that my electrical engineering classes brought too much mental and physical pain (mental because of hard math stuff, physical because of my body’s ability to conduct current). So, I switched to computer science, and the rest is history.
Would you tell us about your work background?
Yes, of course. I started in software development while I was still in college, writing UIs in Visual Basic for a smallish point-of-sale software company. My first customer-facing experience was installing our software at a local candy store. I did a lot of QA to make sure the chocolate truffle SKU was working properly.
From there, I transitioned to software engineering and enterprise software architecture, where I’ve spent the last 13 years of my career, building content management software at IBM and then large scale premium content discovery and delivery applications post IBM.
As an example, one of my applications ingested music files, transformed them into appropriate delivery formats, and then offered them for download or as ringtones on mobile devices through an online storefront. This storefront was then branded and offered by multiple wireless carriers in the Americas. The system surfaced all kinds of interesting work for me—content clustering algorithms for generating radio stations on the fly, a custom enterprise search engine for Japanese content, merchandising systems, billing systems, and more. All of this had to operate at scale (millions of requests a day) within aggressive and punitive SLAs.
This taught me all kinds of important lessons like “never let them give you a pager” and “why’d you let them give you a pager” and “pagers are really hard to break.” But, it also taught me that deploying, scaling, monitoring, and maintaining applications in production is hard, really hard. During this time, I wrote more Puppet code than I care to mention, attempted to build pseudo-PaaS capabilities, and generally spent huge portions of my life trying to simplify and harden these capabilities. Of course, I didn’t know then that many of these problems had already been solved for me.
How did you end up at Pivotal?
Before I joined Pivotal (and only a few months back now), I had been architecting a web services platform for a brand new, premium video streaming service. We designed the system to be microservices oriented and to operate in a container-less context. Of course, we wanted it to be ridiculously easy to deploy—developers could just write web service business logic and everything else would work. We planned for automated deployment, injected dependencies, automagic routing, log aggregation to a log analysis platform, etc.
At the same time this was going on, I was talking with a field engineer friend who worked at Pivotal. As I started to read about Pivotal products, I realized that everything I had been busting my hump on for the previous 6 months was already available to me in Pivotal Cloud Foundry. It was also easy to get enamored by the absolute toy box that is Pivotal’s product suite. So, I started to get excited about the possibilities for me to not only learn all of these cool products but also to take on a new kind of customer facing role. Having been in product architecture for so long, I felt a significant draw to something new and to seeing lots of different architectures and problems instead of being zeroed in on one stack for years at a time.
After talking with the Pivotal recruitment team, going through the rigorous interview obstacle course, and seeing how much talent and momentum Pivotal had, I was convinced it was the right place for me.
In your words, what is your role within Pivotal? What are you most focused on?
Field engineers are in technical sales roles, and I am a member of the field engineering team in the Southeastern U.S. My role is to understand our customers needs and business problems, help them identify and understand the products within our suite that can help them, and then ensure they are successful with those products.
What challenges do you look to solve for customers?
Our ideal customer is looking to transform the way in which they deliver software. They might be struggling with long release cycles and stuck somewhere between waterfall and agile—a world in which great ideas spend 3 to 9 months floating aimlessly on the currents of some water-scrum-fall process. There are many challenges developers and ops people face. Creating new environments for developers is hard. Scaling applications is hard. Deploying new applications is hard. Innovating is hard. Being bold is hard.
Generally, I talk to a lot of people who see the need to improve these things and to improve their software development houses in general. Everyone is excited about DevOps, containerization, microservices, etc. But, there is also a sense that these things are all really hard you have to devote a big team of developers to writing Puppet or Chef scripts, and you have to create vast orchestration layers for scheduling and managing containers.
It’s exciting for me to watch customers here in the Carolinas realize that Pivotal Cloud Foundry makes all this complexity go away. We handle deployment. We handle orchestration. We handle wiring and telemetry and routing and patching and HA and all the other difficult bits in between. All of this is necessary for running applications and continuous delivery. And, all of it is fundamentally distinct from what our customers themselves should have to be really good at—writing applications that fuel value within their unique businesses, not managing infrastructure and repetitive, manual processes.
What else do you see Pivotal Cloud Foundry doing for your customers?
Ultimately, I see Pivotal Cloud Foundry continuing to iterate and provide greater efficiency for enterprise customers that are trying to redefine the way they create, deploy, and manage software. This could mean additional security options for controlling the locality of multiple applications or the ability to target specific applications to specific infrastructure. It could mean the ability to run and distribute applications across many data centers automatically from one centralized place. It could mean even tighter integration with SCM and CI tools and workflows. There’s also the challenge of supporting Windows-centric development shops that want to run .NET applications, which we see a lot of in the Southeast.
How does open source fit into Pivotal’s story for you?
You know that dream where you show up to work and realize you’re naked? If you’ve ever read one of those dream interpretation books, you’ll know that this dream means that you fear accountability or that you are hiding something. Open source code is code that has shown up to work with no clothes on. There is no hiding—crappy code is laid bare for everyone to see. Security flaws are laid bare for everyone to see. Linus’ Law states that “given enough eyeballs, all bugs are shallow.” Ultimately, open source software is transparent, and it’s just flat out better because of it. Not only do I know exactly what I’m getting and how it works, but I know I have an avenue to take if my vendor decides they want to go in another direction.
Open source is central to Pivotal’s strategy, and this transparency, along with the ability to leverage contributions from a large and growing number of foundation partners, is central to the value of products like Pivotal Cloud Foundry.
What do you like to do in your personal time when you aren’t living and breathing Pivotal products?
Glad you asked. I’m a closet musician and noodle around on my guitar daily, terrorizing my chocolate lab with my singing. I also like to collect instruments and pretend to know how to play them. In this vein, I’m constantly threatening my friends and neighbors with my plan to buy a trombone. And, one of these days, I’ll go through with it. Stay tuned for the webinar link.
When my schedule allows, I am also active at my local fire department, which is a hybrid paid-staff / volunteer department. This includes constant, incessant training and drilling. Sometimes this is fun stuff like breaking down doors. Other times it’s wet and cold stuff like hydrant relays in the middle of January. All-in-all, its a solid diversion from my inclination to sit in front of a screen all day long.
About the Author
