Checking Up On Python's Role in DevOps - Episode 244

Summary

Python has been part of the standard toolkit for systems administrators since it was created. In recent years there has been a shift in how servers are deployed and managed, and how code gets released due to the rise of cloud computing and the accompanying DevOps movement. The increased need for automation and speed of iteration has been a perfect use case for Python, cementing its position as a powerful tool for operations. In this episode Moshe Zadka reflects on his experiences using Python in a DevOps context and the book that he wrote on the subject. He also discusses the difference in what aspects of the language are useful as an introduction for system operators and where they can continue their learning.

Do you want to try out some of the tools and applications that you heard about on Podcast.__init__? Do you have a side project that you want to share with the world? With Linode’s managed Kubernetes platform it’s now even easier to get started with the latest in cloud technologies. With the combined power of the leading container orchestrator and the speed and reliability of Linode’s object storage, node balancers, block storage, and dedicated CPU or GPU instances, you’ve got everything you need to scale up. Go to pythonpodcast.com/linode today and get a $100 credit to launch a new cluster, run a server, upload some data, or… And don’t forget to thank them for being a long time supporter of Podcast.__init__!



Announcements

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • When you’re ready to launch your next app or want to try a project you hear about on the show, you’ll need somewhere to deploy it, so take a look at our friends over at Linode. With 200 Gbit/s private networking, scalable shared block storage, node balancers, and a 40 Gbit/s public network, all controlled by a brand new API you’ve got everything you need to scale up. And for your tasks that need fast computation, such as training machine learning models, they just launched dedicated CPU instances. Go to pythonpodcast.com/linode to get a $20 credit and launch a new server in under a minute. And don’t forget to thank them for their continued support of this show!
  • You listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis. For even more opportunities to meet, listen, and learn from your peers you don’t want to miss out on this year’s conference season. We have partnered with organizations such as O’Reilly Media, Corinium Global Intelligence, ODSC, and Data Council. Upcoming events include the Software Architecture Conference in NYC, Strata Data in San Jose, and PyCon US in Pittsburgh. Go to pythonpodcast.com/conferences to learn more about these and other events, and take advantage of our partner discounts to save money when you register today.
  • Your host as usual is Tobias Macey and today I’m interviewing Moshe Zadke about his recent book DevOps In Python

Interview

  • Introductions
  • How did you get introduced to Python?
  • How did you gain experience in managing systems with Python?
  • What is DevOps?
  • What makes Python a good fit for managing systems?
  • What is unique to the devops/sysadmin domain in terms of what software is used and what aspects of the language are useful?
  • What are the main ways that Python is used for managing servers and infrastructure?
  • What are some of the most notable changes in the ways that Python is used for server administration over the past several years?
  • How has Python3 impacted the lives of operators?
  • What was your motivation for writing a book about Python focused specifically on DevOps and server automation?
  • What are some of the tools that have been replaced in your own workflow over the years?

Keep In Touch

Picks

Closing Announcements

  • Thank you for listening! Don’t forget to check out our other show, the Data Engineering Podcast for the latest on modern data management.
  • Visit the site to subscribe to the show, sign up for the mailing list, and read the show notes.
  • If you’ve learned something or tried out a project from the show then tell us about it! Email hosts@podcastinit.com) with your story.
  • To help other people find the show please leave a review on iTunes and tell your friends and co-workers
  • Join the community in the new Zulip chat workspace at pythonpodcast.com/chat

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

Click here to read the raw transcript...
Tobias Macey
0:00:13
Hello, and welcome to podcast, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at linode. With 200 gigabit private networking, scalable shared block storage, node balancers, and the 40 gigabit public network all controlled by a brand new API, you've got everything you need to scale up. For your tasks that need fast computation, such as training machine learning models, they just launched dedicated CPU instances. They also have a new object storage service to make storing data for your apps even easier. Go to Python podcast.com slash linode. That's l i n o d today to get a $20 credit and launch a new server and under a minute and don't forget to thank them for continued support of this show. You listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis. For even more opportunities to meet, listen and learn from your peers you don't want to miss out on this year's conference season. We have partnered with organizations such as a Riley media chronium Global intelligence, od sc and data Council. Upcoming events include the software architecture conference, the strata data conference, and pi con us. Go to Python podcasts comm slash conferences to learn more about these and other events and take advantage of our partner discounts to save money when you register today. Your host as usual is Tobias Macey, and today I'm interviewing Moshe Zadka about his recent book DevOps in Python. So Moshe, can you start by introducing yourself?
Moshe Zadka
0:01:48
Sure. So my name is Moshe Zadka. I've been using Python since 98. I've been using the looks of finding five and right now I'm working as a senior Site Reliability Engineering Survey Monkey
Tobias Macey
0:01:59
and Remember, I first got introduced to Python,
Moshe Zadka
0:02:02
I wanted to use a language to do like, some numerical analysis. And I kind of looked around, see what's kind of annoying back in 1998, it's too late for that girl didn't look like the right fit. So I learned Python. And I remember that like the next day, it was already for the active. So I decided this is a good language.
Tobias Macey
0:02:22
And you've actually been on a previous episode talking about your experience working on the twisted package and all of the adventures that you've had there. So a lot of like in the show notes for that one. But in this episode, we're talking about your experience in your book about using Python for DevOps. And so I'm wondering if you can talk a bit about your experience in using Python for managing different systems and some of the jobs and products you been involved with that helps contribute to that overall experience?
Moshe Zadka
0:02:52
Sure, a little before like the concept of DevOps or so he was saying thank you. We didn't really have a word for it. So, but often, people with the title of infrastructure engineers will be using one of these things. And I basically ran the infrastructure team at a small startup called beehive. We're basically the whole company was using Python anyway. And I ran the infrastructure team. And back then that meant running the CI, CD, the, the monitoring system and all of that. And like in 2006, we our tools were much weaker than what we have today. So I basically had to write lots of stuff from scratch in Python.
Tobias Macey
0:03:34
And so as you mentioned, the term that a lot of people are using now for a sort of blanket way to encompass the entire realm of systems engineering and systems administration and Server Automation is DevOps. So I'm wondering if you can talk a bit about what that term means, particularly in the context of how you're referring to it for the purposes of your book. Sure.
Moshe Zadka
0:03:55
So I guess it's kind of interesting to look at it etymologically right. Originally, you had ops team, and people would write software, those developers and they would what we call, throw it over the wall to the ops team, hopefully with some documentation, and the ops team had to keep it running. And whenever it didn't work, the ops team had to figure out why they didn't work. Is it a configuration problem? Or is it a problem with the actual software. And if it is a problem is the actual software had to go back to the developers convince them that is the problem with the software, get them to fix get them to deploy it, get them to document how to use a fix, and this was very complicated, and especially when people started making software as a service, they decided that like this is this is slow down, slowing down the development work, and we should unify it. So DevOps is a philosophy First of all, from all that about unifying the developer and ops in one team, not necessarily in one role, but in one team in the DevOps engineer is the one in charge of reducing the operational complexity then This is a little bit subtle, because the ops engineer is the one responsible for shouldering the operational complexity in the dev ops team, you don't have an ops engineer, you have a DevOps engineer was responsible for reducing that they do that partially by shouldering it by partially by talking to the developers figuring out how to make the software easier to operate in, partially by automating stuff. And often the automation stuff comes with a little bit of an afterthought, and like you want to get it fast and running. And Python is a glue language, it has interfaces to everything, and it's very easy to teach and it's very fast to use became a natural fit for DevOps. And this is kind of like a some of the context for my book.
Tobias Macey
0:05:41
And so for people who have been using Python for developing web applications or writing simple scripts or for doing data science, there are a lot of different ways that they use the language. So I'm curious in terms of your experience, what you have seen as being the unique aspects of how DevOps engineers and Cisco Administrators use software and the aspects of the language that they find particularly useful.
Moshe Zadka
0:06:06
So there's a few things here. I guess one interesting historical note is, in some sense bifold invented to be what we now called DevOps language it was invented to manage the Amoeba operating system, the me will vary the system is of course, long gun, but it was invented with a thought that it would be it would be used to manage systems. So this is important historically, because we had the operating system model and like a lot of modules that are needed for managing the underlying unique stuff very early on integrated into the standard library. And this is part of like, why historically people were like, Oh, I guess I already have all these interface to roistat, which is very useful if you want to analyze the status of a file or something like that, which languages like Java try to abstract the operating system away and didn't have a lot of these tools. So of course, this is different nowadays. A lot of managers Systems now is done with like Web API in Python. having great Web API libraries, such as requests makes it also like a very good fit for like modern DevOps stuff.
Tobias Macey
0:07:10
And in terms of the particular aspects of using Python for managing systems, what are some of the general categories of the types of operations that Python would be used for in the context of systems administration and systems automation?
Moshe Zadka
0:07:24
First of all, the easy integration with the operating system is that often people will write scripts that run the tos Python, all service that collects information like metrics and logs, and sends them to some central place to be analyzed. So for example, script that will run every few seconds and in grab the numbers from uptime and send it to a collection thing so that it could be analyzed later. Those things of course, are really nice to use in Python, because it's you, you either get it from the for web interface, or you get it for you, I know your command or you get it by using an operating system interface and all these things are Good in Python. The other thing that often people use Python is automating common tasks. Like say, if you want to deploy something, often this is a multi step process. So for example, deploying, you're going to Canary first, then getting the data from the monitoring system to compare the canary to the default system to check that everything is okay. And then during the rest of the thing, and maybe there's a few steps, and maybe you want to integrate with the staging system. So for these steps are very complicated. And often there are the result of a lot of postmortems. So there was a post mortem that said, Oh, we should have first checked it on this specific thing, or we should make sure that the Canaries run on inside of all the data centers in before launching it. And often these things get more and more complicated. It's pretty nice to be able to fold all these things into some automated thing instead of making the script as a human has to follow more complicated and more.
Tobias Macey
0:08:57
And for people who are just getting started, particularly And Linux and Unix based environments the first experience that they'll usually have is using something like bash or seashell or z shell for doing some of these automation routines and usually as you continue along that path or it gets to be a point where trying to use that as the automation language just becomes very difficult and clunky and I'm wondering what your experience and perspective is on sort of when the right time is to stop trying to use some of the built in Terminal languages or terminal environments and move to Python instead.
Moshe Zadka
0:09:34
I guess it's a silly phrase it because it's almost my answer, which is as soon as you type vi It is time to write by phone and what we mean by that is I'll often white like pretty long things right on the command line writer for loop with a couple of pipes and that's all fine by the song is I'm doing it on the command line. I feel like that shows the show is a great thing as soon as like di vi or maybe even start with like, you know, copying and pasting the bad seem to have something to start with. But I feel like this is a good heuristic. As soon as I actually feel like this is stable enough to be in a file, I'm going to use Python in partly because as soon as you put it in a file, this is also the about the time that people will want to send in arguments. And using arguments in bash is very subtle, especially if you want to allow spaces or allow other special characters, and you have to start quoting hell. So as long as you do it in the command line, if you miss quotes, and you can immediately see the thing and kind of add to fix that as soon as you put it in a file with someone else, you want to use it with an argument that you didn't plan for. So I feel like that's, that's kind of about the white ust
Tobias Macey
0:10:38
and in terms of your experience over the past several years, as you said, you've been using for Python for a while and working in the systems management space. I'm curious what you've seen as some of the most notable changes in the ways that Python is being used and some of the types of tools that are available for Server Administration over that time.
Moshe Zadka
0:10:57
So little bit, like I said, we actually went Started out using paestum. For these kind of ministration, you didn't have cloud services. And basically, you ran your own servers and you knew what was running on them. And you use them to manage those servers. And that was very useful, of course, but now I feel like most people are running on something like AWS, or maybe Google Cloud, or even if they run their own clouds using Kubernetes. So the tool, often what we use with spicen is a tool that are one level up from that. So for example, AWS has bought of three library which is a really, really nice library for managing AWS and I've often used by some with, with bottle sweet to automate all kind of kind of AWS tasks like building a cluster up or making cluster bigger or smaller. And then often Nowadays, people use things like GitHub or get lab which also have great by some API so often will people will use Python API's to for example, speeding up a new repository, you'll make changes across several repositories. automatically. So the focuses shifted a lot to a lot of web API is whether the direct operating system API's.
Tobias Macey
0:12:07
Yeah, and as you said, the sort of breadth of responsibility has shifted a lot to from when it was just entirely server based, everything ran on a physical box, and you had to make sure that that box stayed up and running for a long time. And uptime was your primary concern. Now, we're, as you said, dealing with these different cloud services and third party SAS platforms. And so a lot of the context of where the Python is being executed is different, where it might just be something that you're running from your local machine and orchestrating all of these different operations versus something that you have to deploy to a server to run. And that also changes the constraints in terms of what you are trying to do in terms of how you're using Python where if you're running it on a server, you're likely going to be trying to minimize dependencies because you don't want to have to maintain it across a number of different instances. Whereas if you're running it locally, you're more likely to Reach out for different libraries because you're not as constrained in terms of the way that that will impact the system and the versions of Python that you're trying to run on. So I'm wondering what you have seen as far as the sort of shift in how willing systems operators will be to reach into libraries versus trying to write everything from scratch themselves.
Moshe Zadka
0:13:20
So I feel like nowadays, your ability to not use any library do anything really interesting with Python is very minimal. Like for several reasons, right? When Python was starting out, we didn't have this great ecosystem. So the best way to do a VPI was use you're ready, but you're ready to win nowadays. Everybody says just user requests. So I feel like the minimum point at which you want to start using a real virtual environment, we buy a subset of beat by a Docker or ditch virtual em for just manually setting it up with a lot lower Usually, I guess if I said that youth by so once you have a file, you start using dependencies. Once you have A modular library.
Tobias Macey
0:14:01
And another aspect of the Python runtime is that it comes as default on a lot of different Unix based systems. But it's not necessarily going to be the most recent version. So that might influence the way that you approach writing the Python that you're using for managing the systems. And then there's also the difference of if you're actually using Python as the runtime for the application that you're trying to deploy on to the systems, it might be trying to target a more recent version than what's available in the operating system repositories. And so I'm curious what you have seen as far as some of the challenges that people face in managing the versions of Python on their servers and the likelihood that the system runtime the way that then the scripts that we're using to automate that system are going to be just using the built in version.
Moshe Zadka
0:14:49
So it gets more and more the common wisdom is never use the operating system Python. It's It's It's for a lot of reasons right on the IBM System. For example, the operating system Python will be, something's really surprising. For example, you can have by some but not a lot of standard library modules that are in Debian package separately. So for the Debian use case, it makes sense in tweeting, I think the operating system Python specially on Linux system is something that is for the operating system by the user bin Python that is packaged on a Debian Ubuntu centers is a very good Python, for the libraries that you get via Debian or Ubuntu or centers. But for writing your own scripts, you usually want to bring your own Python, this will make sure that you can control the version of it, and especially loud it like people will often use sentence versions that are very slow moving, and based on these much more fast moving that is much nicer. And also that lets you control a lot of how it's deployed. And make sure that you have all the bits and pieces that you need in Python. So I guess this is kind of like the first chapter of my book is how to get the right buy from your system. And I think on Linux systems, usually what I would recommend to people is using pyun.
Tobias Macey
0:16:03
Yeah, that's what I end up using for managing my systems at my work is just using pi n for installing the specific version that you need for the application that's going to be running on it because it gives you much greater control rather than having to rely on what's actually in the operating system repositories and when it's actually going to be updated, because you either could be trying to run a version that's older than what you were initially targeting. Or it might just surprise you in terms of when it updates and the types of updates that it brings along. So surprises are never a good thing and the operating system space. And then another thing too, that you talk about in your book is packaging. And as you said, the packaging ecosystem A number of years ago was a large part non existent but at least very nascent. And in recent years, that has accelerated quite a bit and now it's getting to the point where we've got an embarrassment of riches where we sort of have the paradox of choice of which packaging system we want to use and sort of how we want to bundle up our scripts for deploying The system so I'm wondering what your personal preferences are. And maybe you talk a little bit about how the ecosystem has evolved in recent years.
Moshe Zadka
0:17:08
Sure. So I guess there's a couple of tools that I want to think it's built on top of PIP and five I wasn't like this is kind of three popular ones plus one operating system specific one. So let's see generic ones are Portree ppm. tools in the operating system. Pacific one is dhv or trillions, I guess. peepin I'm never sure because actually, like I've tried to run it a couple of times and never get the hang of it for to me I felt like it was much more built to help you develop Python when the to help you deploy Python. So I really like people's so mostly what people people's value doesn't really manage the installation, which I think is great because people people take care of that. What he does is he tells you lock down dependencies. And I guess as you said, surprises is never a good thing. When you deal with open system management or in general in programming, so you want to know in advance exactly which dependencies you're using PIP tools is the thing that will let you go from abstract dependencies like this version great or equal to this to a complete requirements to txt file that has exact dependencies plus hashes. So it's kind of nice to it also gives you a sense of security. And then when you actually come to the point, you want to use something like virtual em, and you can use virtual f directly. You can use dhv virtual interview and tap on top of a Debian system. You can use Docker if Docker is a good fit for your use case. And then I will still usually put a virtual and inside the Docker because makes some aspects of building the Docker image easier. I guess if you under reference for that he neck gave a really nice talk about how to build Docker Python based Docker images a few years ago in Python and he covered specifically Why should always use
Tobias Macey
0:18:56
virtually for that and in terms of the book itself, what was your an motivation for writing a book about Python that was focused specifically on DevOps and Server Automation, particularly at this point in time.
Moshe Zadka
0:19:08
So I guess it felt like there was like, immediately the market Why does like a lot of introduction to Python books, but then because the tweets themselves introduction, they won't cover even like the aspects like packaging and installation, the dean substance matter to someone who's managing systems more than aspects of the language often, you know, like, I'll write things that don't even have a classroom. So just a couple of functions to tie together a couple of standard library modules, but mostly what they need to think about this, how do I get by some into the system? How do I get dependencies into the system? So even an intro to Python book by chapter four, you will be talking about classes and inheritance which are less important to the system manager than actually getting Python into the packages to work reliably, which the intro book doesn't sink is a very important thing. So the focus is very different. And I guess the other thing is that like, you Seems like a lot of people were using Python for DevOps. And they felt like I have a lot of interesting things to say about that. And maybe that could help people get better at it.
Tobias Macey
0:20:08
Yeah, and for a little while, it was interesting because Ruby was starting to take over some of the use cases that Python had in terms of the systems management space, particularly because of the popularity of puppet and Chef, which have recently been declining. And saltstack and Ansible have been becoming more prevalent and taking over a lot of that same popularity. So I'm wondering what you have seen as far as how those tool sets have influenced the direction of Python in the systems automation space, and the ways that people are engaging with Python in that context.
Moshe Zadka
0:20:41
So I guess, among a funny anecdote, and that is that I recently met a very nice developer from the Ansible team. And we talked a little bit about how people use astable. And when people start using Ansible, it's mostly by writing a lot of yamo files. And as soon as they need something interesting, they'll start going into like Ansible channel Ansible StackOverflow and asking how do I do it to the Jinja thing that Ansible? Does it? NVR answer is always the same. As soon as you have to ask these kind of questions, stop doing anything like the ginger thing that generates the mo thing that danceable confused and start writing Ansible modules. So the nice thing about Ansible and saltstack is they don't hide the fact that they're invite from the expose it as a feature, meaning you can write extension modules for saltstack and Ansible. That will do other things. And if you have a custom environment that sinks in its own way, you can write higher level obstructions and implement them in Python. And part of it is that this feels to a lot of people like a big jump, right? I was just kind of writing a little follow up in Jinja. And now you're telling me to start writing Python code and using your real operating system. So this is kind of a good point where like, you know, maybe a nice introduction to Python for for system administration is useful.
Tobias Macey
0:21:54
Yeah. And one of the nice things as you said about the Python and Ansible ecosystems is That if you do if you are familiar with Python, you can take them quite a bit farther than if you chose to only use the facade that they provide. And also saltstack, I know has the option of actually using Python as the syntax that you use for actually building your configuration management and issuing the emelin Jinja combination for people who don't want to go down that road. So if you like to, you actually can go entirely native Python using the DSL that they expose.
Moshe Zadka
0:22:27
Yeah, and that that's a really cool feature that I feel like is really underrated to use by some because YAML is just a way to specify dictionary and like, it's really nice to build dictionaries in Python. It has strong literals plus strong programming. So yes, the fact that saltstack exposed it is pretty cool. I like that.
Tobias Macey
0:22:45
And another interesting development in recent years in this context of systems administration is the introduction of Python three, which has been around for quite a while but it has become increasingly the default for different tools. And I know that the sort of primary pain points around the transition from two to three is in the interaction between Unicode and strings and bytes objects, and that those are particularly prevalent in the systems domain because of all the networking that happens and dealing with file objects and things like that. And so I'm curious how you have seen the Python three transition impacting the lives of systems operators.
Moshe Zadka
0:23:23
So it's funny that you use strings and bytes and file object is like the biggest thing to change because superficially Yes, this is the biggest difference between Python two and Python three, but I feel like for a lot of people who have waited a long time, I guess longer than it would be ideal. What happened is that a lot of libraries started dropping support for Python two, then when you try to upgrade to Python three sure you can deal with like the few strings and bytes you had in your code to upgrade them. But you also have to jump versions of library and again, in my experience, this is this has always been the the bigger header, the jumping versions of libraries are the biggest library like we So twisted more pretty careful. But other libraries started doing it quite a bit earlier, especially like they would not support bicycle swim the old version. So if you need even support for Python three, you have to jump a new version. And this is this is this is the biggest pain in my experience in managing debt, of course, is very subtle, you often want to jump the libraries before you jump the version and just coordinating that it's been a huge hassle. And I guess, you know, people who manage systems tend to be the most conservative people. So they waited the longest and kind of have seen the most pain from that. So mostly, it's I kind of think of it as a bad episode that I'm very happy has mostly reached its inclusion. And we've we've kind of suffered, but level suffering is done. We don't ever have to think about it again.
Tobias Macey
0:24:46
And one of the other aspects of the transition to Python three is that there are new built in modules in the standard library, including things for managing IP addresses. And so I'm curious if there are any of those new Standard Library modules that you found particularly useful.
Moshe Zadka
0:25:03
Um, I guess not because even towards kind of like you know, Python 2.6 already there were such a such good module in the in the ecosystem that sure it's it's kind of nice maybe that the standardized in Python, but that didn't make like a big difference in my life like all these, the IO module and Springdale. It's kind of a bit nicer, but that's definitely not where the biggest differences
Tobias Macey
0:25:27
and going back to the book, I'm wondering what your process was in terms of determining what were the particular topics that you wanted to cover and how to lay them out and what level of depth to go into and sort of what you had in mind as the level of experience for the target audience. Sure.
Moshe Zadka
0:25:45
So I guess with the book, I kind of I had kind of like, I guess four things that they kind of wanted to cover. So the first big chunk was, you know, like the book is called DevOps in Python. But the first big chunk is actually the opposite. Python for DevOps engineers. And this means covering, like, if you want to learn the language, you editorial, you can literally learn the entire language was torn in one day. But if you want to get the aspects of Python that are useful for DevOps engineer, which means how do you deploy Python? How do you use packages? How do you ship packages? How do you configure it? All that others not good resources? So the first member when I when I was talking with my publisher about it, they were like, isn't there usually someone in the company who does that? And I said, Yes, that's DevOps engineer. And this is the person who's trying to issue the book. So the first chunk is like, we need Python for DevOps engineer. The next two chunks of what I feel like is like the most common tasks in when managing Unix style systems, which are the most popular systems to manage and that's the first direct operating system interfaces. So how do you manage processes and files and stuff like that? And then Unix historically has always been a very text oriented operating system, the configuration files, the old booted out of a lot of things happen our text format, and sorry, what I felt like we should cover some of the common kind of text manipulation things not at the level that says Like, like big books about text manipulation, Python, but at least the common bread and butter things that you have to do is a Unix system administrator like, you know, getting CSV files, parsing the spaces out stuff like that. I felt like we should cover that. And then the fourth big chunk was kind of managing systems as a distance, I guess you can call it so I covered stuff like Ansible stuff like saltstack, how to manage AWS, how to manage Docker, which are kind of like the most what what we would call kind of a modern DevOps job.
Tobias Macey
0:27:43
And were there any aspects of writing the book where you ended up being surprised as you started to dig into the subject matter or any particular challenges in terms of how to represent the material in a way that was accessible to the target audience?
Moshe Zadka
0:27:57
So I guess one, one of the interesting things was My publisher and I kind of really talked about like covering Ansible and saltstack. Because the publisher had kind of not a great experience with covering those because he said that those systems kind of move really fast. Right? So if you try to document and say, well, you find it, you could do commendation validate with the next version, because a lot of the modules are different. And so instead of focusing on the modules, which I feel like the online documentation is good, and also the move faster book wouldn't be useful. I focus on the underlying concepts which can't change this fast. So you covered how to do extension modules, fanciable and how to extension modules for saltstack, which not a lot of resources do cover, but they feel like that was something important and also something that they have to keep stable, because they want to make sure that modules are useful between versions.
Tobias Macey
0:28:48
And so for people who are coming to the book, who are trying to figure out the best ways to use Python for managing different systems. What's the sort of next step after they've read the book? gone through the material, are there any useful resources or references that you can suggest or sort of what's the level of familiarity and capability that you expect them to be at by the time they finish.
Moshe Zadka
0:29:12
So I guess by the time you finish the book, you should at least be able to automate a simple AWS tasks automate simple GitHub tasks. I guess AWS is cheap enough that if you just you know, kind of get like a $20 gift card and put start an AWS account, you can play around with that and see how they work, how you set up a service, how you would even like build a Docker system using the tricks I teach in the book and kind of, like, make the whole thing from like, from soft to deployment with, with one check in, which is always a great exercise for DevOps because I feel like this is often where people are trying to go right like the whole continuous deployment. And I feel like it's a good exercise for people who want to do DevOps because This will teach you where the hard things are.
Tobias Macey
0:30:03
And are there any other aspects of DevOps or the ways that Python is being used in that context or your experience writing the book, or anything along those lines that we didn't discuss yet that you'd like to cover before we close out the show?
Moshe Zadka
0:30:15
Oh, I guess one more thing, which is we talked a lot about the technical aspect of DevOps. But DevOps is a very human oriented discipline, right? Like a lot of the skill of DevOps is to know how to talk with developers and to talk with people who are more operationally focused and figure out what they need, what pains them and how you can help them and often if you can help them try to communicate what is the problem in in doing what they want, and you're still feeling that they are in pain, but you can solve this problem for them. So in general, I feel like empathy is a very important skill in DevOps. This is normally they're actually shifted from a book which does not teach that skill. But if you do want to be successful in the discipline, this is known as important than understanding Python understanding Unix
Tobias Macey
0:31:00
Alright, well, for anybody who wants to follow along with you and get in touch, I'll have you add your preferred contact information to the show notes. And with that, I'll move this into the pics and this week, I'm going to choose the salt stack package. Because I've been using it for a number of years. I may have picked it before, but it's definitely a tool worth checking out, particularly if you're working in the DevOps space because it has everything you need as far as being able to manage systems including handling, deploying new instances, configuration management, software delivery. So it's a pretty powerful framework, very flexible. So there's definitely plenty of room for hanging yourself, but there is plenty of ways that you can use it productively so definitely worth taking a look. And so with that, I'll pass it to you, Marcia, you have any pics this week.
Moshe Zadka
0:31:44
So yes, might be the ultimate package. Ultimate is a framework for doing finite state machines in Python. I've written a little bit, a little bit of a blog post about it once. But the idea that often you have things that have state you can't do that while you do this. And You can do that while you're dead. And often you find yourself in a mess of volumes in the document which state you're in. And having a lot of if statements. And ultimate is a great framework for making sure that you can write this with a lot less bugs while still keeping the outside interface of a plain old Python objects, which is something that some other finally state machine packages don't give you, which is why like, what too much specifically?
Tobias Macey
0:32:25
Yeah, and I'll point people in the show notes to a link to the episode that I did with glyph talking about that. So definitely an interesting package and worth checking out. So second, your choice there. Thanks. And so with that, I'd like to thank you for taking the time today to join me and discuss your experience of using Python for managing systems and writing a book about that to help other people learn how to do it. So I appreciate all of your efforts on that front and I hope you enjoy the rest of your day. Thank you. Thank you for listening. Don't forget to check out our other show the data engineering podcast at data engineering podcast. Calm for the latest on modern data management and visit the site of Python podcasts. com to subscribe to the show, sign up for the mailing list and read the show notes. And if you've learned something or tried out a project from the show, then tell us about it. Email host at podcast in a.com with your story to help other people find the show, please leave a review on iTunes and tell your friends and coworkers
Liked it? Take a second to support Podcast.__init__ on Patreon!