Greg established and leads the Enterprise Monitoring Services team at Standard Chartered Bank, and together with his team wrote and implemented a strategy and approach to effectively monitor and leverage data from over 1,000 applications, 30,000 servers, 15,000 network devices, public and private cloud, mainframe, tandem, and multiple other technologies in a sustainable and scalable way. Applying Agile and DevOps techniques to the build, engineering, and support of the monitoring ecosystem at Standard Chartered, the team brought together tools across the technology stack and advocated techniques such as monitoring as code in order to improve monitoring quality and make it a mandatory part of the deployment pipeline.

Prior to that he worked at Barclays Capital in Singapore and Goldman Sachs in Tokyo, Japan in various infrastructure and engineering roles.

Mike Julian: Running infrastructure at scale is hard, it's messy, it's complicated, and it has a tendency to go sideways in the middle of the night. Rather than talk about the idealized versions of things, we're going to talk about the rough edges. We're going to talk about what it's really like running infrastructure at scale. Welcome to the Real World DevOps podcast. I'm your host, Mike Julian, editor and analyst for Monitoring Weekly and author of O’Reilly's Practical Monitoring.

Mike Julian: This episode is sponsored by the lovely folks at InfluxData. If you're listening to this podcast, you're probably also interested in better monitoring tools — and that's where Influx comes in. Personally, I'm a huge fan of their products, and I often recommend them to my own clients. You're probably familiar with their time series database, InfluxDB, but you may not be as familiar with their other tools. Telegraph for metrics collection from systems, coronagraph for visualization and capacitor for real-time streaming. All of this is available as open source, and they also have a hosted commercial version too. You can check all of this out at influxdata.com.

Mike Julian: Hi folks. Welcome to the Real World DevOps podcast. I'm here with Greg Parker, head of enterprise monitoring services at Standard Chartered Bank, way out in Singapore. Welcome to the show Greg.

Greg Parker: Thanks,  Mike. I'm doing well. How are you doing?

Mike Julian: I'm doing fantastic. So Standard Chartered Bank, like what is this? It sounds like just a bank, but I've been talking to you about it and it sounds like it's a whole lot bigger than I imagined.

Greg Parker: Well, Standard Chartered operates across 70 countries. There's more than 1200 branches, there's 90,000 employees, and it's just a sprawling financial institution, but it's primarily operating in Africa, Middle East, a lot of emerging markets, and the headquarters for IT is in Singapore, though the bank is headquartered in London. And so out of Singapore we drive the technology strategy and across all of the markets over 70 countries. And we get a lot of diversity in our environment because of the different strategies that we have in each country. Coming from, I was working for Goldman Sachs for about ten years, where IT was very tightly controlled from the center from New York where, the word came down from the heavens around this is how you're going to do everything. And then I went to Barclays, which was a similar model except the word came down from London, and at Standard Chartered it was really Singapore saying, this is what we should be doing and this is how we operated for our group owned applications, but there were 70 other countries saying, this is how we have to do it in Nigeria, and this is how we have to do it Kenya, this is how you have to do it in Pakistan. And so you have all of those issues creep up when you're working across emerging markets and especially in a financial.

Mike Julian: What's your role in Standard Chartered?

Greg Parker: So my role at Standard Chartered is to run enterprise monitoring. And, it wasn't my original role. I came in to drive some infrastructure projects, large infrastructure projects, and when I got there, I saw that monitoring was essentially chaos. There was really no central strategy around how we're going to do it. And when I worked with some people there and we effectively established a central enterprise monitoring organization for Standard Chartered, the problem was there was no central strategy or tool set, or group of tools that we were using for monitoring, and there were multiple vendor deals, negotiated at different prices at different times with different countries. And so there's a lot of inefficiencies that were contributing to massive, MTTRs. Which meant, when an issue occurred, a thousand different teams got an alert, nobody know whose fault it was, and it took all this time to work out, what's the root cause and how are we going to resolve it? And I think a lot of that comes down to, the fact monitoring wasn't precise.

Mike Julian: And I'm sure in no small part do two countries not be able to talk to each other.

Greg Parker: Certain countries couldn't talk to each other and other countries just didn't know to talk to us. And so there was a lot of people working in silos.

Mike Julian: How does your strategy even look when you have all these different entities that are doing their own thing, and like culturally you're not able to say, “This is what we're going to do.” So what's your approach instead?

Greg Parker: Well, we do have the authority to dictate if we want to. And that's one of the things that came along with establishing this central organization which is backed by the CTO and the head of technology services, which is going to say, our mandate is to go out and fix monitoring for SCB. But at the same time it's not something that we want to do, is to just give people a mandate. And I've been saying this the whole time is that our strategy is not perfect and it's never going to be perfect. Our strategy is focused around corralling all the data that's out there, and translating it, and enriching it, and normalizing it, and then exposing it through APIs. And that's really the crux of it. But, it's never gonna be perfect, and our focus was to just implement a working framework, and help to improve monitoring so that we can reduce those mean time to resolve and mean time to detect times, and just give generally a better sense of observability for the company. So we have a sense like that we know what's going on. 

Mike Julian: Why don't we talk more about the strategy behind what you're doing. Like what does it actually look like? How did you come to this strategy? How are you implementing it? What is it even?

Greg Parker: So we started with multiple teams that had implemented their own monitoring with the tools that they wanted to work with. We have BMC, deployed across all of the infrastructure. A lot of the application teams had purchased ITRS. There were other tools like AppDynamics and Dynatrace and some open source tools out there with Grafana and Elastic and all of that. And so my first thought was, we're not going to standardize everybody to one tool, and there's not one tool that's going to, be this panacea that's solves all our monitoring problems. And that's kind of one of the key tenets of monitoring is that, there's a lot of different tools. It's not about finding the perfect tool, it's about getting them to work together. And so the initial thought was, let's just take all this data that we have and somehow ingest it and normalize it and then figure out a way to leverage it. We can use more modern tools once we have a dataset that we can leverage. And so we started off on that path, and we started building integrations, and building ingestions, and building a translate, an enrichment, and a normalization layer that would ingest not only the data coming from the patrol agents, of BMC Patrol agents across all of our servers, but everything that was being deployed, AppDynamics, or APM. We onboarded a tool called Sysdig for container monitoring, Dynatrace does synthetics, ITRS is obviously doing a ton of application component monitoring as well as infrastructure monitoring, and some tools are harder than others to integrate. And that was the main focus of our efforts over the last 18 months or so was ...

Mike Julian: Is on the integration side?

Greg Parker: Yeah. Was bringing everything into one place. When you're at a big company, like Standard Chartered or any large, investment bank, you can spend years talking about what you want to do and-

Mike Julian: At some point you just got to do it.

Greg Parker: ... Yes. And I've seen it happen. Exactly. I've seen companies talk for years about cloud strategies, and monitoring strategies, and web service strategies, and database strategies, and at some point you just have to dive in and start doing it.

Mike Julian: So what makes the integrations some more difficult than others? Like what are the actual challenges with it?

Greg Parker: Well, we talk a lot about, there being open source tools and there being vendor tools and proprietary tools, and there is this thinking that proprietary tools aren't open and you can't get the data in or out. That's not necessarily the case. There are some open source tools where it's really hard to pull up the data and there is some vendor tools where it's actually relatively easy. But for us, Patrol wasn't too bad. AppDynamics, Dynatrace have relatively open platforms for us. Actually, we ran to a bit of an issue with ITRS because they don't really structure their data in the way that you would expect from a normal monitoring tool. There's [inaudible 00:10:57]. These things make it difficult for us to say, this is where the breach occurred and this is where it was resolved, and this is what it should look like, and this is how we should normalize it. And at the same time, they have a Kafka method in order to bring in the data. But we were running it on such old VMs that if we were to turn on that Kafka, then it would impact the performance of the gateways, and ITRS operates on a siloed model so that we had 300 gateways across our environment, more than 300 gateways. And for us to ingest the data from all of those gateways would've meant either a single script pulling stuff from the central database or 360 different scripts running on each gateway and bringing data in. So for us that was a major challenge.

Mike Julian: Yeah, that sounds like a nightmare. How are you going around to all the teams and getting them to adopt what you're doing?

Greg Parker: Well, like I said, we wrote a white paper in the team essentially about what we were going to do, what the approach is going to be as far as enterprise monitoring. And we circulated that in the forums that we have for technology standards. We got some feedback, we got people who didn't read it and just said fine, and I think you'll see a lot of that especially in big banks or people who are running a large organizations. And then we got people who are like vehemently disagreed with our approach. Like violently, just like absolutely not. And I think that's the problem that you'll always find is, you'll have somebody who's completely ideologically focused on a single type of solution. The protests, to attend to come from people that hadn't spent a lot of their careers in large corporations but in technology companies where you can probably do some more experimentation.

Greg Parker: But it's not that they were wrong at all. They're absolutely right. We should maybe look at these more modern technologies. But when we have a limited amount of time in order to deliver value for a company that's not focused on technology, like our primary service isn't delivering, cloud to our users or something like that, or primary services being a bank, and we had an environment, built out on BMC, that we just needed to upgrade in order to be able to achieve what we wanted to do. And so it ended up being a compromise obviously, where we would agree, yes, this is what we want. We're not necessarily delivering it the way everybody wants, but we're doing something for the purpose of expediency, getting a solution out there, and at the same time we're going to start evaluating, what's the best way to do it? And I think it's always an evolution like that at big companies.

Mike Julian: I have spent a lot of time at very large companies myself and I've also spent time in the small companies, and I ran into a lot of people that are, they don't like how technology decisions are made in very large companies, and mostly how slow they are and how behind the curve they feel like they are. But to me there's actually a lot of really good reasons for that. But to me that actually takes away a whole lot of stuff that I don't need to worry about anymore. Like with you, you have the support of a very large bank behind you. You have all this data that you get to play with, a single division at which you're working on towards the entire revenue of many of the companies that are in Silicon Valley. So just the scale of what you're doing is way more interesting that you're only gonna find it a large place.

Greg Parker: You don't account to these issues when you're trying to monitor a single application, then you're just like kids, fantastic, let's do [inaudible 00:15:06] of tracing and let's just get everything into a database and then you can build a Grafana dashboard and it's fantastic. But I think that's the thing is, we're not trying to monitor our company. We're trying to build a framework so that each individual team can monitor their application. Right?.

Mike Julian: You and I were talking while back about this particular challenge as well, about how, if you develop this strategy and develop this platform, how do we get it out there? And the one where we're talking about is, well, you don't have like one team that needs to adopt it. You have several dozen teams that all are doing their own thing and you want to get them to adopt it. So it's not a quick thing. This is not going to be done anytime soon. So this is very much a very long play for you. Do you have any idea about how long it's going, how long of an investment this is?

Greg Parker: It feels like, well, it's something that never ends first of all, but it feels like it's already been going on forever. So we establish the team like around the end of 2017. We spent the better part of the last, 14 to 16 months building the platform and the integrations, and our thinking was, we'll get people on board with the concept, we'll build something, we'll deliver it to them, and then we'll slowly drive the adoption. And so having spent the most of the last year building the platform, in 2019 we're going to be primarily focused on driving the adoption. So we've migrated over about 50 teams at this point from monitoring through either email or remedy tickets or something like that to our standard platform which exposes data through API and it has a front end, and we plan to drive, another 50 to 100 teams next year onto that central platform.

Greg Parker: And I think one of the difficult pieces we'll be looking at the teams that are using more mature solutions that, where they've actually spent a lot of time. We have a team that's has for resources that have been fully dedicated full time for the last three years on our eCommerce area [inaudible 00:17:28] this straight to bank platform, which is eCommerce in real time, trade execution and all of these sort of things. And they've built an ecosystem around this ITRS gateway that is completely custom and completely complicated. It's just insanely complicated. And then they generate dynamic dashboards and they inject XML because that's the only way you can really talk to ITRS in a programmatic way. So it generates XML flat files and pushes it out to the gateways and everything like that. And I mean, for me the solution that works for them, and so that's not going to be our primary goal is to absolutely get 100% of the bank onto our framework and our platform. It's really for the teams that haven't put that type of thought into their monitoring. And if you have just been working off of emails and remedy tickets because alerts were auto-generated to tickets, which is a horrible way to deal with alerting, but for teams that were doing that sort of thing, they're more willing and they're definitely much more eager to say it. I'm so glad that you delivered a platform that is actually purpose built for monitoring.

Mike Julian: You made a really fantastic point there. I want to call it out so we don't miss it. That your goal is not 100% adoption. Your goal is to provide something where there wasn't anything good before. So it's not that you're trying to tell the teams, all the teams that you support that, no, you have to use my thing. What you're telling them is, this is available, but if you want to do something else that's fine. But this thing that ...

Greg Parker: If you like your manual, keep it.

Mike Julian: Like this thing that we've built is fully supported, so if you don't want to maintain your own stuff, then you can use ours.

Greg Parker: Yeah, exactly. And we try not to position it as a mandate. Generally, we’re an internal team, we could manage one, but we sell it. I have a team of people that spend their time sitting down with the support people on the ground and selling our platform to them as if we're a technology company, because we want people to want to buy into it and not just feel like they're forced to use it.

Mike Julian: What sort of questions or I guess objections are you getting when you're selling this to teams? Are there any common complaints, any common objections that come up?

Greg Parker: There's two big ones. I mean, the first one is that people are very used to the way that they were doing things. And that happens when they've been monitoring in a certain way for the last 10 years, which is, they just stare at a remedy queue and they hit F5 every 30 seconds to refresh it. And some of them actually have created macros, so they don't have to actually hit F5. It just automatically refreshes every thirty seconds.

Mike Julian: That's incredible.

Greg Parker: Talk about automation. But they're very used to that and they're very ... Because audit and compliance is always a huge pressure at a bank and they're very worried that they might miss a ticket. And that's why they've auto-ticketed every alert, even minor alerts, 70% threshold breaches and that sort of thing. And they're like, as long as it's a ticket, then we can't say that we've missed it. And that's entirely missing the point of monitoring, which is like, you shouldn't actually even have to look at anything if there's no remedial action to take. So you do have to sit down with a lot of junior support people because the domain heads that are sitting in Singapore and aren't really on the ground, hear gripes coming up from the ground and saying, “We don't want to move to this solution that the monitoring is trying to force on us,” and it's about, helping them to understand the bigger picture. And so it doesn't, even though we have the support from the domain heads, you have to do a grassroots campaign. I feel it's the best way to approach it. And the other big gripe that comes along is for people that are using tools like ITRS, because there are certain features in ITRS that we can't replicate in our central platform like acknowledging and snoozing an alert or something like that. And that's a functionality that people have been used to. Even though it's not necessarily a good practice. And there are things like that and you just have to kind of take them case by case.

Mike Julian: Sure. And on that note, you mentioned that there's this functionality in ITRS that people are used to of acknowledging or snoozing an alert and it's not a good practice. So in that situation, are you also, through your platform also teaching people how to do monitoring better, like as an education component to it?

Greg Parker: We really try. There were four pillars of our monitoring transformation, people process governance and technology, and we through the people's side, we built up the team. From process, we are building a lot of documentation and training about how people should be thinking about monitoring, and a monitoring pyramid which is that you obviously think about your business deliverables and your business KPIs before you think about what are your alerts going to be, what are you going to monitor for? And so that's, another completely different aspect of my organization is trying to drive better monitoring practices across the organization. And that's much harder than building the technology.

Mike Julian: As it turns out, people are a lot more work.

Greg Parker: Yes, exactly. Driving changes in behavior, especially when they're like deep seated little habits is very difficult, and we formally modified our software development framework, our SDF and our SDLC and gateway checks and all of these things in our governance documents, but it doesn't mean anything. People are not going to sit down and read those. It's really about, helping people to drive better monitoring in their area.

Mike Julian: You kind of touched on a point earlier of audit and compliance is a big deal. So with all this stuff you're doing, regulatory controls. I mean you're a bank, so regulatory controls and audit and compliance and all that stuff surely plays a pretty big role in what you're doing.

Greg Parker: Yep. For me that's probably 70% of my job. It's massive.

Mike Julian: What does that mean? What does that look like to you?

Greg Parker: So the compliance aspect is driven by your own policies and that's the thing that's really that a lot of people probably don't get is that, all of your audit burden is brought on by yourself, because your internal … you have three lines of defense in any organization, any corporation. You have your first line which is your internal risk and control team, and your second line which is your group operational risk, and then your third line which is your group internal audit, and they'll all judge you based on the policies that you write. But at the same time, if your policies don't adequately address the risks that face the company, they'll write them for you. 

Mike Julian: So it's much better for you to write them?

Greg Parker: Yes, but it's always a balancing act because I could write a policy that says, there's no central monitoring standard for the bank, and then they'll say, well what about the risk of the bank not having adequate monitoring? And I'll say, there's a small monitoring standard for the bank where all you have to do is monitor CPU. And they're like, well, what about the risk of a file system failure? And then so it's just, you're just constantly balancing about, I don't want to have too much governance burden, but you want to address the risks of the bank. And so you go into this negotiation with Gore, with group operational risk and talk about, I think this is not a material risk, based on my experience and based on industry practice, and you arrive usually at a compromise, but in the end there has to be a monitoring standard. And that's the little piddly tedious thing that GIA is going to audit you on every time. So for us, a constant finding in audits across the company is that, the monitoring standards that your CPU threshold should be 90%. And we looked at the configuration and it’s 87%, and it's just nonstop. And so from our perspective, we want to put out a monitoring standard that helps improve the company's overall production stability and addresses the risks of the company not having adequate monitoring. But it shouldn't be too specific that it causes internal teams to fail audits when there's not actually a material risk.

Mike Julian: Like alerting on a CPU?

Greg Parker: Right. Alerting on a CPU at 91% is not a material risk, if the standard says it should be 90%. One way that we try to do that is we de-emphasize the importance of static thresholds, obviously. And it's sort of it an ancient monitoring technique anyways. Now you have a lot more machine learning and dynamic thresholds. And so we try to de-emphasize the importance of static thresholds. We put more emphasis on broad themes of monitoring, like you're monitoring for your performance, you're monitoring for errors, you're monitoring for peak utilization and high levels of demand. And then from that point on it's really about educating your internal audit and risk and control teams about why these better address the risks of the company.

Mike Julian: You actually end up with really two different customers here. So you have the group that's using the platform and then you have your internal governance that's judging you on what you've written and what you're doing, and you're having to satisfy both, which is almost an impossible task in some ways.

Greg Parker: That's a good word. They're constantly judging us — and sometimes based off of antiquated understanding of the industry. I love these auditors sometimes being in the business for 30 years and they saw how monitoring work in 1990 at IBM, and they expect to see a similar structure when we're trying to drive something that's more modern. But generally the users are appreciative of the fact that, we feel that the monitoring related questions around audit, but they have to be aware of that, of the policies that exist and try to drive them and implement them because, another way to drive our policies across the bank is that they’re going to show up on these noncompliance lists if they're not compliant to the policies. And so what we do, is we tried to establish a reasonable standard and a reasonable framework, and from that point on we can let Gore and GIA drive the compliance to an extent that's sort of a hammer that essential team can use across cross a large organization.

Mike Julian: So our listeners are going to absolutely roast me over a fire if I don't ask this question. But what's the tech stack look like underneath this platform you've built? Like what goes into it? So you mentioned that there's a lot of vendor, is a lot of proprietary, a lot of commercial and a lot of open source tools. But what's gluing it all together?

Greg Parker: Like I said, we tried to bring together a bunch of different tools. At the center is a tool called TrueSight Operations Manager, which is from BMC. And that's an aggregation. It's a manager of managers, and it's a way to ... it has enrichment models, it has normalization models, and it has a lot of interfaces. And so the different agents that we have across the organization to collect data include, like I said, ITRS, BMC Patrol, AppDynamics. There's open source tools out there, there's Elastic and there's Beats that are out there. Like I said, Sysdig does our container monitoring and that's based on an open source agent that was developed back in 2011. There are teams that are using Prometheus, there are teams that are using Telegraf and Influx to collect data. And we were able to ingest that into, via a set of proxies across every country and in our two main data centers ingest that data in, normalizing it and enrich it with data from RCMDB, is our configuration management database, enriches that monitoring data with information about business criticality and application and owner and a lot of different things. 

Greg Parker: And on the other side of that, because like I talked about before, BMC is a massive corporate vendor, but they're starting to step in the API direction and they've developed APIs for TSOM. But there's a lot of issues with the APIs for TSOM. They're complicated, they're hard to use. And so while teams can use the front end of TSOM, of TrueSight Operations Manager to build simple dashboards and there's drag-and-drop and there's Widgets, we then stream that data of TSOM into an elastic database. And then we've built a platform on top of elastic using the elastic KPIs, and then we have the elastic KPI's plus the set of custom KPIs that we've built to expose all of the data to users in real time, so that they can build their own real-time dashboards and visualizations off the back of that. And for right now, that's why we have a team of like 60 people or whatever, that ...

Mike Julian: Just to make sure that people got that. You said 60?

Greg Parker: Yes. Across engineering and support and our governance and our service management teams.

Mike Julian: I just want to be sure that people listening to this, like, this is not a simple thing to do. That's a pretty significant organization working on that.

Greg Parker: And most of the banks that I've been with have not actually devoted that much resource to their enterprise monitoring organization. There's usually an enterprise tools team that has a handful of people or maybe 10 or 20 people, and then there's a support team that supports a group of sort of IT for IT applications, but we really thought that we're going to take all of those teams and bring them together, and really try to drive a strategy centrally. And that's why it's a relatively large organization, but usually you have that number of people spread out across the bank, supporting the entire ecosystem.

Mike Julian: Got you. There's so much that goes into what, how a large bank operates that it's just never occurred to me before. So this has been absolutely fantastic to learn about.

Greg Parker: I mean, it's just an octopus with his tentacles just going out everywhere and you really just trying to get everything, corral everything together. And so, still being early on in our journey, like I said, we're just trying to corral everything. But there's other teams, that have gone out. In Standard Chartered for example, the cloud team has gone out and sort of built everything from a greenfield, and with their best of breed tool set of choice for DevOps, and all of the aspects of the DevOps pipeline as well as monitoring, which also integrates with our central framework. And so there are areas and there are pockets where, and their application teams out there that are building microservices applications based on Docker Swarm and based on Kubernetes. And so they're very modern in fault tolerant and performance. And then of course there's still plenty of applications out there that run on a mainframe and tandem, and all of those fall into the same rules and policies.

Mike Julian: So surely you've learned a few things from doing this whole project. What's gone well? What hasn't worked?

Greg Parker: I would say that the thing that I would change if starting over, if I were just starting over from the beginning would be to initially just talk to my users more and really focus on improving monitoring from day one. Whereas, we were saying, we're so far behind we have to upgrade our system and we have to start building all these equations, we have to build this central data layer. But we actually had the tools in place where we could from day one, start talking to our users and implement these fundamental things that didn't require our modern tool set. They didn't require anything advanced. You don't need Kafka, databus and Cassandra and all these different things. If a Unix team is not able to monitor VCS. I mean, we needed a few scripts and a knowledge module, and then you can have active, proactive monitoring of your VCS clusters and know when they're going down or falling over or hitting resource constraints. And it was only after we had possibly spent maybe half a year that I had the head of Unix or the head of platform is coming up here and be like, "When are we going to get better ping monitoring and when are we going to get better VCS monitoring?" And I said, "Well, actually we've been working on completely overhauling or upgrading the platform." But I think a lot of problems can be solved just by obviously talking to your users, and we probably could have reduced our MTTRs and MTTDs quicker if we had started with that, and while at the same time concurrently starting driving an upgrade.

Mike Julian: So this has been absolutely fantastic conversation. Thank you so much for coming. For people in a company like yours, they're probably listening here and saying, “Yeah, but I can't do that like for all these different reasons like that won't work for me.” What advice would you give them?

Greg Parker: I would really just say, to focus on your monitoring coverage and compliance to your monitoring standards, and focus on developing good standards. Because like I said, if you're at a large company or if you're at a company that has a typical corporate governance structure, you don't necessarily have to be the person that drives the compliance to that. If you write a good, risk reviewed policy that addresses your company's main risks as far as monitoring is concerned, then you have teams of people whose job it is to drive compliance with those policies and who will audit the other teams for those policies. So federate the workout, try not to take everything under yourself, which is a lesson that I've learned. It's impossible to do in a bank with 34, 35,000 production systems, and 1,000 applications. If you're driving a large organization, you don't have the resources, then focus on a very solid base, and ensure that your group risk and your group audit are on board with your policies and understand them, and so that when they run, when they do their jobs, that they drive those teams to adhere to those policies.

Mike Julian: All right, so is there anywhere that people can find out more about you or your work?

Greg Parker: I'm trying to think.

Mike Julian: You do work for a very large bank, so perhaps not nearly as public as some others.

Greg Parker: I mean, I'm on LinkedIn and I welcome people to, they can get in touch with me there.

Mike Julian: Alright. I'll throw that in the show notes of course.

Greg Parker: Sure.

Mike Julian: Well, thank you so much for joining me, Greg.

Greg Parker: No problem, Mike, anytime you want.

Mike Julian: And thank you to all our listeners as well. If you want to stay up to date on the latest episodes, you can follow along at realworlddevops.com or on iTunes. And if you're listening to this on iTunes, please rate us. So thank you and have a wonderful evening.

Greg Parker: All right. Thanks Mike. Appreciate it.