This week’s Pipeliners Podcast episode features Scott Williams of EnerSys Corporation returning to the podcast to discuss the key technological developments around developing pipeline software applications for the cloud.

In this episode, you will learn about the risk factors associated with moving to the cloud, how advances in technology have supported the development of cost-effective cloud-based pipeline technology applications, and what the future looks like for whether SCADA will move to the cloud.

Pipeline Applications for the Cloud: Show Notes, Links, and Insider Terms

• Scott Williams is the Development Manager for EnerSys Corporation. Connect with Scott on LinkedIn.
  • EnerSys Corporation is the sponsor of this month’s Pipeliners Podcast episodes. Find out more about how EnerSys supports pipeline operations compliance, audit readiness, and control room management through the POEMS software suite.
    • ComplyMgr is a new software module from EnerSys that simplifies PHMSA compliance and streamlines the PHMSA audit process for pipeline operators. [Watch this video and consider scheduling a demo.]
• Cloud environment (or cloud computing) refers to an off-site hosting location where applications, data, and business processes are stored, owned, and managed by a cloud provider. “Moving to the cloud” is the process of moving information away from on-site or on-premise hosting environments to the cloud environment.
• SCADA (Supervisory Control and Data Acquisition) is a system of software and technology that allows pipeliners to control processes locally or at remote location.
  • RTUs (Remote Telemetry Units) are electronic devices placed in the field. RTUs enable remote automation by communicating data back to the facility and taking specific action after receiving input from the facility.
• Latency is the amount of time allotted for data to be transmitted and received in a SCADA system. Network latency is typically dependent on the number of RTUs and other devices on the network and the demands placed on the SCADA system.
• SQL (Structured Query Language) is a standard code language that is used in database programming and queries.
  • Microsoft SQL Server is a relational database management system developed by Microsoft. As a database server, it is a software product with the primary function of storing and retrieving data as requested by other software applications — which may run either on the same computer or on another computer across a network.
  • Sybase was a relational database server acquired by SAP that was used to manage and analyze information in relational databases.
• PowerBuilder is an integrated development environment owned by SAP since the acquisition of Sybase in 2010.
• Root Level Technology (n/k/a WALT Labs) is a cloud strategy partner that supports the migration to the cloud.
• Digital transformation refers to the adoption of digital technology to transform how companies do businesses by automating processes, replacing legacy technology, and integrating technology into the overall business strategy.
• Internet 4.0 (a/k/a Fourth Industrial Revolution) refers to the modern connection of people, systems, and devices as part of the Internet of Things (IoT) and Industrial Internet of Things (IIoT).
• Edge Communications is a method of building out the architecture for structured communication from edge devices in the field to a host server using connectivity to transmit the data. When evaluating the capabilities of your SCADA systems for transporting data, it’s best to consider which method of communication fits your operation.
  • Poll Response only sends data if requested by the host. This creates limitations because you may need to wait up to 15 minutes for the full data package to be received.
  • Publish-Subscribe protocol is a form of edge communications that allows edge-of-network devices to publish to a broker. Clients connect to this broker, which then mediates communication between the two devices.
    • MQTT (Message Queuing Telemetry Transport) is a publish-subscribe protocol that allows data to move quickly and securely through the system and does not bog down the system with unnecessary requests.

Pipeline Applications for the Cloud: Full Episode Transcript

Russel Treat:  Welcome to the Pipeliners Podcast, episode 157, sponsored by EnerSys Corporation, providers of POEMS, the Pipeline Operations Excellence Management System, compliance and operations software for the pipeline control center, recently releasing ComplyMgr software to streamline audit readiness. Find out more about POEMS at enersyscorp.com.

[background music]

Announcer:  The Pipeliners Podcast where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology projects and pipeline operations. Now your host, Russel Treat.

Russel:  Thanks for listening to the Pipeliners Podcast. I appreciate you taking the time. To show the appreciation, we give away a customized YETI tumbler to one listener each episode. This week, our winner is Matt Argo with Magellan Midstream Partners. Congratulations, Matt. Your YETI is on its way. To learn how you can win this signature prize pack, stick around for the end of the episode.

This week, Scott Williams returns after a fairly long period of time since the last time he was on the podcast. We’re going to be talking about developing pipeline applications in the cloud. Scott, welcome to the Pipeliners Podcast.

Scott Williams:  Hi. Good to be here, Russel.

Russel:  Good to have you back. It’s been a while. I think it’s been 70 episodes since we had you on last time.

Scott:  Just a few.

Russel:  [laughs] What have you been doing since the last time you’re on the podcast?

Scott:  Oh, my goodness. Dealing with the whole health struggles like everybody else has, of course. One big thing I think is the top of our show that I’ve done completely in the COVID world, which is kind of interesting, is gone from zero to pretty respectable with cloud stuff.

Russel:  Let’s talk a little bit about your background, just a little context for the listeners. Tell us a little bit about your education, your career, and what you do.

Scott:  Let’s see. My degree is in computer science from University of Texas, Longhorns. I had to put that on there for you, Russel.

Russel:  I appreciate that. You guys support your school.

Scott:  That degree was way back in ’95. I was already working for a systems integrator before I graduated. Systems integration isn’t quite development, but along the way, there’s always a need for utilities or even full-blown applications. I have a lot of experience in development in general and development supporting SCADA systems or measurement systems or related activities.

Russel:  A lot of experience in automation and communications and dealing with the various things you need to do with that kind of data reports and displays and all that kind of stuff?

Scott:  Certainly. All the way from certain SCADA systems allow you to develop what you could characterize as plugins in various software languages to web applications with SQL server back-ends and the whole deal, Windows services, long-running utilities, like communication servers, for instance, so all those different kinds of things.

Russel:  Just to give the listeners a little context, Scott and I have known each other and had been working together for quite a long time. We started out in the ’90s working on a measurement application, building it in Sybase and PowerBuilder. If you’re a developer, and you don’t know what that is, that just means that Scott and I’ve been doing this a while. [laughs]

Both of us have grown up around the control room, measurement systems, data collection, and almost all of that with on-premise systems. We’ve seen a lot of transition in what’s going on and that. We had been in a conversation for quite a long time about getting to the cloud.

This last year, we went from zero to cloud. That’s really what I wanted to talk about. Scott, why were we talking about doing the cloud, and why was the cloud where we needed to go, at least before we knew what the cloud was?

Scott:  We have a new product called ComplyMgr. It’s document management around regulatory documents and company documents at a really, really high level. The reason we decided we wanted to go with cloud is I would say there’s a lot of hands-on, but more of a case of whenever new documents come out or updates to documents.

We want to be able to get them out to customers quickly and not have to send a bunch of files to the customer and say, “Here’s a set of directions on how to get them installed, get them loaded on your system.” We can just make it happen. It’s not like it’s a big software update. It’s more of a big data update.

Supporting customer systems when they’re in the cloud, and we can directly connect to them is a lot easier than trying to walk somebody through all these different things.

Russel:  Exactly. If you think about regulatory where there’s constantly things happening around rulemakings, advisory notices, and all kinds of other things that happen in the regulatory world, but the need to keep all that updated is pretty high, and if you have 100 customers, and you’ve got to send something to every one of those 100 customers, and every one of those 100 customers has to do something to get those documents up, that’s a problem.

It’s a whole lot easier if you have 100 customers, and you just add the documents for them or make the documents get added — however you determined to streamline that and so forth. From a support standpoint, you wanted to be current and quality for your customers. It just makes a whole lot more sense to be able to access that as more of a single, monolithic database.

Scott:  Exactly.

Russel:  What did you think the cloud was when you started versus what do you think the cloud is now?

Scott:  Back in my previous life, before I started working with you, Russel, I had a side business. We had some servers that we hosted at a data center. We did the whole — it wasn’t called the cloud back then — cloud offering. We had to do all of it, all the switches, all the firewalls, all the gear, all the servers, get it all wired up, get it configured correctly.

We had to go through all those steps. There was a fair bit of work. Up until I started working on this project, my vision of the cloud is that kind of deal, but somebody else is managing the physical resources; I just had to deal with the machines themselves. I knew the different providers had a lot of different capabilities beyond what I just described, but I hadn’t explored them all that much.

Russel:  Scott, I would tell you. I had the same idea because I can go all the way back to the ’80s and talk about data bureaus or data centers and application service providers and such. This idea of having somebody else handle the infrastructure has been around for a long time.

When I first started hearing about the cloud, I was like, “Oh, well, that’s the same thing I’ve seen for the last 20 years, branded five different ways, branded a new way.” I don’t know that I’m knowledgeable enough about the cloud to talk about this with the right language. I think there’s probably two classes.

One class would be they’re going to provide you infrastructure. In other words, they’re going to set up a server for you, and then you have the access to it, versus what Google, Amazon, and Azure are doing where it’s all software. It’s all software.

When we started diving into this, that’s pretty shocking to me. I really had no idea. It probably displays my ignorance of that subject matter a little bit, but I had no idea just how advanced some of that stuff is.

Scott:  When I was in the learning phase, there is a lot of different capabilities that we saw there — I didn’t mention it — when we were using Google Cloud. I’ve spent a lot of time exploring what the Google Cloud offerings are. For the most part being, from a server perspective, we’re using virtual servers, which isn’t wildly different than setting up your own server in the cloud, except you don’t have to.

A few clicks of the keyboard and clicks of the mouse, and I have another computer set up, with Windows installed, ready to go. That’s pretty nice. Some of the advanced things — I don’t know if I wasn’t prepared for — I’ll say that are different than what I expected. They have what they call Cloud SQL. Instead of sending up a machine and installing Microsoft SQL Server on it, I just say, “Hey, I need a SQL server machine,” and I don’t even have to remote into a machine to manage Windows or do anything like that.

I just have, “Here’s a connection to a SQL server. Ta da,” and there it is. It’s set up. Want to add some databases, add some users, I just use my usual tools, and I can do those things, but all the minutiae of managing the database, managing the server, managing the install of SQL, none of that is my problem.

Russel:  For people that don’t understand software development, if I’m going to stand up a SQL server, I’ve got to decide a whole bunch of questions about, “Well, what gear do I need? How much RAM? How much disk space? What processor?” On and on and on.

I’ve got to do my install, and then I’ve got to do all my configurations. I would say that just time, the savings for setting up a SQL server, even once I have the gear doing it in the cloud with something like Google Cloud versus doing it on a machine four to one, five to one at least.

Scott:  Oh, at least. Let’s say I take a database backup of a database that I was preparing, and I have this backup. It’s like, “Okay, this database is ready,” I can go into the tools, and I can say, “Hey, I need a whole new server database. I want to make a database, and here’s some certain criteria. Upload this backup file and apply it.”

Not with counting, if it’s a huge database backup, obviously, that takes time. If you discount that an hour, [laughs] that’s really fast.

Russel:  For something that would take days otherwise, if you already had the gear. The other thing to the same point that was also compelling to me is just how advanced the security and infrastructure is around the cloud.

I can get in the cloud and set up a test environment, start setting stuff up, and isolate it from the world pretty easily versus if I’m trying to do that in my own shop, I’ve got to build a network. I’ve got to configure that network, and I’ve got to make sure that network’s isolated.

The level of effort there just to do it, assuming you have all the gear, and you know what you need to do, the level of effort there is days and gear versus an hour in the cloud.

Scott:  Don’t get me started on licensing. With SQL Server, you have core licenses. You have socket licenses. You’ve got user licenses. You’ve got “type of use” licenses, I think. I’m not sure what they call it, but it’s an Internet-facing database versus a private corporate database.

All these things, you have to struggle with this licensing. Whereas the cloud stuff, it doesn’t really matter. I specify a version of SQL, and I use the resources. It says, “This is what it’s going to cost you.” It’s like, “Thank you very much,” and I’m off.

I don’t have to worry about getting all those Microsoft details right and getting Microsoft angry at me when I do it wrong.

Russel:  [laughs] Exactly. We’ve been talking a lot about speed of deployment and complexity of deployment. Certainly, one of the things I learned about this as we were going through the process, brought in the experts, and were playing 150 questions, we just worked to the death asking questions.

One of the things I learned is that a lot of this is, it’s just what you’re doing in the cloud’s just different. There are similarities and alignments, but fundamentally, it’s different.

Scott:  The things that you’re doing are the same things you’d do if you did it yourself. The way you go about it and some of the terminology is definitely different. In the Google Cloud, I have a firewall. I have firewall settings. I have servers. I have database servers. I have connectivity between them.

It’s all the same stuff, but the way you go about it’s a little different, and the tools are a little different. Definitely, everything has a different name. That’s the problem — the biggest struggle — is there’s a lot of products. Knowing which one that you really want, at least for us, getting some time from some experts really, really accelerated that process.

Russel:  Not to mention, make sure you don’t get more than what you need.

Scott:  Certainly.

Russel:  Everything that you get has a cost, and I might be able to use something that costs a dollar a month, or they might have something else that would work, and it costs $100 a month, but I don’t need to spend $100.

That’s the other thing too about this whole process that was so extraordinarily compelling to me. We had a new product. We’re ready to get it ready to go to market. It took us from the time we started on the cloud deployment until the time we had something we could show to customers, it was a matter of a couple weeks.

Scott:  We’ve spent one week with the experts getting, let’s say, a sample set up, and getting introduced to all the technology. A few more weeks, making sure we had exactly what we wanted and then put the app up. Not all that long, maybe four weeks, maybe.

Russel:  It was two weeks before we had something, and then we were starting to feel comfortable, and four that it was solid.

Scott:  It was fast.

Russel:  It was very fast. We spent, in terms of Google services, like not even $1,000. If we’d have bought gear to do this, the gear alone would have been a minimum of $25,000, and we wouldn’t have had near the ability to scale it up.

Scott:  That’s one of those things that’s pretty fantastic. With the monitoring tools, I can look at the health of the SQL server, see how busy it is, and see if I’m loading it. If I need to add a CPU, I need to add some memory, or I need to add some disk space, it’s pretty easy. I don’t have to go buy new hardware.

Russel:  Yeah, and you don’t have to open the case up, install it, and find out it doesn’t work. [laughs]

Scott:  When you’re buying hardware, you got to get that right or close from day one. Whereas the cloud, you can test it a little bit and see if you need more or not.

Russel:  That’s right. If you don’t need it, you can take it out and not pay for it. It’s really compelling. What I would say I learned is that the cost of the infrastructure is a fraction of the cost of buying the infrastructure.

The speed of deployment, particularly setting up a new environment, is a fraction of the speed of doing it in your own infrastructure even if you do it in a cloud infrastructure. The security is out of the gate probably stronger than what most small to medium businesses could do easily.

I would say that the support, the ability to get help, is probably…I would say this. I’ll make a shoutout to Root Level Technology because they were really material in helping us in this. If we hadn’t had access to those experts, we would have burned weeks and weeks and weeks trying to learn this stuff, and we would have not had nearly as strong of a solution.

Scott:  We could very easily be paying for more than we need right now.

Russel:  Certainly would be, probably by an order of four or five. I think that’s absolutely true. I want to transition a little bit, Scott. The cloud’s pretty mature, pretty accepted for business applications.

There’s people that are doing infrastructure as a service. There’s people doing software as a service. There’s people doing combinations. I want to talk about, what would it take to put SCADA in the cloud?

I think you could argue that there are some companies out there that are doing SCADA software as a service, but those folks are mostly measurement type applications or process management. They are not process safety applications. I’m talking about SCADA from a process safety standpoint.

I’ll talk a little bit about the history of SCADA. SCADA started out as a big, monolithic solution. A bunch of engineers with some computer gear, probably a Unix box, and they built everything out from scratch all the way from the RTU, the communications infrastructure, the hardware. All the software was custom. That’s where we started.

Over time, we have migrated to where the communications are pretty generic. The field devices are pretty generic, and they need to be configured. We’re using the Internet and the company-wide area network to move the data from the field to the servers.

The applications, the server infrastructure, and the network infrastructure are generally managed by the IT group, not always but generally. Certainly, the network is managed by the IT group most often. We’ve come from a place where SCADA was a big, monolithic solution to where it’s really the integration of a whole bunch of pieces and parts.

How do you think, or what do you think would be required to take modern SCADA from a critical safety standpoint, get it into the cloud, and have the industry be comfortable that that was the right solution?

Scott:  I think it comes down to managing your risk. If I go back just a handful of years — not that long ago — I was visiting with a customer, and we looked in their communications room. They had a large room with racks of communications gear. They dealt with all the communications from their facility out to the field.

You had the various servers using that communication gear, then the various machines, the various workstations running the screens the controller sat in front of. Out until they used carrier communications, at some point, they’re on AT&T, Worldnet, whoever, to actually get the data transmitted.

Most of that gear was under their control and was in the same facility, very low latency, high bandwidth, at least around the gear itself between the servers, the workstations, and the top-end of the communications.

Now, when you move all this to the cloud, your communications are going from the field to — let’s call it — centralized locations that then get it up to the cloud. In general, cloud communications are using the Internet as the primary backbone.

Once you get to the local site where the master radios are, obviously, that’s radios. From there to the cloud, that’s the Internet. If you don’t have a strong Internet connection, your coms can drop out. Once you get in the cloud, you have your — I’ll use air quotes, you can’t see me — “servers” in the cloud, and there’s all your data.

Now, your workstations, your consoles, what the guys are sitting at are at their local location. Again, from those consoles to the cloud, that’s your Internet connection. You need a strong Internet connection. Nowadays, getting a strong Internet connection isn’t that hard. It used to be a lot more struggle.

Russel:  If you could get it, it was hard to get it in a way that you had higher reliability in it. That’s changing, too, particularly, if you’re in some kind of city center.

Scott:  At the house, here I am at home with COVID, myself, my wife, my two kids all use the Internet every day for various meetings, classes, and so on. Obviously, my Internet has to be pretty sound to not cause troubles.

So far, we haven’t had any problem at all. This is just at the home. Corporate locations, there’s other things you can do to increase reliability even beyond what you have at the house.

Russel:  It’d be equivalent to having both Comcast and AT&T at the house. If the Comcast dropped out, you would hope you’d still have the AT&T.

Scott:  Right. You gear up to manage that, and it’s seamless to the people inside. If you’re running SCADA from the cloud, you’ll want to do that. You’ll want to use two different providers to provide backup and all the smart things that go with that.

Take that relatively low risk and cut it again by a factor of 10, then have an alternative. Is there an alternate way to get to your cloud services in case things go really bad, or you have guys in the field that can manage it temporarily if things go really bad?

Russel:  You think about it. You do that now, right? If I have a total communications loss because some critical leg of my network drops out — and that happens — we have mechanisms in order to respond to that. The value of having the gear on-premise is not really that high, unless it directly connects to the communications infrastructure, like I’m direct-wired to the master radios.

Once I bridge to the Internet wherever I do that, it really doesn’t make any difference if I have my gear on-premise or have my gear in the cloud as long as I’ve got good quality Internet.

Scott:  Likewise with the cloud. Make sure you do the right things. Make sure you’re smart about how you set up your cloud infrastructure. You still want to have redundancy. Just because you’re in the cloud doesn’t mean you can’t do redundancy. You still need to do it. You still need two servers.

Russel:  I think there are obstacles for us to get SCADA as critical process safety in the cloud. One of the biggest is redundancy versus recovery. Recovery being the ability to set up a new environment and start going again versus redundancy being it just moves in real-time to the redundant environment.

The vendors of software are going to have to get to the point that that stuff will work. I mean the application vendors, the guys that sell the SCADA stuff, are going to have to cloud-enable their toolsets for this to work.

Most of the software vendors are not there yet, at least in my understanding. I do think, however, that we could take the data part and put it in the cloud now. I think there’s some real value to doing that, and there’s a whole nother conversation around Industry 4.0 and digital transformation around that. The idea that with a publish-subscribe protocol…Let me get a little geeky here.

[laughter]

Russel:  Most of the other protocols are poll response, meaning I have a computer sitting someplace. It calls up a remote device and says, “I need a certain set of information,” and the remote device responds. That’s poll response. I send a request, I get an answer back.

The future of communications for data is publish-subscribe. The way that would work is the remote device says, “Here’s an update.” It sends that to a broker, and then the people that need that data go to the broker and say, “Hey, give me the latest update.”

MQTT — and anybody who’s working in SCADA and data communications is hearing about MQTT until they can’t stand it anymore — is a publish-subscribe protocol. It allows you to get a lot more data over a com link, and it allows you to manage latency.

One of the challenges with poll response is, every time I ask, I have to wait until I get an answer or until I know I’m not going to get an answer. That time is becoming more of a problem on many data communication networks than the actual quantity of the data being moved.

Scott:  Certainly. With the publish-subscribe model, it’s a matter of the equipment in the field or the publish-subscribe component that’s sitting there recognizes he has new data. Consider it like a mailbox and say, “Oh, here’s some letters that have to go out.” Whenever he can finally communicate up to the cloud, he sends all the letters.

You didn’t lose it. It’s sitting there waiting. As soon as communications are restored, all of it goes up. You’ve had a temporary outage for sure, but you don’t lose things because of that temporary outage.

Russel:  It’s just very much like email. I’ve got an Outlook client on my machine. When I hit the send button, it takes it to the exchange server. It sits there until the person on the other end says, “I want to get my mail.” That could be running many times a second or once a day, and it still all works.

If I’m disconnected for two or four days because I’ve been on vacation, we all know what happens then. All the data comes in when I reconnect.

Scott:  [laughs]

Russel:  I get my several hundred emails to slog through as I’m getting back to work.

Scott:  It’s always fun.

Russel:  I think that there’s actually a possibility that we’ll see the data part move to the cloud first.

One of the big reasons I think that’s true is there’s a lot of other people that need that SCADA data, particularly the data that’s beyond safety, things like engine analysis, vibration analysis, and things that third parties would need in order to evaluate machine reliability, things that third parties might need to do advanced analysis from a leak detection or some other kind of statistical analysis process.

I think many of those are going to be delivered as cloud services where you send me a data feed, and I send you back a data feed. That stuff gets a lot easier in the cloud than trying to build infrastructure and interfaces everyplace. I got to have that. How long do you think before we see some major company move its SCADA system into the cloud?

Scott:  I don’t think it’ll really be that long. The tricky part, I believe, is for the client interface. Traditionally, what you’re running on that workstation is what you classify as a thick client — meaning it gets all the data and all the information it needs — it shows the user what they need to see.

Contrast that to your typical website where the website sends you exactly what you need to see but not anything extra, so the actual bandwidth and latency. The late latency becomes less of an issue, and the bandwidth usage drops significantly.

When the SCADA ventures start to embrace that, have their clients be a little thinner in nature, not needing as large a data feed, that’s going to take you big strides, because now, having the server in the cloud and the client locally over the Internet just won’t be a big deal. It won’t just work.

The other alternative approach if somebody doesn’t want to go that route is the equivalent of remote desktop. I’m sure everybody, especially lately, has been using remote desktop a lot more than they have in the past. Short of watching a video over remote desktop, which doesn’t work very well, everything else, it says if you’re there. I do it every day.

There’s stuff at our office that I don’t have a replicant of it at home. I don’t want the large bandwidth hit of large datasets flying across the wire, so I remote into a machine at the office and do the work that way. I don’t notice that it’s a remote desktop. It feels just like a local experience to me.

Russel:  Certainly, the limitation in terms of putting critical process safety in the cloud is the user interface for the controller or operator of the system. That thing has to be highly reliable and has to have extremely good performance and virtually zero latency, at least, from an operator experience perspective. That’s the problem. That’s got to be solved to be able to do that.

Scott:  You got to build your clients to recognize that and operate that way. If you use any of the major players’ websites, they’re very responsive, and you can interact with them. You can get live updates depending on the site. That technology is moving forward very quickly.

Russel:  Like everything these days. What we ought to do, because we’re kind of getting a little long here, is to give people some teasers.

I am planning on doing some episodes, looking for some guys that are real industry experts and leaders in digital transformation and Industry 4.0 and what’s that going to mean for pipelines going forward particularly as it relates to the things that Scott and I have been talking about.

I would say that my key takeaway is there’s a whole lot of value in the cloud way beyond what I thought there was. There’s a lot less risk there than what I thought there was. There’s certainly some risk, but there’s a lot less than what I thought there was.

I think it’s coming. It’s going to be here probably sooner than we realize, or I’ll just pull some episodes together to help people start thinking about it and get prepared. Scott, do you have anything to add to that or anything you’d like for the listeners to take away from this conversation?

Scott:  I guess just a couple comments. If you’re looking at the cloud, find an experienced guide to help you get started. Keep in mind that security in the cloud is just as important as it is on-premise, and I say, even more so. Just be careful and take the time and the effort to make sure you do it right. You’ll probably be successful. I’m amazed at how fast these things went together.

Russel:  Ditto. I am completely blown away. Now, I’m asking the question, “Why didn’t we do it five years ago?”

[laughter]

Scott:  Exactly.

Russel:  Always a pleasure to have you home. You need to make it not so long coming on to be a guess because these are my favorite conversations.

Scott:  It’s been fun.

Russel:  They’re all my favorite conversations for all the other guys that come on as guests.

Scott:  [laughs]

Russel:  Scott and I have been doing this for a long time, and we do like the opportunity to talk about these things. Thanks for being a guest, Scott.

Scott:  It’s been fun. Thanks, Russel.

Russel:  I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Scott. Just a reminder before you go, you should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit pipelinepodcastnetwork.com/win to enter yourself in the drawing.

If you would like to support this podcast, please leave us a review on Apple Podcasts, Google Play, or whatever smart device podcast app you happen to use to listen. You can find instructions at pipelinepodcastnetwork.com.

[music]

Russel:  If you have ideas, questions, or topics you’d be interested in, please let me know on the Contact Us page at pipelinepodcastnetwork.com or reach out to me on LinkedIn. Thanks for listening. I’ll talk to you next week.

Transcription by CastingWords