Cloud Therapy: EP 007 – Automate Server Tasks to Level Up in IT

Steve Tarver, Principal Engineer at CenturyLink discusses several ways IT professionals and Sys Admins can “Level Up,” and become an extremely valued and sought-after professional, through using automation and shifting to a Dev Ops mindset.

Want to hear more Cloud Therapy? Find us on iTunes and Stitcher!

Thousands of cloud and telecom service providers… Click below to skip to your company’s top 3 “best fit.”

MY TOP 3

See full transcript below:

  Mike:    Are you a sysadmin or IT manager, and you’re working for a company and you really want to move up, and you really want to listen to podcasts all the time that tell you about new ideas that are going on in the industry, and listen to the people who are in the forefront of innovation in terms of IT? You really want to do all these things, but you have no time? You are so busy keeping the lights green every day and putting out fires that there’s no way you have any amount of time for self-improvement or career improvement? Well, if that’s the case, today, I have an awesome guest for you. His name is Steve Tarver. He’s the Principal Engineer at CenturyLink. The cool thing about Steve is he is a great person to have this conversation because he is, basically, doing a very similar job for CenturyLink that you guys are doing currently. He knows what it’s like – he’s been in the trenches – and he’s found ways to free up his time through little tips and tricks he’s done through automating some things, through changing his mindset on a couple of things. I think it’d be really interesting for you guys to hear it. At the very least, I think, you guys will get a couple of great reminders.

We also have a free gift to offer you today, as we always do. This is a list of questions that if you’re shopping for Cloud VM providers, you definitely have to ask yourself prior to shopping. It will help you and your IT team find the best Cloud VM provider quickly.

To get that list of questions, I think there’s twenty-five or so, I took hours, and hours, and hours talking to all these different Cloud VM service providers, ones that you’ve heard of and ones that you’ve never heard of, and asking them what they do well. Based on those conversations, I created a list of questions that will help you find providers like this.

If you want the list of questions that took me hours to compile, I’ll give it to you for free. All you have to do is text the word “CLOUDVM” to the number 44-222. Again, just text the word “CLOUDVM” to the number 44-222 and we will email you a free list of all those CloudVM questions.

Alright. Let’s get to this interview with Steve Tarver.

Hi, Steve. Thanks for coming on the program.

Steve:   Hey, Mike. Glad to be here.

Mike:    Awesome. Can you take a minute to fill in the blanks a little bit and tell us a little bit about yourself both professionally and personally?

Steve:   Sure. I live out in the Colorado Mountains, elevation 8450, at a town that’s so small, it doesn’t even have residential postal service, and I just love it. My wife and I live a couple of blocks from the White River National Forest, so in the winter there’s lots of snowboarding, snowshoeing, and getting into the backcountry, in the summer lots of mountain biking, and hiking, and getting into the backcountry.

Mike:    Wow.

Steve:   Yeah, it’s cool. Beyond that, I’m a foodie. I really like Mexican, Indian, and Italian food. I usually enjoy my own cooking the most. I use yoga to keep my head and body in shape and I really enjoy experiencing other cultures through music, food, and their stories.

Mike:    Awesome. Wow, you are a well-rounded individual. That’s awesome.

Steve:   Yeah, it’s a lot of fun – keeps me busy.

Professionally, I’ve been in the programming game for a couple of decades now. I’ve worked in research, and startups, consultancies, small businesses, and large corporations – had a lot of diversity there. I’ve been involved with Science, shrink wrapped developer tools, computer languages, financial industry, real-time data distribution, server automation, and common IT functionality. Today I’m working with the CenturyLink Cloud Business Unit, more specifically, with the Database as a Service team.

Mike:    That’s great. That’s awesome. How long have you been with CenturyLink?

Steve:   Through various purchases and reorganizations, just celebrated my ten-year anniversary.

Mike:    Oh, wow. So, you’re a long-timer over there.

Steve:   Yeah. They’re doing something right – keeping me around.

Mike:    And that’s cool you get to live in the mountains at the same time.

Steve:   Definitely.

Mike:    Yeah, that’s fun. Okay, great. Tell us a little bit about what you’re going to talk to us about today.

Steve:   Let’s start with where I work. I work in a DevOps environment. This is a two-pizza sized teams, agile processes – you’ve got a product owner, an analyst, an engineering manager, and a contributor. I really enjoy this work environment compared to the traditional IT, kind of, monolithic efficiency approach.

The difference there, when people make this migration – this is the future of enterprise IT – is that we can take a couple of these ideas and incorporate them into our work as sysadmins and really clear our work schedules, get rid of the tedium, and allow us to focus on the important things. So, no matter where you or your organization are in migration from a traditional enterprise IT to a cloud-based enterprise IT or just cloud adoption, you  can incorporate some of these DevOps ideas, and really eliminate the tedious work, level up your skillset, build your resume, generally, become a highly desirable employee above what you already are.

Mike:    That’s really cool. My mistake, sorry. I meant to ask you a little bit about what your day-to-day is right now with CenturyLink. You mentioned it a little bit. You mentioned you’re, kind of, in a DevOps environment. Can you give us a background on what your role is at CenturyLink and how that applies to DevOps?

Steve:   Well, as we piece DevOps together, we’ve got these different, kind of, big roles, like, the product owner owns the vision of the product, the analyst owns the business side of it, the engineering manager is the head of all the other people that are just contributors. The contributors are going to be DBAs, and operators, sysadmins, business developers. I’m a principal engineer, that’s really just a title and those get, kind of, weird between companies. What does that mean in software engineering? It means you have some mastery of some programming languages, broad technology, and framework knowledge, you have built large systems, but most importantly, to me is you have whole product concern, and responsibility, and some leadership skills.

So, how does that play out? Well, I get to move around a little bit. Last year, I was investigating new implementations and sales strategies for a sagging business sector. Then, this year I was assigned the database as a service team. Man, I’m just a contributor on that team. I go out and I code features every day. Also, I’m looking at new technologies and processes, and trying to figure out how we can incorporate those into our system to really smooth out our processes and make us a really high-scale, high-performing team, and then also figure out how that applies to other teams in the larger organizations, so that we can propagate those best practices throughout the whole organization.

Mike:    Okay. So, you not only work for a service provider who, obviously, sells services that can be sold to the sysadmins, and DevOps teams, and so forth, but you actually do that job on a day-to-day basis as well, so you, kind of, know both sides of the fence.

Steve:   Yeah. We’re building the product and we’re living the dream. We’ve constructed a great work environment, and they take in the consideration, everything from what your office looks like to your process, business process, and your development process.

Mike:    Cool. Yeah. So, you’re going to talk to us a little bit about how to, like you said, clear the clutter and increase the amount of time that you can spend on the fun stuff, right?

Steve:   Sure.

Mike:    Alright, let’s dive into it.

Steve:   So, when I look at this… I’m really interested in this space where we have the traditional enterprise IT and we’re trying to migrate, trying to level up, improve our businesses, our corporations, and also our personal lives. When I look at that, and I talked a little bit about how we can pull in some of these DevOps ideas no matter where we are and use them to improve ourselves and make a bigger contribution to the corporation.

I also get to see a lot of individual teams go through this migration, so I see patterns emerge and that’s where I came up with some of these ideas. So, the first ideas are reimagining yourself as an ops developer. The reason this is important is because many operators are so busy keeping the lights green that they have no time to think about how they work or how they improve their situation. So, what if you took the simple step of reimagining yourself as an ops developer instead of a sysadmin or an operator?

In the DevOps world, we have the notion of business developers and ops developers. Ops developers believe the mantra “Automate or die” and they focus on programming to solve their problems. They use IT automation tools like Ansible and Saltstack, and Chef, or Puppet to manage infrastructure, and language is like Python or Ruby to interact with the platform as a service and the various service APIs to automate or in remediation.

This family of IT automation – and I’ll use Ansible as a concrete example – they let you define your infrastructure. They’re usually declarative in nature and you define the end state that you want.

So, today, I might get a ticket requesting a new web server. I’ll go out, and I’ll create the server, and I’ll SSH to it, apt-get update, apt-get install Nginx, and then service nginx start.

In contrast, in Ansible, I’ll write a role-named web server and then a yaml file in the role, it’ll have an apt-get update and install, and do the service start. Then, in the playbook, I can call the API to create the server. So, now I’ve got one line that I can execute from my command line that will run this complete Ansible playbook, and is going to create the server, and applies the role “web server” to that new VM.

Now, instead of twenty or thirty minutes, maybe to remember how to set up NGINX and actually do it, I can Ansible up the NGINX playbook one shell command. Beyond that, you could define a corporate standard with much more sophisticated configuration and everybody could use that. Then, beyond that, you can evolve the role to remove old versions and install new ones to upgrade a fleet of servers. So, see how we’re building on this, kind of, atomic unit to get more and more value out of it, but each thing is a programming step.

Mike:    Got it.

Steve:   Now imagine if you apply that approach to the HAProxy that sits in front of the web server, the middle or large server, and the data stores, so it’s your whole stack. Also, remember that you’re going to have to do this for a new product in dev, in QA, and also in prod. Look at all that time that you’re saving.

So, each of these IT automation tools is pretty cool and they have their own way of managing server drift and, of course, updating server-installed software. There’s a little bit of a learning curve, but there are a ton of Ansible playbooks on Github that will provide great starting points for NGINX or any of these common infrastructure components. All you have to do is start with one of those and evolve it to suit your needs. So, that’s getting all of your infrastructure in place, controlling drift, like, people go out and mess with the circle a little bit, and you want to bring it back to a known state.

But, what about remediation? Let’s say you resize your attached storage, and you df -h, and the and the size is just not right, so you figure out how to rescan the devices and correct the problem. Well, you can do this with an Ansible ad hoc command. This is just one command line in the shell, go out and SSH out, and run the commands that you need to remediate this issue.

The advantage of this is that you’re eliminating the SSH part and the bash script part. When you have an ad hoc command or just a very simple playbook to do this, it becomes a one-liner. You can capture all of the information that you found out while you’re investigating the error, and to remediate it, and how to make sure that it’s completed properly with this Ansible playbook or this script that runs the ad hoc command. What’s cool about that is, now you’ve captured all that knowledge, you can give this to the junior staff and that’s both a training aid and is also getting stuff off your plate.

Next, all cloud providers provide robust REST APIs for their platforms and all the services. They do a pretty good job of documenting those APIs. So, armed with Python or Ruby, it’s pretty trivial to peace these APIs together to generate useful reports or usage monitoring. All of these things come together to, really, eliminate the repetitive kind of task that you do. When you code them, it’s also very easy to give to your junior staff or even developers or other people that could safely run these fixes. So, that’s my first idea.

Mike:    That’s really cool. What I love about how you’re explaining it, Steve, is that you are using words that I have no clue what they are, but I know our audience does, which is great. There, I think, a lot of our audience is really following along with you, but from my standpoint, I still get the gist. The whole point is looking at it from – when you say like reimagine yourself as an ops developer, you’re trying to automate stuff, so you’re, kind of, taking a step back and saying, “Look at all the different processes that I’m going through. Is there a way to really automate these things and make them faster,” is that correct?

Steve:   That’s exactly it. That’s the key to that strategy is that you want to go out and do the remediation, figure out what’s going on with this bug, really understand it, and then you create one fix, and you do that one time. Then, you can use that one piece of code everywhere. You don’t have to go through that twenty or thirty that it took you to figure out what the heck is going on here?

Mike:    Yeah, that’s great. Now, just from a devil’s advocate standpoint – what do you think the one objection that a sysadmin might have to that, if we’re telling them to do that? What’s the barrier that’s really standing in their way? Is it knowledge to be able to automate it? Is it familiarity with the programs that it takes to automate it? Or, is it something else that you think might be standing in their way?

Steve:   Well, there are a couple of things. I love what motivates people and understanding that. So, at first, getting started with any of these programs – we use Ansible and Saltstack primarily. There’s a bit of a learning curve, so it takes longer and you’ve got people banging on your door, “I need this up now.” That stops you from jumping in. Then, there’s also, you know, sysadmins are the heroes, because when you’re stuff just goes crazy, they’re the guys that bring it back in line. That’s pretty addictive stuff, you know? So, being able, I guess, to combat or to counter those objections, get your system running, and then take a half hour/an hour afterwards to, kind of, retro the situation, and set aside some time to create this automation to fix this problem.

In the modern world, it’s not whether you have these alerts come up, these outages come up. That doesn’t matter. We know that’s going to happen – that’s a given. What matters is how fast you can get the systems back online. When you can recognize the key attributes of a system, apply automated remediation to it, and get that system back up in a few minutes as opposed to twenty or thirty that would take you to remember, you know, “What was really going on here and what was the fix?” man, you are going to stand out.

Mike:    Yeah. I think that’s what’s important to recognize too is sometimes it’s like, “Well, why do I put all that effort into something, into trying to do all that and go outside of my comfort zone? Hey, it’s working now and everything’s fine,” but we all want to get promoted, we all want to get recognized, we all want to put things on our resume. That’s really the mentality that will get you there, I think, is if you’re really trying to think in the company’s best interest. If you do that, although it doesn’t seem like it works out for you in the short term, it, kind of, puts more work on your plate for the same amount of money, the long term, that’s really the right thinking.

Steve:   Well, you know what it does? It starts you down this path where you have more free time and you’re elevating your thought process.    Instead of diving in and doing really repetitive things, you solve that problem and now you’re able to have some free time to think about, “Well, what other problems could I solve and get off my plate to free up more time?” You’re elevating the level of thought that you’re applying to your task.

Mike:    That’s awesome. Fantastic. Okay, what’s next?

Steve:   Well, next, I think, what a really cool idea is to create a developer proof of concept account. One thing that limits business agility is resource constraints. If developers don’t have access to on-demand temporary servers, it’s really difficult to experiment with new technologies, frameworks, or other strategies like improving your continuous delivery pipeline.

Now, if you’re lucky enough to be able to provide developers with those services very quickly… It could be one of those tedious tasks that just eat away at your day. What if, instead, you created a developer PoC account with your cloud provider and gave your developers the keys to the kingdom – let them manage it.

So, every cloud provider should be able to create a sub-account on your main account – and there are varying levels of sophistication and limiting resource use (monitoring, billing charges, that kind of stuff) – you can work with pretty much whatever any of the major providers give you. Now, you have some empowered, happy developers that are ready to really just revolutionize your org.

Now, a little bit on expectations here. When developers first get this facility, they may not know what to do with it. No worries, because no servers, no charges. But, as the developers start to wrap their heads around the idea of, “I can have a server any time I want. It only takes a couple of minutes to spin it up and I can tear it down before lunch,” man, you’ll see that facility is used more and more, and soon the developers just won’t know how they lived without it.

That’s one of the radical transformations I saw this year – just in myself, having this ability to spin up a new Percona management system or any of these other little technologies that I want to play with. It can be a short-lived server or I can let it stay around for a couple of weeks and let other people play with it and see what ideas I’m trying to promote – very cool stuff.

Mike:    Yeah. The first thing that comes to mind is, just like you said, is – will they know what to do with it? Is there anything that you suggest throwing out there to them to, kind of, spur their creativity, too, kind of get them started? Kind of like when you write a paper or you have to write something, it’s always that first paragraph, that first sentence that’s the hardest for them. Are there any suggestions or tips you might have to, kind of, spur their creativity and give them some ideas as to what they might do or where they might start? I think, there’s probably a little gap there where they’re thinking, “What could I do?” “What do I start with? I can’t reinvent the wheel on anything we’re doing.” What are your thoughts on that?

Steve:   Okay. Here’s an area that bridges operations and the business developer side: and that’s logging. How do we do logging? It’s also an underlooked, underserved market because, the developers, it’s, kind of, their own little private playground and they log what helps them develop the product. But, then, if you’re an operator, you need to read those logs, it’s like, “What in the world is going on? I’m missing this piece of information and that…”

There are two main aspects to developer-based logging. That’s going to be the kind of logging that you use to remediate a specific issue and that you use to, kind of, understand how your application is performing under load and over time. The first one is – you see this, kind of, diary-based entries, like, received a request to create a new server and then just all the steps that it takes to do it. The second thing is really interesting to operators and sysadmins and that’s the ability to understand how many requests to create a server happened this hour, last week, how does it vary over the last seven days.

So, logging systems that are typical like Splunk or the ELK Stack, those kinds of things, they’re not that good at doing that kind of thing and they’re also difficult to include all the information that you want. However, there’s another system called Prometheus, and this is one that’s coming up. It’s a really great system. It is really adept at analyzing time series-based data. So, you can set an adapter upon, let’s say, you have a job, an app, on a Tomcat. You can hook up the Prometheus server to the access log, and then pipe it into this Prometheus server, and very easily write queries to see all these information the operators want.

Very long description there, so let’s go back and recap. Developers come out and they see these new technologies like Prometheus, and it’s getting a lot of good press because it’s an outstanding system, and they want to try it out. Now, with their proof of concept account, they can go spin up a server and install Prometheus, and play with it, make that last for a day, they can tear it down, save some dollars. Then, they can stand it up again, let it run for a couple of weeks, collect some data, and let the operators play with it, let other developers play with it. This becomes their proof of concept. Do we want to include this as a standard part of our infrastructure? So, that’s a very specific example. Operations can do this do once you have this little PoC area.

Get out there and listen to the people that are changing the industry. Listen to what they have to say in the podcast. When they come up with these great ideas or an interesting technology, you can carve out in, like, a morning and go whip up a new server because it, literally, takes just a few minutes, then you SSH out to it, install the software, and you can play with it. This is the garden that all these great ideas grow in.

Mike:    Very cool. I get exactly what you’re saying. I think that’s a really good example to help spur some creativity there. Now, being someone who’s had experience with this, do you have any tips or warnings about the other side of the spectrum as far as the restraints or constraints that you want to place on these servers or, kind of, rules that you might want to set up to prevent the other thing from happening, them doing it too much or taking it too far?

Steve:   Yeah, sure. Each cloud provider is going to have a little bit different level of sophistication in the monitoring and the kind of limits that you can put on an individual account. For instance, one provider might allow you to say, “I only want this account to be able to use, say, 50 CPUs.” That’s great, but if they don’t have that, there are workarounds – you can create automation.

So, first, when you start up a new server, if you’re doing it, you can just set the lifetime of the server. Create a new server, down at the bottom you click a little box, and say, “Automatically delete the server after three days.” If you’re doing it for the developers, they can say, “Hey, I want one for three days,” and you can set it up for them or they can do that themselves. This is a great way to minimize cost.

Now, also, you don’t get charged when your servers aren’t running. One thing you can do is you can turn down all these fully-configured servers at night and on the weekend, and write an automation, as we discussed before, using Python and the platform as a service APIs.

Another thing you can do is really make the developers culpable for their account. If you can’t directly limit them, make them culpable for it. You can set up an allowance, and then you can create and automate report generation that shows how much they’ve used over the given month, what they’re tracking, say, “We’re going to let you have $250 to spend each month on servers.” When you give them that goal and you give them a way to track what they’re spending, then developers will just eat that up. You’ll be surprised at how well they stick within guidelines.

Mike:    Very cool. Great tips. Okay. Any other good points to level up?

Steve:   Well, I had one more. This is to have the developers create and manage the infrastructure automation. We’ve already talked a little bit about how Ansible, Chef, Puppet, and Saltstack work, right? We’ve identified that we have fewer sysadmins and more work to do. Let’s look at this situation. Let’s think through how augmenting existing infrastructure happens in traditional enterprise IT.

So, the developers go through – they have a new idea, they get a new product going, right? They come to you and they say, “I have a new application and I need another Tomcat to host it.” You whip up a new server, install a Tomcat, and you turn it over.

Day 2: Developer says, “I need these modifications to the server.” You apply the changes, notify the developers.

Day 3: Developer says, “I need these modifications to the Tomcat instance,” so you apply the changes, notify the developer.

By the way, there are probably some miscommunications along the way, and you had to redo some of those changes, and there are probably several reiterations.

About day 25 the developer say, “We’re ready to move the app to the testing environment,” so you repeat all the work that you did in the dev environment in a new testing environment.

Now, the developer say, about day 45, “We’re ready to move the app to prod,” so you repeat all the work that you’ve done in testing and in dev.

I go through this, kind of, long example to show just how much work there is that you’re being asked to do. Well, what if we made the developers responsible for developing the infrastructure/automation that sets up this system? Right off the bat, you’ve eliminated the communication overhead and all the miscommunications that happen – the developers are doing it themselves. You’ve also eliminated delays while one group waits on another. These both benefit the company through increased business agility, but you’ve also cleared a lot off your plate.

In this scenario, the ops developer is put in, kind of, a supervisory code review role. The business developers have their own PoC account, as we discussed earlier, and they can develop and prove-out their Ansible playbooks. Then, they can come to the ops developer for some help and a final review to make sure they’re catching the edge cases, and have proper configuration, and all that kind of stuff – that final seal of approval from operations, the experts, on infrastructure.

Mike:    Awesome. I think that makes a lot of sense because if they’re creating it, they own it. Obviously, they’re going to be hands-on and really close to what’s going on, so it gives them empowerment as well.

Steve:   I agree and that’s what I’ve seen.

Now, another hint on adoption for this… At first, developers will balk. It’s more for them to do. It’s expanding what they do. But, once they get over that hump, they get over that learning curve – this is where the operators, or sysadmins, or ops developers can help out by teaching them and get them over that hump. Once they’ve gotten over the hump, they’ll love it because they’re not waiting on anybody else – the world is in their hands. It gives them a great feeling of empowerment and control over their destiny.

Mike:    Right. Very cool. Now that they have all these free time from this great advice that you gave them, what are they supposed to do with all these time?

Steve:   Level up. Because, you know, you’re stuck just with the tedium, now you’re free to find out what all the new cool stuff is going on. There are people that are really pushing the operations and sysadmin world, people like Andrew Clay Shafer, Mitchell Hashimoto, see what they’re doing and how they approach this. All of this is going to let you think about problems at a much higher level, which is so much more satisfying and, of course, it’s a great career-builder. It makes you more valuable to your company or any other future employer.

Mike:    Absolutely. Very cool advice. Very good topic. Thank you so much for sharing all that stuff with us.

Steve:   Excellent. I was happy to.

Mike:    Alright. Now, I’d like to shift a little bit to something a little more lighthearted and quite a bit off-topic. Steve, one thing we always like to talk to our guests about is: tell us something funny – lighten our day up a little bit. Tell us, what’s the funniest, or strangest, or coolest thing you’ve ever seen in the workplace?

Steve:   Well, it’s, kind of, a constant, sort of, behavior with this new team. Let me describe a little bit where I work. Our team room is this huge rectangle with a couch and a large screen T.V. with a front. I’m a remote worker, so I sit in a Google Hangout all day on this big screen T.V. So, I can see the whole room and my head is on this big screen T.V. They’ll jack with me and put mustaches or hats on me during meetings, and sometimes maximize the hangout so there’s this giant Max Headroom, kind of, disembodied head on the T.V.

What’s great about that is somebody will come in from another team, they’re on a mission, and they’ll start a conversation with somebody sitting on the couch, and I’m right behind them. I’ll say, “Hey, Brad,” and they’ll jump and they’ll turn around. They’ll see my huge head and their face is just perfect. Is that a big brother kind of funny? I don’t know. It never gets old.

Mike:    That’s cool. Yeah, it’s almost like borderline prank. I mean, it just sets up so many possible pranks. That’s awesome.

Steve:   Well, it’s like that though. It’s, kind of, like a frat house. I’m sitting in this hangout and I can see everyone in the room, kind of, like a reality T.V. show. I’ll watch plans unfold and one Nerf ball or Nerf dart will fly across the monitor fence in the middle of the room. Then, another, and then retaliation, and then sometimes there’ll be a minor skirmish that breaks out. It’s really cool to watch a bunch of thirty-something nerds just pranking and laughing at work.

Mike:    That’s pretty cool. Now, I’m just curious. Is the Google Hangout – is it set up all day long? Are you, basically, on the screen all day long or is it just certain periods of time where you pop in and you’re talking to a couple of people? Or, is it just like constantly monitoring you like big brother, like you’re sitting there?

Steve:   Well, you know, it’s a little bit like big brother, but you can change the way that you think about it. I’ve got my hangout right in front of the camera, so I’m making good eye contact with the people, and they’ve got theirs, and they can see me and see what I’m doing. Maybe I’ll have my headphones off and they’ll know I’m not listening or I’ll be blanked out.

What’s really cool about it is anybody can walk up to me anytime and just start talking. They’ll come down, they’ll bring their computer up, sit down on the couch, and ask me a question, or they can yell at me from across the room, and I can Screenhero, you know, write to them directly, we can pair program on it. In the DevOps world, there’s a lot of pair programming that goes on. Like this morning, we sat down, everybody at the couch, me at the Google hangout, and we’re writing Ansible roles and playbooks. Pretty cool stuff.

Mike:    That is pretty cool. I guess, my self-conscious side of me is just thinking like, “Gosh. Am I sitting there with my jaw wide open all day long staring and everybody’s seeing me in a way that I don’t want to be seen?” Heaven forbid I pick my nose or something and forget that I’m on camera, and everybody’s like, “What is he doing over there?” or something, I guess. But, after a while, you probably just get used to it, huh?

Steve:   Yeah. You’ve got to be able to laugh at yourself. We don’t really have cubes or anything like that. It’s a big open space, everybody sits next to each other, so people are going to see you if you’re doing that anyway.

Mike:    That’s hilarious. That’s great. So, are they watching you right now as we speak?

Steve:   No, I turned that off. It’s too distracting.

Mike:    Yeah. I was thinking, yeah, they’re going to be like, “Hey, quick question,” and you’re going to be giving them sign language like, “Not now. On. Podcast.”

Steve:   Yeah. Heavy on the sign language, probably.

Mike:    Yeah. That’s cool. Alright. Now that we’ve learned a little bit about you and, obviously, know that you know what you’re talking about when it comes to DevOps, and sysadmins, and some really good tips, why don’t you take a minute about to tell us a little bit about what’s going on at CenturyLink that you’re excited about and what everybody should know about what you guys are doing?

Steve:   Yeah, great. Well, since your audience already knows telecom, they probably know CenturyLink for its telecom and its networking chops, but CenturyLink is a huge company. It’s like 43,000 employees.

Mike:    Holy cow. That’s a lot.

Steve:   It’s vast. The telecom and networking isn’t all they do. Two years ago they bought Tier 3 to gain a stronger position in the cloud marker and that’s the part of the company that I work in, more specifically, as I mentioned before, with database as a service team.

So, following on our team of simplifying a sysadmin’s life, what if you or your developers could just press a button and have a database in a couple of minutes? You wouldn’t have to create a server, SSH to it, and then apt-get update/install dance, set up the password, set up backups, maybe do a little tuning – you or the developer would just press a button. This really changes the game when you’re thinking about developer PoCs. These are MySQL compatible databases that we have tuned for a well-balanced read/write load. They already have backups running nightly and you have a replication option for when you move your app to prod.

Developers have easy access to the database through the MySQL workbench. So, as a PoC, developers will probably start with a 1 CPU, 1 Gb RAM, 1 Gb disk kind of database, and then as they load test, they can push another button, maybe a couple of buttons, and push the CPU count, the RAM, the storage to tune it to what’s expected for the production load.

The service that we provide, this DBaaS (database as a service) has a full public API, so you can provision databases and your infrastructure automation, as we talked about before. This can be just a normal part of your stack. Our services went GA at the end of January and we’re adding features at a pretty rapid clip.

If you want to try this out, new customers have a free trial. This is really easy to sign up for. You can go to http://www.ctl.io and click “Free Trial” at the top right – this little button. You’ll get a verification code on your phone, you enter that, enter some personal details and a credit card, and you get $500 in credit. If you are going to use this just for the database service, to try it out, you get a 1 CPU, 1 Gb RAM, 1 Gb disk database for $0.02 an hour – that’s $16.50 a month. So, if you ran this database 24/7, you can run it for 30 bucks just for free, just to try this system out. Now, you can use that credit on any of the other facilities as well.  So, that’s all pretty cool stuff.

One of the other cool things that we do at CenturyLink is every team contributes to the blogs. We have some pretty nice blogs. I’d like to encourage people to go out and look at what we have to say about, kind of, the whole, well, every way that we work. You can go out there and find things like how we get the best use out of Chef, how our agile processes work, how we redesigned our offices to focus on engineering joy and really easy, impromptu collaboration.

There are also, of course, articles about getting started on the platform, using the services, and building applications with our Ansible, Node, Java, .Net, PHP, Python, all the SDKs that we provide to make it easy to interact with our platform. We can probably put the URLs in the show notes.

Mike:    Absolutely. If any of our listeners are thinking about some of your products or would just like to maybe chat with you about a couple of things they are thinking about regarding the topic that you brought up, would you be okay if they contacted us if we set up, like, a three-way call or something like that?

Steve:   Sure. I’m sure we can work something out.

Mike:    Awesome. Fantastic. So, if anybody wants to talk to Steve about something specific, just shoot us an email. Tell us what you’d like to talk to him about and we’ll send it over to him and try to set something up. But, other than that, it’s been fantastic. Thanks a lot for coming on the show today, Steve.

Steve:   Great. It was a joy to be here with you, Mike.

Mike:    Alright. Well, hopefully, we’ll be talking soon with some people. Again, thanks for coming on.

Steve:   You’re very welcome.

Mike:    Alright, IT Nation, what did you think about that? Wasn’t Steve great? You can tell by the way he’s throwing out some of those terms there – he’s done that stuff, man. He’s really been in the trenches and knows what he’s talking about. Hope you enjoyed it as much as I did.

Also, just wanted to drop you a quick note, as we’re recording this, this last weekend, I attended an event. It was called the McKennaClaire Party for a Purpose. If you know anything about our company, you know that we support brain cancer or pediatric brain cancer research, especially through the McKennaClaire organization. If you want to know more about that, click on “Why Pediatric Brain Cancer?” on our website and it’ll tell you the whole story about our background.

It’s just a big reminder to me of what’s really important. This disease, this pediatric brain cancer research is called DIPG. It is a monster of a cancer that affects seven-year-old kids, typically, and it has a 0% survival rate. Basically, these parents have to watch their kids slowly deteriorate and pass away right before their eyes within six to nine months. It’s horrible. It is a horrible monster of a disease. We’re doing everything we can as a company to fight it.

The cool thing is all you guys have to do to help us out is to go on to our website, http://www.AeroComInc.com and write reviews on your providers. For every review that you write, we will $1 towards pediatric brain cancer research, which, basically, goes to the McKenna Claire Foundation and researching all this stuff. I know with more research money, they’re going to find a cure for this thing, because they haven’t had a lot of research funding up to this point, and now they’re finally making some breakthroughs and they’re getting places.

It’s just not right that any parent should have to go through this kind of thing. We all die. We’re all going to die. Death is normal, but this is just something that hits close to home with little kids. It’s just not necessary. So, just a quick note there – don’t want to bum you guys out too bad, but just a reminder – something I was thinking about. Everyone can contribute. It’s really easy – you just go on and write a review. You don’t have to donate money. We’ll donate the money. Just go ahead and write a review and we’ll do that, so just a quick reminder there

Also, just another quick reminder about our free gift, the list of CloudVM questions. These are the list of questions, that I took hours, and hours, and hours of research to compile, that you should ask yourself prior to shopping CloudVM providers. It will help you find a perfect CloudVM provider for your company a lot faster than it normally would.

I’ll give it to you for free. All you have to do is text the word “CLOUDVM” to the number 44-222. Again, text the word “CLOUDVM” to the number 44-222 and we will email you a free copy of that list of twenty-five or so questions that I have for you. Hopefully, that will help you the next time you’re shopping.

Alright. Until next time. Enjoy your day and I wish you all the green lights in the world today.