Real World DevOps

About the Guest

Baron is the CTO and founder of VividCortex, the best way to see what your production database servers are doing. Baron has written a lot of open source software, and several books including High Performance MySQL. He’s focused his career on learning and teaching about scalability, performance, and observability of systems generally (including the view that teams are systems and culture influences their performance), and databases specifically.

Links Referenced

• xaprb.com 
• High Performance MySQL: Optimization, Backups, and Replication
• eBook: DevOps for the Database
• @xaprb
• VividCortex

Transcript

Mike Julian: This is the Real World DevOps podcast and I'm your host Mike Julian. I'm setting out to meet the most interesting people doing awesome work in the world of DevOps, from the creators of your favorite tools to the organizers of amazing conferences, from the authors of great books to fantastic public speakers. I want to introduce you to the most interesting people I can find.

Mike Julian: Ahh, crash reporting. An oft-forgotten piece of a solid monitoring strategy. If you struggled to replicate bugs or elusive performance issues you're hearing about it from your users, you should check out Raygun, whether you're responsible for web or mobile applications, Raygun makes it pretty easy to find and diagnose problems in minutes instead of what you usually do, which if you're anything like me, is ask the nearest person, "Hey, it's the app slow for you?" and getting a blank stare back because, hey, this is Starbucks and who's the weird guy asking questions about mobile app performance. Anyways, Raygun, my personal thanks to them for helping to make this podcast possible. You can check out their free trial today by going to raygun.com.

Mike Julian: Hi folks. I'm Mike Julian, your host of the Real World DevOps podcast. My guest this week is Baron Schwartz, the founder and CTO of Vivid Cortex and author of a book that I'm sure many of you have laying around, High Performance MySQL. Welcome to the show Baron.

Baron Schwartz: Thanks Mike. Great to be here.

Mike Julian: Baron some years ago, well, I also started writing a book in like 2015, I guess it was, 2016. And you've written a lot about your writing and I mean you are a very prolific writer on your blog, having also written the tome of High Performance MySQL.

Baron Schwartz: Maybe too much of a tome. Yeah.

Mike Julian: Right. It is a pretty sizable book. And I found this article that you had written about how you wrote, which I found absolutely fascinating. One of the pieces of advice I saw that I've used and have been regurgitating to everyone. How do you write the book while you outline? You start with an outline and then you keep outlining. And you keep and keep and keep on outlining until you're at the point where you should feel like you've stopped outlining long ago and then outline some more. Yeah, just a little bit more after that.

I thought that was incredibly insightful advice because most people, they do stop jotting down thoughts a bit too early.

Baron Schwartz: Yeah. I should use that advice myself. Every time I do it, I'm really happy with the results. The truth is I don't always, and then I'm like, "Why is this so hard?" It's just because I'm just slogging through not having outlined and now I've got ... So for folks who are not going to read this blog post, which I assume will be a lot of our listeners, the general idea that led me to try this approach was actually writing the second edition. So the blog post that you're talking about was written after the third edition of High Performance MySQL. And the second edition was an absolutely horrendous amount of work. I know because I used a timekeeping app and I basically spent like a half a year on it. So it was more than a thousand hours of really hard work.

And then afterwards I looked at what was most of that time spent doing and most of it was actually spent editing things that turned into pros too soon because pros has to have correct grammar. And if you don't feel right about the order of the ideas in a paragraph and you start fussing with it, then the grammar gets mucked up when you're sort of dragging things around or whatever. And so you try and fix that, but you're polishing something that is structurally bad and to fix it, you end up having to go back and restructure it and then re-edit it. But if you're re-editing for grammar and flow and everything the whole time, it's just an insane amount of work.

So the third edition, I did using mostly the outlining style that you're talking about, mostly after several years of having just collected notes, which is a part of the writing process that's largely invisible, just like filling files full of one bullet point URLs or quick little one liners or whatever. And I took that stuff, I sort of decomposed the second edition into its component parts, restructured it, put in the stuff that I wanted to update or new material, and then outlined and wrote. And the third edition was about 300 hours of work. Although it was a complete rewrite of the book and made it much larger. So it was a lot more material and a lot more accomplishment with a heck of a lot less work.

Mike Julian: Yeah. When I first started writing mine, I did actually start tracking time and then I stopped doing it after a while on the advice of one of the editors of the first edition of a friend of mine, Derek Balling, he gave me a piece of advice that do not ever under any circumstances, attempt to calculate your hourly rate of writing a book.

Baron Schwartz: Excellent advice. Yeah. If you do the math, what you end up earning from a book is almost always depressing in purely economic terms. However, I will say it's been a huge ... well, there's a couple of things. High Performance MySQL has been unusually best selling for a technical book and very few books ever strike gold that way, which is purely a function of just circumstances and luck and things like that. So I think if I calculated my hourly rate, it wouldn't be depressing, but that's-

Mike Julian: It would also just not be awesome.

Baron Schwartz: Yeah. It still wouldn't be awesome. But it's been good to get the royalty checks every now and then, which most authors never get. They never pay back their advances. And that's part of the publishing role. But yeah, even if you do, it's still ... But there's also a lot that you can't just reduce to an hourly rate about the benefits of writing a book, not only for example, the book lives on, and carries to many audiences, and reach as many people, and touches many lives that you never would have in other ways and that comes back and is very rewarding. People write me on a fairly regular basis and say something. I met with somebody a couple of months ago and he said, "I have to thank you for making me a millionaire." I said, "Well, can I get a finder's fee? Just 1%."

Mike Julian: Oh, wouldn't that be nice. It's always wild to me when I get the notifications that, "H...

About the Guest

Dr. Nicole Forsgren does research and strategy at Google Cloud following the acquisition of her startup DevOps Research and Assessment (DORA) by Google. She is co-author of the book Accelerate: The Science of Lean Software and DevOps, and is best known for her work measuring the technology process and as the lead investigator on the largest DevOps studies to date. She has been an entrepreneur, professor, sysadmin, and performance engineer. Nicole’s work has been published in several peer-reviewed journals. Nicole earned her PhD in Management Information Systems from the University of Arizona, and is a Research Affiliate at Clemson University and Florida International University.

Links Referenced: 

• 2019 State of DevOps Survey
• Previous State of DevOps Reports

Transcript

Mike Julian: This is The Real World DevOps Podcast, and I'm your host Mike Julian. I'm setting out to meet the most interesting people doing awesome work in the world of DevOps. From the creators of your favorite tools to the organizers of amazing conferences, and the authors of great books to fantastic public speakers, I want to introduce you to the most interesting people I can find.

Mike Julian: Ah, crash reporting. The oft-forgotten about piece of a solid monitoring strategy. Do you struggle to replicate bugs, or elusive performance issues you're hearing about from your users? You should check out Raygun. Whether you're responsible for web or mobile applications, Raygun makes it pretty easy to find and diagnose problems in minutes instead of what you usually do, which if you're anything like me, is ask the nearest person, "Hey, is the app slow for you?" And getting a blank stare back because hey, this is Starbucks, and who's the weird guy asking questions about mobile app performance? Anyways, Raygun, my personal thanks to them for helping to make this podcast possible. You can check out their free trial today by going to raygun.com.

Mike Julian: Hi folks. I'm Mike Julian, your host for the Real World DevOps Podcast. My guest this week is Dr. Nicole Forsgren. You may know her as the author of the book Accelerate: The Science of Lean Software and DevOps or perhaps as a researcher behind the annual State of DevOps report. Of course that's not all. She's also the founder of the DevOps Research and Assessment, recently acquired by Google, was a Professor of Management Information Systems and Accounting, and has also been a performance engineer and sysadmin. To say I'm excited to talk to you is probably an understatement here. So, welcome to the show.

Nicole Forsgren: Thank you. It's a pleasure to be here. I'm so glad we finally connected. How long have we been trying to do this?

Mike Julian: Months. I think I reached out to you, it's March now. I reached out in November, and you're like, "Well, you know, I have all this other stuff going on, and by the way, my company was acquired."

Nicole Forsgren: Well, back then, I had to be sly, right? I had to be like, "I've got this real big project. I'm sorry. Can we meet later?" And, God bless, you were very gracious and kind, and you said, "Sure-"

Mike Julian: Well thank you.

Nicole Forsgren: ... "we can chat later." And then I think you actually sent me a message after saying, "Oh, congrats on your 'big project'." I said, "Thank you."

Mike Julian: That sounds about right.

Nicole Forsgren: I appreciate it. Yeah. And then, you reached out again, and I said, "Oh, I'm actually working on another big project. But, this time ..."

Mike Julian: It's not an acquisition.

Nicole Forsgren: Yeah, it's not an acquisition. This time, it's a normal big project, and it's this year's State of DevOps report. And we just launched the survey, so I'm super excited we're collecting data again.

Mike Julian: So we can get that right out of the way, where can you find the State of DevOps report?

Nicole Forsgren: All of the State of DevOps reports are hosted at DORA's site. We still have the site up. And all of the reports that we've been involved in from, I want say we started in 2014, I'm so old I already forgot. All the reports that we've done are hosted. We'll post them in the show notes. If you can grab yourself a Diet Coke or coffee or a tea or a water, or if you want a bourbon. Get comfortable. Sit back, takes about 25 minutes. I know, right, everyone's like, "Girl, 25 minutes?"

Mike Julian: That's a big survey.

Nicole Forsgren: I know. It is. But it's because the State of DevOps report is scientific, right? We study prediction, and not just correlation. But sit back, get comfy and let me know what it's like to do your work. Because we're digging into some additional things this year; productivity, tool chains, additional things around burnout and happiness, and how we can get into flow, and really what that looks like. And some really great things are a bunch of people have already chimed in after taking the survey in really thoughtful ways. Also, by the way, I love you all for taking it if you have. Share it with your colleagues, share it with your peers.

But they've said that just by taking the survey, they've already come away, even before the report has come out, they've already walked away with really interesting ideas and tips and insights about how they can make their work better.

Mike Julian: Yeah, that's wild to think about, that the act of taking a survey actually improves my work. Because most surveys I take, I'm finished, I'm like, "Well, that was kind of a waste of time." It feels like I just gave away a bunch of stuff without getting anything.

Nicole Forsgren: Yeah, and I think the reason it works that way is because we're so careful about the way we write questions that sometimes just the act of taking the survey helps you think about the way you do your work. So just the act of kind of taking some of these questions helps people think about what they're doing. And then, of course, like I joked already, it's my circle of life, the survey will be open until May 3rd and then I will go into data analysis and report writing. And we expect the report itself to come out about mid-August.

Mike Julian: Well, why don't we take a few steps back and say ... Everyone loves a good origin story. I believe you and I met at a LISA many, many years ago. You were giving a joint workshop with Carolyn Rowland on-

Nicole Forsgren: Oh, I love Carolyn.

Mike Julian: Yes, she's also wonderful. I should have her on here.

Nicole Forsgren: My twin. Yes. Absolutely.

Mike Julian: So you were a professor then when I first met you. I'm like, you know that's kind of interesting that a professor's hanging out at a LISA and giving all this great advice on how to understand business value, which I thought was absolutely fascinating. Professor, hanging out in the DevOps world, how'd...

About the Guest

Thai helps teams build more resilient systems and improve their ability to effectively respond to incidents. A former EMT, he applies his experience managing emergency situations to the software industry. He writes about resilience engineering each week at ResilienceRoundup.com

Links Referenced: 

• Strongbad’s The System is Down 
• https://resilienceroundup.com/
• https://re-deploy.io/

Transcript

Mike Julian: This is the Real World DevOps podcast, and I'm your host, Mike Julian. I'm setting out to meet the most interesting people doing awesome work in the world of DevOps. From the creators of your favorite tools to the organizers of amazing conferences, from the authors of great books to fantastic public speakers. I want to introduce you to the most interesting people I can find.

Ah, crash reporting, the oft forgotten about piece of solid monitoring strategy. You struggle to replicate bugs or elusive performance issues you're hearing about from your users, you should check out Raygun. Whether you're responsible for web or mobile applications, Raygun makes it pretty easy to find and diagnose problems in minutes instead of what you usually do, which, if you're anything like me, is ask the nearest person, “Hey, is the app slow for you?” and getting a blank stare back because hey, this is Starbucks, and who's the weird guy asking questions about mobile app performance? Anyways, Raygun, my personal thanks to them for helping to make this podcast possible. You can check out their free trial today by going to Raygun.com.

Mike Julian: Hi folks, I'm Mike Julian, your host for the Real World DevOps podcast. My guest this week is Thai Wood. He's an internal tools specialist at Fastly, the editor of Resilience Roundup, a fantastic newsletter that I'm a huge fan of. And perhaps really interesting is he's a former EMS professional. For those that don't know, EMS is what most of the Ops world keeps looking to figure out how can we improve our own on-call and incident management procedures. So, welcome to show Thai.

Thai Wood: Hey Mike, thanks for having me.

Mike Julian: So for those that really have no idea or frame of reference for what EMS is, what is it?

Thai Wood: EMS is sort of the broad umbrella of what happens anytime someone has a medical emergency, usually starts with someone calling 911. Someone gets sick or injured, they call 911 and the people who show up in whatever capacity are EMS workers and EMS professionals.

Mike Julian: So, would this also be like firefighters, police, doctors, nurses? Everyone's included in that or?

Thai Wood: Yeah, typically it's a big group of people just because who shows up actually, in the US strangely depends on where you live, what state you're in, what your county rules are, and a lot of things like that. So, here in Las Vegas, for example, we actually have three different fire departments, some of which run their own ambulance services, some of them do not. So it can also depend on what area of town you're in.

Mike Julian: Yes. San Francisco is the same way. The San Francisco Fire Department actually, I guess consumed the San Francisco Emergency Management into themselves so there's no such thing in San Francisco County is separate EMS. So that's why you hear so many fire trucks everywhere, it's because most of the incidents are not for fires, the city is not always burning down, it's just someone's always hurt. So they send a fire truck and police and more fire trucks. Where I'm from in Knoxville, Tennessee we actually had separate EMS, which was like they had the same vehicles as the ambulances except they were green instead of red, which was kind of cool. So yeah, that's fun.

So one of the things I really find interesting about EMS is when you look at people responding to incidents, and I'm using incident in a very broad, vague way here, someone gets hurt. And the people responding have just like the most cool, collected nature I've ever seen. And it's always like two people show up and everyone knows exactly what's going on. Meanwhile, the people who have called are freaking out, but the EMS personnel are calm and collected. How do you even get that way when someone's bleeding on the sidewalk, but EMS is perfectly cool about it.

Thai Wood: I think that's a really good question. It's actually something that I feel is missing in a lot of software, which is just a lot of it is experience. The hundredth time that you've been on a similar call, the thousandth time, of course like anything we habituate to it, and it gets easier. A lot of places with EMS, you have an opportunity to practice these things, and to get better at them. Oftentimes, that might be that you do ride-alongs even before you are certified. So, you're already becoming immersed in this world. You have an opportunity to do some clinical hours at hospitals, for example, sometimes, and you get to just be in these different situations. And of course, the first, maybe the fifth, maybe even the 10th, you feel the same way. There's also of course a culture where a lot of times what you're seeing is not in fact the truth.

Mike Julian: Okay. Tell me more about that.

Thai Wood: Well, depending on what it is that you're walking into, I or others might have an internal dialogue that say, “Oh, no, I have not seen this before.” But, we're not doing either of us a service by letting that dictate our outward response. If I'm letting that change my behavior or letting it allow me to be distracted or unfocused, I'm not helping you nor am I helping myself be more effective or be more effective in helping you.

Mike Julian: Yeah, that makes sense. I mean, I've definitely had that situation when I've been on call. You walk in has something like, well, everything's exploded, I have absolutely no idea what's going on. But as the senior engineer, everyone's looking to you like, expecting, you've seen this before. So you just kind of put on that veneer of, “Nope, I've got this,” while screaming internally.

Thai Wood: Absolutely. And I think that, depending on why it's done, I think it's actually a good thing. In software, I do tend to question a little bit, I think it should be okay to say, “I don't know, this thing. I haven't seen it before, but I'm going to figure it out,” whereas with … Because you're probably with personnel that you know at least somewhat if you're on call, right? Network operations, staff, people you've at least talked to before, which is not necessarily the case with emergency management, in the physical realm. These are strangers and you don't know how they're going to react. So your best service to them is to just keep that cool.

Mike Julian: Right. Yeah. It's just really hard to do sometimes or, most the time for me. Man, I do not miss being on call at all. I never liked the idea of having to present that coolness that everyone's looking for.

Thai Wood: I definitely understand that. It's a very visceral, physical experience. And I know a lot of us can habituate good and bad to some of this stuff. We know that noise, whatever our pagerduty alert noise is, we know that noise, right? Or even if you put it on vibrate, the sound of that phone vibrating against your nightstand, you know the ...

About the Guest

Cory G Watson is a Technical Director at SignalFx with 20 years of SWE, SRE and leadership experience at the likes of Twitter and Stripe. He's an observability wonk, optimist, and lover of sneakers. He hopes you're having a great day!

Links

• Twitter: @gphat
• Website: onemogin.com

Links Referenced

• Patrick McKenzie’s blog post, “I’m Joining Stripe to Work on Atlas”
• Book recommendation: Information Dashboard Design: The Effective Visual Communication of Data by Stephen Few

Transcript

Mike Julian: This is the Real World DevOps podcast. I'm your host, Mike Julian. I'm setting out to meet the most interesting people doing awesome work in the world of DevOps. From the creators of your favorite tools, to the organizers of amazing conferences, from the authors of great books to fantastic public speakers, I want to introduce you to the most interesting people I can find.

Mike Julian: Ah, crash reporting, the oft forgotten about piece of a solid monitoring strategy. If you struggle to replicate bugs or elusive performance issues you're hearing about from your users, you should check out Raygun. Whether you're responsible for web or mobile applications, Raygun makes it pretty easy to find and diagnose problems in minutes instead of what you usually do which, if you're anything like me, is ask the nearest person, "Hey, is the app slow for you?" and getting a blank stare back because, "Hey, this is Starbucks, and who's the weird guy asking questions about mobile app performance?" Anyways, it's Raygun. My personal thanks to them for helping to make this podcast possible. You can check out their free trial today by going to raygun.com.

Mike Julian: Hi folks. I'm Mike Julian, your host for the Real World DevOps podcast. My guest this week is Cory Watson, Technical Director for the Office of the CTO at SignalFX. He's previously run observability at Stripe and Twitter. Cory, welcome to the show.

Cory Watson: Thanks for having me.

Mike Julian: I think it's interesting that you have gone from running observability teams at pretty interesting places like Stripe and Twitter.

Cory Watson: Thank you, thank you.

Mike Julian: To now, you're working for the enemy.

Cory Watson: That's a good way to put it.

Mike Julian: Yeah, you have suddenly gone to the vendor side.

Cory Watson: Yeah, the nicer way that I put it, is I say I switched sides of the table.

Mike Julian: Ah, yes. That is a much better way to put it. Apologies to my sponsors for insinuating that they're the enemy. You're completely right, it really is just the other side of the table.

Cory Watson: That implies that it's just a simple change in aspect, though. It's really not. It's actually a pretty fascinating difference, I think.

Mike Julian: Well, why don't you tell us more about that? What is that difference? What is it all about?

Cory Watson: I think, in the past, when you work at a place that uses these vendors, you're often trying to make sure you maintain, or at least it's always been my goal to maintain, a sort of neutrality or maybe not a shim layer is the right way to put it. But how do we retain our independence and make sure that we could switch, if necessary, and all these other things? It's both good, usually from a technical perspective, but also from a leverage perspective, right? Because you wanna be able to switch if you need to or go to the new, cool thing that might come out. Not that we jump and switch that frequently, but you wanna be able to retain that independence. Now, suddenly, I'm on the opposite side. I think there's two interesting bits about it. One is the change in perception or the change in the approach. The second is just the learning experience that I have from watching business being conducted from this side of the table. I guess we can start on the difference in perspective. To your earlier question, it's like, alright. Here I am previously sitting over here, going like, "Okay, don't tell them anything and pretend like you hate everything that they show you, and never show your true colors."

Mike Julian: Fantastic negotiating tactics.

Cory Watson: For lack of any better training, I think that it's the place that you try to go. But at the same time, it's actually somewhat different than I imagined, because I'm happy to work for a company that largely isn't trying to sell you something for the sake of selling it to you. I think this is true of pretty much all vendors, we only want you, as a customer, if you're ultimately going to be happy. Especially for the duration that many of these engagements, contracts, or purchase periods, or whatever last, you don't just want to ease in, make a buck, and then ease back out again. You've got to stay with it.

Cory Watson: In many ways, I think that my past experience of wanting to hold everything close to the vest, to use that idiom, don't really work that well because you need to give as much information as you can to the vendor so that the vendor can, hopefully, tailor the solution as well as possible, right? At the same time, I think it all comes down to price, though, at the end of the day. I think in that, luckily I don't have to have that conversation. I am only here to talk about the pros and cons and the approaches of how to do observability and how SignalFX can be helpful for you. I actually think that in switching sides, I've actually seen how it can actually hinder the process of adoption and understanding. Because, if you're like, "Well, we're not gonna tell you how many things we're monitoring, or how many metrics there are, or what our challenges are." It makes it extremely difficult to articulate a value proposition to the other people because suddenly I'm like, "If I can't help you size this, I don't know how to have the conversation." It's interesting to be on the side where you suddenly lack so much information because-

Mike Julian: I've run into that in the Amazon world, where people will say, "Oh, we're spending a ton of money with Amazon, but we don't want to tell them what our future plans are. We don't wanna tell them about our product roadmap because security reasons. What if they leak it, what if they try to do it themselves?" On some level, like it's AWS so maybe it will actually happen.

Cory Watson: Yeah, as we saw last week.

Mike Julian: Right. When you're spending that much money with a company, when a company is such a core aspect of how you do business, for example on monitoring product, it's no longer a vendor. They're a partner.

Cory Watson: Yeah, that's an excellent way to put it. I love that phrasing because I felt that way even as a customer. I've been a customer of many companies in this context, in the monitoring, observability, whatever context system stuff, and it's true. Once that spin gets to a certain amount or when it's such a critical part of your infrastructure, these systems...

About the Guest

Josh is a salary negotiation coach who helps experienced software developers negotiate their job offers and the author of Fearless Salary Negotiation: A step-by-step guide to getting paid what you're worth.

Links

• Twitter: @JoshDoody 
• Website: fearlesssalarynegotiation.com
• Read Josh’s book, Fearless Salary Negotiation
• Josh’s Salary Negotiation Coaching services
• A detailed article on how to answer the salary history and salary expectations questions: https://fearlesssalarynegotiation.com/the-dreaded-salary-question/
• Salary negotiation email (how to write a counter offer email): https://fearlesssalarynegotiation.com/salary-negotiation-email-sample/
• Salary increase letter (how to write an email asking for a raise): https://fearlesssalarynegotiation.com/salary-increase-letter-sample/

Transcript

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: Alright folks, I've got a question. How do you know when your users are running into showstopping bugs? When they complain about you on Twitter? Maybe they're nice enough to open a support ticket? You know most people won't even bother telling your support about bugs. They'll just suffer through it all instead and God, don't even get me started about Twitter. Great teams are actually proactive about this. They have processes and tools in place to detect bugs in real time, well before they're frustrating all the customers. Teams from companies such as Twilio, Instacart and CircleCI rely on Rollbar for exactly this. Rollbar provides your entire team with a real-time feed of application errors and automatically collects all the relevant data presenting it to you in a nice and easy readable format. Just imagine — no more grappling logs and trying to piece together what happened. Rollbar even provides you with an exact stack trace, linked right into your code base. Any request parameters, browser operating system and affected users, so you can easily reproduce the issue all in one application. To sweeten the pot, Rollbar has a special offer for everyone. Visit rollbar.com/realworlddevops. Sign up and Rollbar will give you $100 to donate to an open source project of your choice through OpenCollective.com.

Mike Julian: Hi, folks. I'm Mike Julian, your host for the Real World DevOps podcast. My guest this week is Josh Doody, a good friend of mine and who is also a salary negotiation coach for engineers and author of the book, the Fearless Salary Negotiation. His articles have appeared in glassdoor.com and any number of other locations and he's amusingly also been interviewed live on the BBC, which was kind of cool when I found out about that. Josh, I'm just imagining BBC calling you and you're like, "Oh, shit. I should probably put some pants on."

Josh Doody: I already had pants on. I was at Starbucks and I started tweeting back and forth with whoever the producer was, and then within 45 minutes I was live on the air on international TV on the BBC being interviewed from my office. So that was interesting.

Mike Julian: Yeah, that's pretty cool. Yeah. I don't know too many people that say they've been interviewed by BBC live. So that's pretty awesome.

Josh Doody: That's a feather in my cap for sure.

Mike Julian: Absolutely.

Josh Doody: It was a pretty awesome, scary experience, and I'm really glad that it happened as quickly as it did because I think if I had time to think about the fact that that was going to happen I could've gotten nervous, but I didn't have time to get nervous. I literally was just scrambling to get some kind of lighting in my office and make sure my camera was working. So I spent 20 minutes on logistics and then I was on live international television being interviewed on BBC, and then it was over. Three minutes later it was done.

Mike Julian: That's a lot of work for such a short little time. So I want to talk to you today about salary negotiation, job negotiation, asking for raises, this whole gamut. But where I want to start is everyone's favorite topics. Everyone loves a good train wreck. So what's your favorite negotiation went totally sideways story?

Josh Doody: Well, I was thinking about this before we talked in case you asked about it, and I'm not sure I can tell you my favorite one because the only way I could tell it is if I censored so many pieces of it that it would be boring and meaningless to everyone. But the CliffsNotes for that one was it was a company that we have all heard of and use their services. They’re currently a private company. And just throughout the negotiation it was one red flag after another of my client trying to negotiate and then the company freaking out when he questions the value of their equity, which they're a private, so it's just monopoly money basically. And just one thing after another where the recruiter was just basically losing his mind, and eventually my client, even though this company had offered him more money, decided just to stay put. He was like, “You know what? I'm not going to go work there because if they're treating me like that right now I can't imagine what it's like to work there."

Josh Doody: But there's another one that can be a little bit less vague. It was a similar story, but this is a nice little way to kind of kill two birds with one stone because people like to ask, “Well, what happens if my job offer gets rescinded when I negotiate?” And my answer to that is I always tell my clients, I say ... They're like, "If we do what you're telling me to do are they going to rescind the offer? Are they're going to get mad at me?" I say, "Listen, I can't tell you that there's a 0% chance that will happen. It's greater than zero, but it's so small I can't even see it like on the graph." But it does happen occasionally. I think I've had I want to say two, maybe three clients in almost three and a half years that this has happened to.

Josh Doody: But I had a client who was going to work for an engineering firm. He was an experienced mechanical engineer. He got a pretty compelling offer from this company, but he knew that there was room to negotiate just based on market value research and some other kind of rudimentary stuff. And up to this point, there had been ...

About the Guest

Matty Stratton is a HumanOps Advocate at PagerDuty, where he helps dev and ops teams advance the practice of their craft and become more operationally mature. He collaborates with PagerDuty customers and industry thought leaders in the broader DevOps community, and back when he drove, his license plate actually said “DevOps”.

Matty has over 20 years experience in IT operations, ranging from large financial institutions such as JPMorganChase and internet firms, including Apartments.com. He is a sought-after speaker internationally, presenting at Agile, DevOps, and ITSM focused events, including ChefConf, DevOpsDays, Interop, PINK, and others worldwide. Matty is the founder and co-host of the popular Arrested DevOps podcast, as well as a global organizer of the DevOpsDays set of conferences.

He lives in San Francisco and has three awesome kids, who he loves just a little bit more than he loves Doctor Who. He is currently on a mission to discover the best pho in the world.

Links

• Twitter account: @mattstratton
• Website: mattstratton.com
• Arrested DevOps podcast
• Bryan Berry’s article: You Should Start a Technical Podcast

Transcript

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: Alright folks, I've got a question. How do you know when your users are running into showstopping bugs? When they complain about you on Twitter? Maybe they're nice enough to open a support ticket? You know most people won't even bother telling your support about bugs. They'll just suffer through it all instead and God, don't even get me started about Twitter. Great teams are actually proactive about this. They have processes and tools in place to detect bugs in real time, well before they're frustrating all the customers. Teams from companies such as Twilio, Instacart and CircleCI rely on Rollbar for exactly this. Rollbar provides your entire team with a real-time feed of application errors and automatically collects all the relevant data presenting it to you in a nice and easy readable format. Just imagine — no more grappling logs and trying to piece together what happened. Rollbar even provides you with an exact stack trace, linked right into your code base. Any request parameters, browser operating system and affected users, so you can easily reproduce the issue all in one application. To sweeten the pot, Rollbar has a special offer for everyone. Visit rollbar.com/realworlddevops. Sign up and Rollbar will give you $100 to donate to an open source project of your choice through OpenCollective.com.

Mike Julian: Hi folks, I'm Mike Julian, your host for the Real World DevOps podcast. I'm here speaking to Matty Stratton today, DevOps advocate for PagerDuty and the host of my arch nemesis, the Arrested DevOps podcast. Welcome to the show.

Matty Stratton: Thanks Mike, I'm really excited to be here. It's always fun to be a guest on somebody else's show because you do a lot less work.

Mike Julian: Ain't that the truth? I've been watching or listening, I guess as it is, the Arrested DevOps podcast for, God since it began; it feels like a million years ago at this point.

Matty Stratton: It's over five years. December 2013 is when we started. I should know off the top of my head how many episodes we have but I don't. In the hundreds.

Mike Julian: Somewhere between five and 50,000.

Matty Stratton: Right. It's a non-zero number.

Mike Julian: Something that we were talking about before we started recording, was this idea of, there's a lot of people that shift from doing ops work into I guess you could call it an influencer role, where we're talking about the work and helping other people become better. It seems like that's what you've done five plus years ago with the Arrested DevOps as well as what you're doing now with developer advocacy or DevOps advocacy, whatever you want to call it. Is that about right?

Matty Stratton: I would say so. I have found that when I try to explain to people what I do for a living now, I say I worked in operations for 20 years and now they pay me to talk about it. But I didn't start out that way. The journey for Arrested DevOps was, it never started out to be a podcast. I didn't know what it was going to be, but when I was starting to learn about DevOps and started to do some DevOps transformation at an organization I was at, I was taking in a lot of the podcasts of the time, DevOps Café and the Ship Show and Food Fight. The one thing that I found was there was a lot of material out there that was related to DevOps but there wasn't a lot of stuff that seemed suited to people like me who were kind of dumb, for a better word. Just maybe a better way to say that is people who are very new to it. I actually originally intended to start a blog because I had done a lot of blogging, been blogging for years and years and years. I wanted to create a blog that was going to be very accessible. I don't remember if it was on Facebook or Twitter or somewhere when I was looking for ideas for what to call this blog and my friend Jessica, who is not in the tech industry, she's a writer. She's the one who coined the name,” Arrested DevOps.” I bought the domain but I didn't have anything to do with it for a while. I decided maybe I'll start a podcast. One thing I know about myself is I'm very good at starting things and very bad at doing them.

Mike Julian: Aren't we all?

Matty Stratton: Yeah. One of the things that helps with that is having a partner or having somebody else that keeps you accountable.

Mike Julian: Oh yeah.

Matty Stratton: I had met this cat named Trevor at an Azure meetup in Chicago and was like, he's a software engineer type and into this DevOps stuff and was like, "Hey Trevor, maybe we should do a podcast." That was back in November of 2013 — we did our first episode I think in December of ‘13. But what's interesting is how this, it never was intended to be in an influencer role. What I wanted to do was be able to take things that I was learning and make things accessible. One thing I learned very quickly with doing the show and Mike, I mentioned you've learned this lesson similarly with your newsletter and the show now, you can't control your audience.

Mike Julian: No, not at all.

Matty Stratton: Even in our very first episode, we had people who were tweeting at us because we used to live str...

About the Guest

Dan spent 12 years in the military as a fighter jet mechanic before transitioning to a career in technology as a Software/DevOps Engineer/Manager. He's now the Chief Architect at the National Association of Insurance Commissioners. He's leading the technical and cultural transformation for the NAIC, a non-profit focused on consumer protection in the insurance industry. Dan is also an organizer of the DevOps KC Meetup and the DevOpsDays KC conference.

Links Referenced: 

• Insure U: created by the NAIC for consumer insurance education 
• Dan’s talk at DevOps Enterprise Summit 2018 
• State Ahead Strategic Plan from NAIC
• Explore technology proposals, fiscal budget proposals, etc. on the NAIC site 
• Dan’s website

Transcript

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: Alright folks, I've got a question. How do you know when your users are running into showstopping bugs? When they complain about you on Twitter? Maybe they're nice enough to open a support ticket? You know most people won't even bother telling your support about bugs. They'll just suffer through it all instead and God, don't even get me started about Twitter. Great teams are actually proactive about this. They have processes and tools in place to detect bugs in real time, well before they're frustrating all the customers. Teams from companies such as Twilio, Instacart and CircleCI rely on Rollbar for exactly this. Rollbar provides your entire team with a real-time feed of application errors and automatically collects all the relevant data presenting it to you in a nice and easy readable format. Just imagine — no more grappling logs and trying to piece together what happened. Rollbar even provides you with an exact stack trace, linked right into your code base. Any request parameters, browser operating system and affected users, so you can easily reproduce the issue all in one application. To sweeten the pot, Rollbar has a special offer for everyone. Visit rollbar.com/realworlddevops. Sign up and Rollbar will give you $100 to donate to an open source project of your choice through OpenCollective.com.

Mike Julian: Hi folks. I'm Mike Julian, your host for the Real World DevOps podcast. I'm here with Dan Barker and the chief architect for the National Association of Insurance Commissioners. Welcome to the show Dan.

Dan Barker: Hi Mike, it's great to be here.

Mike Julian: So National Association of Insurance Commissioners, it's like the four least interesting words in one title I've ever heard. What in the world do you do?

Dan Barker: We thought if we combine them that it would be more interesting, that may not have had the intended effect. So the NAIC is a nonprofit, about 150 years old. We kind of got our start organizing events for insurance regulators, so primarily the chief insurance regulators for each state and territory and we organize events to get them together. And we also created model law. Over time, as technology advanced, we started to host some centralized technologies within the NAIC and providing a lot of the back-end applications that regulators use. We also offer something called Insure U, where you can go and learn about insurance, all kinds of insurance, I'm sure that it will get flooded now.

Mike Julian: Because we're all chomping at the bit about insurance.

Dan Barker: Yeah. And so we still do a lot of the event planning, taking regulators and kind of informing them on technology. There's a big movement in Insure-Tech with tons of investment right now. And so we're trying to make sure everyone is staying up to date with things like blockchain, AI, a lot of the data-focused stuff particularly around unconscious bias and the data and how to clean that out. So we're a pretty diverse group and we have a lot of kind of different focuses but one of those is the technology side and I'm the chief architect and leading up a lot of the technological transformation as we move to Amazon Web Services, moving everything to the cloud and moving to some more open source tools and trying to move towards a DevOps culture.

Mike Julian: That sounds like a pretty fascinating situation.

Dan Barker: Yeah, it's really exciting. We have all kinds of new tools and new things. We're moving towards ... This company has done a pretty good job of standard blocking and tackling actually, what you might be surprised at in a nonprofit.

Mike Julian: Right.

Dan Barker: One of the only companies I've ever even heard of that had one version of Java and that has been-

Mike Julian: That's pretty impressive.

Dan Barker: Yes, I continue to ask in every meeting if that's true, and-

Mike Julian: Are you sure?

Dan Barker: Yeah. I'm sure there's one somewhere around here. But yeah, for all of our applications, they're all on the same version of Java and it's up to date to you know, like Java 4.

Mike Julian That's pretty impressive, congratulations.

Dan Barker: Yeah, so it's a great base to start on. And it's been a great journey so far. I've been here for a year and the CTO that kind of came in to start this off has been here for, I think about three years. So it's about the length of the transformation so far.

Mike Julian: Okay. So we're talking about transformation here. You actually gave a talk about this at DevOps Enterprise Summit in Vegas earlier this year, or 2018. What was the problem that started this entire transformation process? What were you trying to solve?

Dan Barker: So, we had several different opportunities that we were looking to kind of utilize moving forward. So we have this infrastructure that has been ... We're a nonprofit, so we don't have a ton of funding and it's been a bit challenging. So we haven't been able to move as efficiently because we haven't optimized a lot of our technological systems, much of what we have has been more by request, kind of an IT department within a company, non-technical company. And so we're trying to move towards being more of a technology company which requires a little bit more proactive planning. So one of those areas we're trying to gain some efficiencies, gain some efficiencies across all the different teams. So trying to standardize a lot of our [inaudible 00:06:30] me...

About the Guest

After many years of ghostwriting, Emily Freeman made the bold (insane?!) choice to switch careers into software engineering. Emily is the author of DevOps for Dummies (April 2019) and the curator of JavaScript January — a collection of JavaScript articles which attracts 30,000 visitors in the month of January. A former VP of Developer Relations, Emily is a CloudOps Advocate at Microsoft and lives in Denver, Colorado.

Links

• Website: emilyfreeman.io
• Twitter:  @editingemily

Links Referenced

• Book recommendations: 
  • Monitoring with Graphite by Jason Dixon
  • Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale by Jennifer Davis and Ryn Daniels
• Emily’s talks: 
  • Humpty Dumpty + DevOps
  • Scaling Sparta
  • Dr. Seuss Guide to Code Craftsmanship

Transcript

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: All right folks, I've got a question. How do you know when your users are running into showstopping bugs? When they complain about you on Twitter? Maybe they're nice enough to open a support ticket? You know most people won't even bother telling your support about bugs. They'll just suffer through it all instead and God, don't even get me started about Twitter. Great teams are actually proactive about this. They have processes and tools in place to detect bugs in real time, well before they're frustrating all the customers. Teams from companies such as Twilio, Instacart and CircleCI rely on Rollbar for exactly this. Rollbar provides your entire team with a real-time feed of application errors and automatically collects all the relevant data presenting it to you in a nice and easy readable format. Just imagine — no more grappling logs and trying to piece together what happened. Rollbar even provides you with an exact stack trace, linked right into your code base. Any request parameters, browser operating system and affected users, so you can easily reproduce the issue all in one application. To sweeten the pot, Rollbar has a special offer for everyone. Visit rollbar.com/realworlddevops. Sign up and Rollbar will give you $100 to donate to an open source project of your choice through OpenCollective.com.

Mike Julian: Now folks, welcome to the Real World DevOps podcast. I'm here with Emily Freeman, Cloud Advocate at Microsoft. Welcome to the show, Emily.

Emily Freeman: Thank you, thank you so much for having me.

Mike Julian: Yeah, so for the folks who aren't as familiar with developer advocacy or developer relations or developer evangelism or the 50 bajillion other names that they go by, can you tell us what is that you do? What are you doing for Microsoft?

Emily Freeman: Yeah, absolutely. Along with the 50,000 names for developer relations, there are also 50,000 interpretations of the actual job. It will vary company to company and person to person. For me in Microsoft I like to say that, because I have a background in writing and I was a writer before I was a developer, I like to tell stories. My job is to tell the stories of the developers in the communities I am in and serve and represent. The most important role I think I play at Microsoft is bringing customer feedback back to the product teams. When I go to a conference, I am never one to just like helicopter in, give my talk and then peace out. I think that's just poor form and it doesn't benefit anyone at that point but my ego. My job really is to go and talk to people and to hear all their feedback, positive and negative. It's not personal, it's about making the product better for the community.

Mike Julian: That sounds like a much more reasonable job than you would hear from like reading shit shows on Twitter.

Emily Freeman: Yes, absolutely.

Mike Julian: That might be a good segue to the recent total shit storm that happened on Twitter about developer relations. I don't even know how these things started. It just suddenly appeared one day.

Emily Freeman: Yeah, and the criticisms from this last one aren't new. This is just one iteration of the sort of dev overall hate, which is like, on a very personal point, it's hurtful because it's like, “Okay this is my work, this is what I care about. I'm passionate about this and obviously I dedicate all of the time I spend at work to this role.” To hear that it just has no value or that we are simply low-key Twitter celebrities that our company shields and drink champagne on planes and party.

Mike Julian: That sounds like a fantastic life, can I get that job?

Emily Freeman: I know. I was telling someone I'm going to Milan next week for Microsoft Ignite | The Tour. It's very exciting, I've never been in Italy, I'm thrilled. I was just telling them like, "I sound a lot cooler than I am. I just got from Toronto and I'm going to Milan." No, I'm just on the plane sad. Yeah, the travel is part of it, I think it's the part that people cling on to. I also think that we as an industry have not done a great job recently at actually representing what the work is. Yeah, I think so much of the emphasis has been around Twitter and a lot of the developer relations folks especially the people Microsoft is picking up, have really — if not enormous Twitter following — substantial ones.

Mike Julian: Well they are already super well-known people to begin with in their own right.

Emily Freeman: Yeah, but there's a cult of personality thing happening. I think when we have that and when we focus so much on the persona and that sort of Twitter platform, then we lose the actual benefits of developer relations, both for the community and the company that they work for.

Mike Julian: Yeah, so some of the criticisms that I saw, you alluded to this one, that you are the representative of a company, but when you're speaking on behalf of the company, you're not saying that you are. Therefore, it's like influencer stuff, but you're not saying that you are. You're not divulging where you're getting your pay from. To me this sounds like a dubious argument, because your employer is right there on your profile.

Emily Freem...

About the Guest

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.

Links Referenced: 

• Connect with Greg on LinkedIn

Transcript

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 pan...

About the Guest

Yan is an experienced engineer who has run production workload at scale in AWS for nearly 10 years. He has been an architect and principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. He has worked extensively with AWS Lambda in production, and has been helping various UK clients adopt AWS and serverless as an independent consultant.

He is an AWS serverless Hero and a regular speaker at user groups and conferences internationally, and he is also the author of Production-Ready serverless.

Guest Links

• Yan’s blog
• Yan’s video course: Production Ready Serverless
• Find Yan on Twitter (@theburningmonk)
• Subscribe to Yan’s newsletter 
• Centralised logging for AWS Lambda

Transcript

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, I'm here with Yan Cui, an independent consultant who helps companies adopt serverless technologies. Welcome to the show, Yan.

Yan Cui: Hi Mike, it's good to be here.

Mike Julian: So tell me what do you do? You're and independent consultant helping companies with serverless. What does that mean?

Yan Cui: So I actually started using serverless quite a few years back, pretty much as soon as AWS announced it, I started playing around with it and the last couple of years I've done quite a lot of work building serverless applications and production. And I've also been really active in just writing about things I've learned along the way, so as part of that, a lot of people have been asking me questions because they saw my blog and talk about some problems that they've been struggling with, and asked me, "Hey can you come help me with this? I got some questions." So as part of the doing that, I like to help people, first of all and then just part of doing that is something that's been happening more and more often, so in the last couple months I have started to work as an independent consultant, helping companies who are looking at docking serverless or maybe moving to serverless for new projects and want to have some guidance in terms of things they should be thinking about and maybe have some architectural reviews on a regular basis. So for things like that, I've been helping with a number of companies, both in terms of workshops but also regular architectural reviews. And at the same time, I also work part-time at a company called The Zone, which is a sports streaming platform and we also use the serverless and is contained very heavily there as well.

Mike Julian: Okay, so why don't we back up like several steps. What the hell is serverless? Just to make sure that we're all talking about the same thing. What are we talking about?

Yan Cui: Yeah that's a good question, and I guess a lot of people has been asking the same question as well because now they say you see, pretty much everyone is throwing the serverless label at their product and services. And just going by popular definition out there based on what I see in the talks and blog posts, I guess in terms of my social media circle, I guess by the most popular definition, serverless is pretty much any technology where you don't pay for it when you are not using it because paying for OpTime is a very serverful way of thinking and planning, and two is, you don't have to worry about managing and patching servers because installing demons or Asians or any form of subsidiary or support software on it is again, definitely tied to having servers that you have to manage. And three, you don't have to worry about scaling and positioning because the systems just scale a number of underlying servers on demand. And by this definition, I think a lot of the traditional backend server's things out there like AWS S3 or Google BigQuery, they also qualify as the serverless as well.

Mike Julian: Okay, so Lambda is a good example of serverless, but there's also this thing of like a function as a service and they seem to be used interchangeably sometimes. What's going on there?

Yan Cui: So to me, functions as services, describes a change in terms of how we structure our applications and changing the unit of deployment and scaling to the function level that makes every application. A lot of the function and server solutions like a dual function or Lambda as you mentioned, they will also qualify as serverless, based on the definition we just talked about and generally I find that there are a lot overlap between the two concepts or paradigms between functions and service and the serverless. But I think there are some important subtleties in how they differ because you also have functions of service solutions like Kubeless or Knative that gives you the function oriented programming model and the reactive and event driven module for building applications, but then runs on your own Kubernetes cluster.

Yan Cui: So if you have to manage and run your own Kubernetes cluster, then you do have to worry about scaling, and you do have to worry about patching servers, and you do have to worry about paying for op time for those servers, even when no one is running stuff on them. So the line is blurred when you consider Kubernetes as service things like Amazon’s EKS or Google GKE where they offer Kubernetes as a service or Amazon's Fargate, which lets you run containers on Amazon's fleet of machines so you don't have to worry about positioning, and managing, and scaling servers yourself.

Yan Cui: At the end of the day, I think being serverless or having the right labels associated with your product is not important. It's all about delivering on business needs quickly, but having a well understood definition on those different ideas that we have, really helps us in terms of understanding the implicit assumptions we make when we talk about something. So now that everyone is talking about calling their services or prod...