Welcome to the Pike Liners Podcast, Episode 157, sponsored by InterSYS Corporation, providers of Poems, the Pipeline Operations Excellence Management System, Compliance and Operations Software for the Pipeline Control Center, recently releasing Comply Manager, software designed to streamline PHMSA audit readiness, find out more about Poems at intersyscorb.com. This week, we're listening to the Pike Liners Podcast. I appreciate you taking the time and to show the appreciation, we give away a customized Yeti Tumblr to one listener each episode. This week, our winner is Matt Argo with Atmos Energy.
Congratulations, Matt. Your Yeti is on its way. To learn how you can win this signature prize back, 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, and we're going to be talking about developing pipeline applications in the cloud.
Scott, welcome to the Pike Liners Podcast. Good to be your Russell. Good to have you back. It's been a while.
I think it's been like 70 episodes since we had you on last time. Just a few. What have you been doing since the last time you're on the podcast? Oh my goodness.
Dealing with the whole health struggles like everybody else has, of course. One big thing I think is the topic of our show that I've actually done completely in the COVID world, which is kind of interesting, has gone from zero to pretty respectable with cloud stuff. Yeah, so let's talk a little bit about your background, just settle context for the listener. So tell us a little bit about your education, your career, and what you do.
Let's see. My degree is in Computer Science from University of Texas Longhorns. Had to put that on there for you, Russell. I appreciate that.
I appreciate that. Got to support your school. And that degree was way back in 95. And I was already working for a system integrator before I graduated.
So systems integration isn't quite development, but along the way, there's always a need for utilities or even full-blooded full-blown applications. So got a lot of experience in development in general and development, supporting SCADI systems or measurement systems or related activities. Yeah, so a lot of experience in the 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. Certainly.
And all the way from certain SCADI systems allow you to develop what you could characterize as plugins in various software languages to web applications with SQL Server backends and the whole deal. Windows services and long-running utilities like communication service for instance. So all those different kinds of things. Yeah.
So just to give the listeners a little context, Scott and I have known each other and have been working together for quite a long time. We started out in the 90s working on a measurement application, building it in Cybase and PowerBuilder, which is, if you don't know what that is, that's the major developer and you don't know what that is, that just means it's got and I've been doing this a while. So both of us have kind of grown up around the control room and measurement systems and data collection and almost all of that with on-premise systems. And we've seen a lot of transition in what's going on in that.
And we had been in a conversation for quite a long time about getting to the cloud. And this last year we went from zero to cloud and that's really what I wanted to talk about. So Scott, why were we talking about doing the cloud and why was the cloud kind of where we needed to go? At least before we knew what the cloud was.
Well, there was, we have a new product called Comply Manager and 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 there's, 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 and load it 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 and supporting customer systems when they're in the cloud and we can directly get on them, connect it to them is a lot easier and trying to walk somebody through all these different things.
Right, exactly, exactly. And if you think about regulatory where there's constantly things happening around rule-making and advisory notices and all kinds of other things that happen in the regulatory world, the need to keep all that updated is pretty high. And if you have a hundred customers and you've got to send something to every one of those hundred customers and every one of those hundred customers has to do something to get those documents up, that's a problem. It's a whole lot easier if you have a hundred customers and you just add the documents for them or make the documents get added to them and have a YouTube server to streamline that and so forth.
Just from a support standpoint, wanting to be really current and quality for your customers, it just makes a whole lot more sense to be able to access that as a more of a single monolithic database. Exactly. So what did you think the cloud was when you started versus what do you think the cloud is now? Well back in my previous life, actually before I started working with E-RUS, I had a side business and we had some servers that we hosted at a data center and we did the whole, it wasn't called cloud back then, but we did the whole cloud offering.
But 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. It was a fair bit of work. So 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. Well, Scott, 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. I mean, this idea of having somebody else handle the infrastructure has been around for a long time. When I first started hearing about the cloud, it's like, oh, well, that's the same thing I've seen for the last 20 years branded five different ways, branded a new way.
And I think there's probably, and 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 and Amazon and Azure are doing where it's all software.
It's all software. I think that to me was, you know, when we started diving into this, I thought that was, that's pretty shocking to me. I mean, I really had no idea. I probably displays my ignorance of that subject matter a little bit, but I had no idea just how advanced some of that stuff was, or is.
Yes. There's some, in the, when I was in the learning phase, there's a lot of different capabilities that we saw, if I didn't mention it, when we were using Google Cloud. So I've spent a lot of time exploring what the Google Cloud offerings are. And, you know, for the most part, I mean, from a server perspective, yeah, 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, you know, a few clicks of the keyboard and picks the mouse and I have another computer setup with Windows installed, ready to go. So that's pretty nice. But some of the advanced things that I don't know if I wasn't prepared for, but say that are different than what I expected, they have what they call cloud SQL. So 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, you know, here's a connection of, here's a connection to a SQL server. Ta-da. And it is, there it is.
And it's set up on some databases, add some users. I just use my usual tools and I could do those things. But all the minutia of managing, you know, managing the database, managing the server, managing the install of SQL, none of that is my problem. Well, if you think, if you think about that, you know, 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 quick questions about, well, what gear do I need?
How much RAM, how much disk space, what processor, on and on and on. And then I've got to, you know, do my install and then I've got to do all my configurations where, you know, and I would say that the savings just for setting up just time, just 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, 4 to 1, 5 to 1, at least, or at least, and if I had, let's say I take a database backup of a database that I was preparing and I have, you know, I have this backup and it's like, okay, this database is ready. I can go into the tools and I can say, hey, I needed a whole new server instance and I'll make a database and here's some certain criteria and upload this backup file and apply it. And you know, not with counting, if it's a huge database backup, obviously that takes time.
But if you discount that, I mean, an hour, which is really fast. For something that would take days, otherwise, if you already had the gear. And the other thing, kind of to the same point that was also compelling to me is just how advanced the security and infrastructure is around the cloud. Like I can get into cloud and set up a test environment, start setting stuff up and isolated from the world pretty easily versus, you know, if I'm trying to do that in my own shop, well, then I've got to build a network and I've got to configure that network and I've got to make sure that networks isolated.
And you know, it's just, again, the level of effort there just to do it. And you know, assuming you have all the gear and you know what you need to do, the level of effort there's days versus, you know, and gear versus, you know, an hour in the cloud. Oh, and then yeah, don't get me started on licensing. With SQL Server, you have what core licenses, you have socket licenses, you've got user licenses, you've got type of use licenses, I think, I'm not sure they call it, but it's you know, 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 you know, I use the resources and it says, this is what's going to cost you. That'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. Exactly. Exactly. Well, that we said we've been talking a lot about speed of deployment and complexity of deployment.
I mean, certainly one of the things I learned about this as we were going through the process and you brought in the experts and we're, you know, playing 150 questions, we just worked with the death asking questions. But one of the things I learned is that a lot of this is it's just what you're doing in the cloud is just different. It's just, you know, there are similarities and alignments, but fundamentally it's different. The things that you're doing are the same things you do if you did it yourself.
The way you go about it and some of the terminology is definitely different. But you know, in the Google cloud, I have a firewall, I have firewall settings, I have servers, I have database servers, I've connected between them. It's all the same stuff, but you the way you go about it's a little different and the tools are a little different. And you know, definitely everything has a different name.
That's right. The biggest struggle is there's a lot of products and knowing which one that you really want that's, you know, at least for us, getting it, you know, some time from some experts really, really accelerated that process. Well, not to mention, make sure you don't get more than what you need, certainly, because there's, you know, there's everything that you get has a cost. And I might be able to use something that costs a dollar a month or or they might have something else that would work and it costs $100 a month, but I don't need to spend a hundred.
Right. And then, you know, that that's the other thing too, about this whole process. It was so extraordinarily compelling to me. So, so 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 of weeks. Yeah. I mean, we spent, you know, one, one week with the experts getting a, let's say a sample set up and getting introduced to all the technology, and a few more weeks, making sure we had it exactly, you know, we had exactly what we wanted and then put the app up.
And yeah, not, not all that long, maybe four weeks, maybe? Well, it was two weeks before we had something and then we were, we were starting to feel comfortable in four that it was, it was solid. Right. It was, it was fast.
Yeah, it was very fast. And, and we spent in terms of just Google services, like not even $1,000. And 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.
Right. That's one of those things that's pretty fantastic. I mean, with the monitoring tools, I can look at the health of the SQL Server and see how busy it is and see if I'm loading it. And if I need to, you know, add a CPU or I need to add some memory or I need to add some disk space, it's pretty easy.
Yeah. I don't have to go buy new hardware. Yeah. And you don't have to open the case up and install it and find out it doesn't work.
Yeah. If you, yeah, when you're buying hardware, you kind of, you got to get that right or close from here. Right. Oh, yeah.
Oh, yeah. You can, you can test it a little bit and see if you need more or not. Yeah. That's right.
And if you don't need it, you can take it out and I'll pay for it. So it's, it's really compelling. So I, 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. And I would say that the support, the ability to get help is probably, I would say this, if we didn't have the experts and I'll make a shout out to Reel Level Technology because they were really material in helping us in this. If we hadn't had access to those, those experts, we would have burned weeks and weeks and weeks trying to learn this stuff. And we, we would have not had nearly as strong of a solution.
And we could very easily be paying for more than we need right now. Wow. Certainly would be probably by an order of four or five. Yeah.
Yeah. I think that's absolutely true. So I want to transition a little bit Scott and I'll talk about, so the cloud's pretty mature, pretty accepted for business applications. And 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 Skata in the cloud. So, I think you could argue that there's some companies out there that are doing Skata software as a service, but those folks are mostly measurement type applications or process management, they are not process safety applications. And I'm talking about Skata from a process safety standpoint. So, probably, I'll start, I'll talk a little bit about the history of Skata.
Skata started out as a big monolithic solution. You know, 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. And that's where we started. And over time, we have migrated to where the communications are pretty generic, the field devices are pretty generic.
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. And the applications and 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.
So, we've kind of come from a place where Skata was a big monolithic solution to where it's really the integration of a whole bunch of pieces and parts. So, how do you think, or what do you think would be required to take modern Skata from a critical safety standpoint and get into the cloud and have the industry be comfortable that was the right solution? Well, I think it comes down to managing your risk. So, if I go back just a handful of years, not that long ago, I was visiting with the customer and we looked in their communications room and they had a large room with racks of communications gear, and they dealt with all the communications from their facility out to the field.
And then you had the various servers using that communication gear, then the various machines, the various workstations running the screens that controller sat in front of. So, out until they used carrier communications, at some point they're on AT&T, whoever, to actually get the data transmitted. But 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. So, 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.
And in general, cloud communications are using the internet as a primary backbone. Once you get to the local site where the master radios are, obviously that's radios, but from there to the cloud that's the internet. And if you don't have a strong internet connection, your cons can drop out. And then once you get it in the cloud, you have your, I'll use air quotes, you can't see me, so air quotes 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. So again, from those consoles to the cloud, that's your internet connection. So again, you need strong internet connection. Now a day's getting a strong internet connection isn't that hard.
It used to be a lot more struggle. Well, and if you could get it, it was hard to get in a way that you had high reliability in it. Right. And that's changing to particularly if you're in some kind of city center.
Sure. Well, I mean, 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. So obviously, my internet has to be pretty sound to not cause troubles. And so far, we haven't had any problem at all.
So 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. Yeah, it'd be a good to have it. Yeah, be equivalent to having both Comcast and AT&T at the house. So if the Comcast dropped out, you would hope you'd still have the AT&T.
Right. And you say you're up to manage that. And it's seamless to the people inside. Right.
So if you're running Skater from the cloud, you'll want to do that. You want to use two different providers to provide backup. And all the smart things that go with that. But 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. Well, you think about 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. So the value of having the gear on premise is not really that high, unless it's directly connecting to the communications infrastructure. I'm directwired to the master radios. Once I go to the, 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 well as I've got good quality internet.
Right. And like I was with the cloud, you 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. Yeah.
So I think there are obstacles for us to get skated 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. That is the vendors of software going to have to get to the point that that stuff will work.
I mean, the application vendors, the guys that sell the scale of stuff, we're going to have to cloud enable their tool sets for this to work. But I think that even, you know, and 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 in the cloud now. And I think there's some real value to doing that.
And there's a whole other conversation around industry 4.0 and digital transformation around that. But the idea that with a published, subscribed protocol, so I'm going to get a little geeky here. So most of the older protocols or poll response, meaning I have a computer sitting someplace that asks, you know, it calls up a remote device that says I need a certain set of information and a remote device response. So that's a poll response.
I send a request, I get an answer back. The future of communications for data is published, subscribe. So the way that would work is the remote device says, here's an update, sends that to a broker and then the people that need the broker need that data go to the broker and say, Hey, give me the latest update. So MQTT and anybody who's working in SCADA data communications is hearing about MQTT till they can't stand it anymore, is a published, subscribed protocol.
And it allows you to get a lot more data over a comm link and it allows you to manage latency because one of the challenges with poll responses 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. And that time is becoming more of a problem of many data communication networks than the actual quantity of the data being moved. Certainly, with the published and tried model, it's a matter of the equipment in the field or the published, published, subscribed component that's sitting there recognizes he has new data. It's considered like a mailbox and say, Oh, here's, here's some letters that have to go out.
And then whenever he can finally communicate for the cloud, he sends all the letters. So you didn't lose it. It's sitting there waiting. And as soon as communications are restored, all that goes up, you had a temporary outage for sure, but you don't lose things because of that temporary outage.
Right. I mean, 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.
And it sits there until the person on the other end says, I want to get my mail. And that could be running many times a second or once a day and it still all works. And if I'm disconnected for two or three or four days, because I've been on vacation, we all know what happens then all the data comes in when I reconnect. And I get my several hundred emails to slog through as I'm getting back to work.
Always fun. Yeah. So I think that there's actually a possibility that we'll see the data part move to the cloud first. And 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 and vibration analysis and things that third parties would need in order to evaluate machinery, liability, things that third parties might need to do advanced analysis from elite detection or some other kind of statistical analysis process.
And I think most of those are going to be delivered as or many of those are going to be delivered as cloud services where you send your data feed and I send you back a data feed. And that stuff gets a lot easier in the cloud than trying to build infrastructure and interfaces every place I got to have that. Sure. Definitely.
So how long do you think before we see some major company move its SCADA system into the cloud? I don't think it'll really be that long. I think it's the tricky part I believe is for the client interface is 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 and 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 in latency is what latency becomes less of an issue and the bandwidth you should drop significantly. And when the SCADA ventures start to embrace that, you know, have their clients be a little thinner in nature, not needing a as large 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 because it'll just work. Right.
Or the other alternative approach if somebody doesn't want to go that route is you'll be equivalent of remote desktop. I mean, I'm sure everybody, especially lately, has been using remote desktop a lot more than they have in the past. And short of watching a video over remote desktop, which doesn't work very well, everything else it says if you're there. And I do it every day and there's there's stuff at our office that I don't have a replicate of at home.
I don't want the the large bandwidth hit of large data sets flying across the wire. So I rewote into a machine at the office and do the work that way. And I don't notice that is there no desktop. It feels just like a local experience to me.
Right. Well, certainly, certainly there's there's certainly the limitation in terms of the critical process safety in the cloud is the user interface for the controller or operator of the system that 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. And that's the problem. It's got to be solved to be able to do that.
Right. Yeah, you got to build your clients to recognize that and operate that way. But if you use any of the major players websites, they're very responsive and they can interact with them. And it's you can have like live updates depending on the site that that technology is moving forward very quickly.
Yeah, like everything these days. Well, so what we ought to do because we're kind of getting a little long here is give us people some teasers. So I am planning on doing some 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've 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. And 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. So I think it's coming.
I think it's going to be here probably sooner than we realize and what we're going to do is pull some episodes together to kind of help people start thinking about it and get prepared. Scott, you anything to add to that or anything you'd like for the listeners to kind of take away from this conversation? I guess it is a couple comments. If you're looking at the cloud, find an experienced guide to help you get started and keep in mind that security in the cloud is just as important as it is on premise.
So and I say even more so. 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.
Yeah, the ditto. I am completely blown away and now I'm asking a question. Why did we do it five years ago? Exactly.
Well, hey, always a pleasure to have you on. We need to make it not so long between coming on to be a guest because these are my favorite conversations. It's been fun. Yeah, they're all my favorite conversations for all the other guys that come on this guest.
But Scott and I've been doing this for a long time and we do like the opportunity to talk about these things. So hey, thanks for being a guest. Scott. Hey, it's been fun.
Thanks Russell. I hope you enjoyed this week's episode of the Pipeliner's podcast and our conversation with Scott. Just a reminder before you go, you should register to win our customized Pipeliner's podcast Yeti Tumblr. Simply visit pipeliner's podcast.com slash win to any yourself in the drawing.
If you would like to support this podcast, please leave a review on Apple podcast, Google Play or whatever smart device podcast app you happen to use. You can find instructions at pipeliner's podcast.com. If you have ideas, questions or topics you'd be interested in, please let me know on the contact us page at pipeliner's podcast.com. We'll reach out to me directly on LinkedIn.
Thanks for listening. I'll talk to you next week.