Tiny DevOps episode #25 Jillian Rowe — Where DevOps Meets Data Science
December 28, 2021
Jillian Rowe, who you may know as a regular co-panelist on the Adventures in DevOps podcast, joins me to talk about her work at the crossroads of bioinformatics, Data Science and DevOps. We have a casual conversation about her business as a freelancer and early-stage startup founder, and some of the unique challenges that come when working with Big Data and bioinformatics, and how she is addressing scaling challenges as a solo operator.
Presenter: Ladies and gentlemen, the Tiny DevOps guy.
Host: Hello, everybody, welcome to another episode of Tiny DevOps where we talk about Dev and Ops, and all other sorts of related things for small companies and small teams. Today, I have with me one of the smallest DevOps teams you'll ever meet, Jillian Rowe. Jillian, thank you for coming on. You are technically the smallest team possible or maybe even smaller, can you be a team if you're only one?
Jillian Rowe: I'm not sure I like to think that I am. I'm going to go with that, I feel like it has that superhero feel that I like when I'm sitting in crunching in my computer alone. I'm going to go with that.
Host: Okay. We have today a team of one, which sounds like a US Army slogan or something, I think. We're going to do a DevOps version of it today. Jillian, why don't you introduce yourself a little bit, tell us about what you do and who you are? And what your one-person team does?
Jillian: Sure. Thank you. First of all, thank you for having me on the show. I'm excited to be here and like you said, I'm Jillian. I've been in the DevOps, computing tech space, mostly in the data science realm for over 15 years now. I started off in computational neuroscience, and then I went up switching to bioinformatics. I actually started off my tech career more as a data analyst, and over time, I found that the labs were doing things and I was like, "Why are we doing these things manually? Surely a computer must be able to do this for us".
I think part of that was lent by my background in computational neuroscience, where we built robots and cool things like that. I already had a feel for automating a bit. I spent a couple of years developing my software engineering skills, and also my DevOps skills by just running around and asking the labs, like, "What are you doing? How can I help you? How can we automate this?" I just kept on with that and I gradually got introduced to DevOps, mostly, because when you work in data science, you are generally working with some big data, or at least I am.
In bioinformatics the data is quite big, it is generally much larger than something that a scientist can process on their own laptop, which often meant that they would have this development cycle of they would have their data, they would start analyzing their data, maybe they would start on their laptop or on a lab server, and they would just analyze a small subset of their data, or usually create their analysis and do that on a small subset of their data. Then over time, they're like, "Okay, now we have to analyze all the data, what do we do?"
The answer to that is, I would say, now you would say it's DevOps, it was HPC then, high-performance computing, and it's still high-performance computing but it's a very different way, I think, than most people think of doing data analysis, because you have to have a knowledge of the underlying tech infrastructure, in order to be able to do HPC. You have to know how many nodes do I need, if you need to do something like MPI, you need to have at least a general idea of how many CPUs and memory you need.
You need to know how the cluster itself is configured because every HPC cluster is a beautiful and unique snowflake, and you have to go get in bed with the HPC admins to understand how to actually get your jobs pushed through the queue. It's also a multi-user environment, so you have to play nice with the other children on the playground.
Sometimes you have to log in and be like, "Oh, this queue is full so maybe I'll just go use this other queue and maybe my job will take a bit longer, but it would never finish if I put it on this big queue." I spent a long time doing that I spent about 10 years just being very much in academic research, bioinformatics, genomics, that thing.
In the last few years, I went out on my own as an independent consultant. I guess I started that around two and a half, three years ago, and so that's what brings me to my I am a DevOps team of one. Although, I suppose most of the time I'm working on quite collaborative projects, where I'm working with a team of interdisciplinary folks. Sometimes I'm working with people more on the science realm. Sometimes I'm working with doctors or clinicians who don't have anything to do with computing, and sometimes I'm working more with software DevOps teams.
Host: Nice introduction.
Jillian: Thank you.
Host: You threw out some words that I am not familiar with, and so I'm going to assume that my audience is not familiar with them either. This is the part where I get to play stupid host and just pretend like I don't know anything. I feel like I just watched an episode-
Jillian: [crosstalk] anyways.
Host: It is. I feel like I just watched an episode of Star Trek where they just threw all this gobbledygook technobabble, it sounds cool, but what does it mean? Could you explain what is bioinformatics and what is genomics? For a five-year-old.
Jillian: For a five-year-old, okay. Biology, I would suppose you could say is the study of life and bioinformatics is the study of life where we take life and try to compute it down into data, and then we study that data with a computer. There are a lot of different ways to study biology, you could be-- like what I wanted to be as a little girl where you're Jane Goodall studying the chimps and things, and that's really cool.
You can be out in the field finding new species of lizards or what have you, or you could go and you could get data and you can use a computer to compile that down to a bunch of numbers or letters, and then analyze it. Genomics is specifically the study of DNA.
Host: Genomics is the study of DNA, and then bioinformatics, is that information about things at a cellular level, or is it like higher level? How many apes or at least this tall and how many are shorter? Or is it all of the above?
Jillian: It can be all of the above. Bioinformatics is pretty darn broad. I would say within bioinformatics, you have so many multi-disciplines. I would say genomics is a topic within bioinformatics. You can study cells, you can study DNA, you can study molecular structures, like proteins and mRNA. For those of you who follow along with the COVID news, one of the ways to combat COVID is the vaccine, and the vaccine is made from mRNA, which is it's-- for the purposes of this conversation is very much like DNA.
Host: Bioinformatics, we're going to simplify its data about life, is that a fair simplification?
Jillian: Yes, that's great. Let's do that.
Host: Then you also talk about big data and of course, I imagine everybody's heard the term, but it's like the term DevOps, it's a little bit fuzzy, I think. What does big data mean, maybe to you or to your business?
Jillian: I would say big data is on the order of terabytes of data that need to-- they need to be processed and need to be analyzed. There are a lot of the things that go into, when you're analyzing large amounts of data, from the DevOps perspective, you have to take care of the data access, especially if you're dealing with medical data, we have this compliance called HIPAA compliance that we must all know and love. If you work in a medical environment, even if you have nothing to do with data, you still have to get certified in HIPAA compliance.
One, you have to take care of the data access, two, you have to take care of where's the data going to be stored, what is the redundancy that we need. If it's raw data, it tends to be quite a lot, because you cannot generally create this data again, say, if it's from a person, and maybe you collected blood or something like that and then you sequence their DNA, you can't always get that back. You need to back that up, you need to perhaps have some redundancy, maybe have several backups, throw it on an archive, throw in other places.
You may need to version your data as well, and that tends to be a very tricky problem because as of now, there are no-- especially good cost-effective ways of versioning very large datasets, say, you're on the order of terabytes of data. That's an interesting problem that I think we're all just figuring out as we go along. You also need to consider that you're running your data through an analysis, and so then you have to consider the fact that analysis is not a static thing, it's not like you run an analysis and you're like, "Okay, we're good, let's go".
Oftentimes, it's like software, there's updates to the toolsets, to the analysis change, and so you need to version your data in relation to the version of the analysis that you're running, and sometimes you get these almost crazy build matrices of different analyses that you could be running. There's a lot that goes into, specifically when you're considering, I suppose, data and data analysis, as opposed to just like your more typical DevOps information where you really have to consider we have data, what is the purpose of this data? What is this data being used for?
Host: What kind of data are you dealing with on daily basis?
Jillian: I dabble in quite a bit, for the most part, I deal with what is called clinical genomics data, and mostly human clinical genomics data. Typically, this means something like I'll work on a research study where, let's say there's a principal investigator who's a head researcher who can command some budget and whatnot, who says, "I want to study diabetes." My name is on some paper for some diabetes studies.
They say, "Okay, I want to study diabetes." They go out and they collect all kinds of data from both diabetic patients, and also not diabetic patients so that you have the control because in science, you always have to have this idea of the null factors so that we have the baseline comparison, which if you're studying diseases as people with the disease, people who don't have the disease and compare them You can have quite a lot of different types of data when it comes to clinical genomics. You can have the genomics, which is DNA, and that's a fairly simple chemical structure that then for the intent and purposes of a computer basically, gets compiled down to a string comparison problem. When you have your DNA and you look at it on a computer, it looks like a big string. It's like ATCG, like that.
There's just regular genomics data. You can also populate all other kinds of data. You can get what's called metabolomics, which is like if you eat something, you have enzymes that break down food, and specifically if you have diabetes, diabetes affects your blood sugar. The specific, biological processes that are supposed to happen and somebody without diabetes-- don't happen in somebody with diabetes.
It's always very important to understand what are the differences, where is this actually breaking down. We know at this point that it breaks down in insulin production, but can we get better at that? There's quite a lot being done lately and it's a very new field, so I don't have a whole lot to say about it besides it's cool. This idea of synthetic biology, which is like, we know that, for example, in diabetics, the pipeline for insulin production is messed up.
Can we just make some biology, like little TT tiny biology bots, and just stick them in people and have that fix things? That's a new area of research that I just find to be really interesting. If you ever want to go look it up. There is-- what is it? There's a publication I really like. I think it's called ScienceDaily and it does quite a good job of explaining, just the science news in a very accessible fashion, even if you're not necessarily a biologist.
Host: Explain a little bit more in detail what your business does or what you as a business does with this data, and how you help your clients do this stuff?
Jillian: Sure. What I do is I go and I primarily work with biotech startups and quite often I'm helping them from the ground up where they need to get their cloud infrastructure off the ground. If you have data scientists, typically your bioinformatics, let's say, which is a particular data scientist within the realm of bioinformatics. You're typically paying them a lot of money to analyze data and give insights into this data and be scientists essentially. Scientists on a computer, but scientists.
You don't really want them to go and be screwing around in the AWS console. I would argue that you don't really want anybody to go and be screwing around in the AWS console, but especially you don't want the people that you're paying less of money to cure diabetes or cancer, or what not to do that. One issue with getting started with AWS is that if you don't have these DevOps skills, it can be quite difficult to get started and it can be quite difficult to put into place a really standard infrastructure that's highly scalable.
Quite often, what I do is I sit down and I talk with them and we decide what kind of analysis that they're doing, first of all, and then the types of problems that they're trying to solve and maybe the toolsets or analysis that they're trying to build out. We work from there to decide on their compute infrastructure. I take a very science-first approach, which I think is refreshing for a lot of my clients because sometimes they go talk to IT people.
ICU or DevOps people will start from the bottom down like, "What kind of network do you need?" They're scientists, they don't know and they don't care. My goal is that I want to be able to build out all this science infrastructure and that the fact that there is a cluster in-network is basically an afterthought to the scientist and they can focus on, "I'm doing this analysis. This is what I want to do. This is the problem that I want to solve. Yes, there's some computers in there running there in the background, but they're just there." It's really just an afterthought.
That is really my goal and my goal for my clients and for my business. To that end actually, I'm working on a project now, which is called BioAnalyze. What I am doing is I'm starting it from the ground up, which is a bit counterintuitive based on what I just said. Right now, I am open-sourcing a whole bunch of Terraform modules. What have I got now? I've got AWS batch, which is the AWS version of high-performance computing.
Then I've got a traditional HPC, which is-- if you come from academia, that's probably what you're more used to. Also, Kubernetes and Kubernetes specifically managed with Rancher. What I'm doing is I'm open-sourcing all of these and the software itself is going to be completely free, completely open-source. There's not going to be anything behind a paywall.
I'm hoping to go a crowdsourcing route or working at least with enough scientists that they're like, "I don't want to press that button. I want to pay you to press that button", that it will still be profitable for me. I will stay in business and feed my children and all these things that I need to be doing on a day-to-day basis. I am essentially a team of one, although I have recently started to with a couple of contractors just to help me out with some QA and things like that. I have to be very careful and strategic about the work that I take on. Also, what I'm going to release out into the wild, because I want for it to have a reasonable degree of so support behind it.
That's really where I'm at right now. That's really the headspace where I'm at, is like, "I want to take these modules", the infrastructure modules that I just talked about, "I want to release them." Then essentially what I want to do is build out a layer or two layers on top of that, where the bottom layer is infrastructure. The next layer up from that is applications. For a DevOps person that would be like helm charts and maybe like deploying things through SSH and stuff like that.
Then the final layer on top of that is what I'm- I think I've decided on cloud labs, I've changed it a few times. It'll be something, but the idea is this is really where the science-based approach comes in. I want to talk to scientists and be like, "You. You're doing clinical genomics, here's a cloud lab that allows you to do clinical genomics." Essentially, they'll be faced with the web interface and they can go and be like, "I want this software for genomics and this software for genomics and this other one for genomics".
Again, they will have to make at least a few decisions on compute infrastructure, namely things like the minimum and the maximum in terms of their auto-scaling so that they are not very surprised by a bill is mostly why that's in there. At the end of the day, what I really want is to have a really intuitive framework for bio implementations to be able to deploy high-performance compute infrastructure on the cloud to do their analysis and do cool science.
Host: Great. One other term you mentioned that would useful, I think to clarify, is high-performance computing because I'm not a data scientist and I-- to me, that just sounds like fast computers. Can you explain what that actually means?
Jillian: High-performance computing is when you throw a bunch of computers together and then you throw a layer on top of that, which is an HPC scheduler. Essentially it happens is that you have your users who are probably scientists, they go, they log into a login node or a head node, and they say, "I want to run this job." They request however many nodes they need or how much memory, how much CPU.
You can also do create groups of these things with what are called queues, but pretty much it's a cluster. It's all a bunch of bash, SSH, and network file storage as far as I'm concerned. If you've ever worked with a Kubernetes cluster or really any cluster Fargate, Kubernetes, Swarm, any of these, they all operate in quite a similar capacity. You have computers, you're stringing them together and you have some layer on top that makes them all communicate.
Host: You have this three-layered, three-tiered approach that you're working on. What are the struggles you're facing right now? You mentioned that you've hired some, I'm assuming, freelancers to help with QA and stuff like that. You're not truly a hundred percent solo operator but you're the-
Jillian: Not anymore. No.
Host: No anymore.
Host: What are you working on lately? What's the challenge that you're addressing, say, in the last week or two on this front?
Jillian: My main focus for the last couple of months has been to really clamp down on the specific infrastructure and modules that I'm going to be supporting. I used to have a couple more thrown into that list and I just realized being a team of one, I can't support all these things. There's only so much me. I also tend to be very highly optimistic on how much time it's going to take me to do something, which I think is good in one way, because I'm like, "At least I'll get started".
Then once I get started, I'm motivated, but then I get started and I'm like, "Oh, this is going to take me like 10 times as long as I thought that it would." Which I think is maybe a little bit typical for people in tech, but I feel like be I'm especially bad about that. I've really just been thinking a lot about what can I do to shave off work from me specifically and to that effect, what I'm doing is just getting rid of some of the modules that I previously had higher. Some people at least to do QA. For example, I have an AWS bat. Terraform recipe out, it's on the bio analyze GitHub repository. Getting well for that one, I wrote all the tests and things as an example, just to show like, "Okay, this is how I want it structured. Now I'm working with an agency from Upwork to go and actually emulate some of the other modules that I have and use the same structure for testing.
To that end, one thing that I'm really interested in is this evolution where all software or all tech is an API that you talk to and then you can go and you can compile these APIs, like different programming languages. Probably the best example for your audience is-- The Kubernetes API actually is an open API spec. You can go and you can take that open API spec and you can use the open API generator and then you can-- I don't know if it's compile or trans compile or whatever it is. Essentially it builds out a library in your language of choice.
For me, that's Python because Data Science Python, that tends to be where I'm at. I'm really liking this way of doing things and I'm really trying to really hone in on tools that take that approach because I've just found that really takes away from-- or that really lessons my own development time. Especially for me, I used to do a lot more software engineering, but I think since I've gotten more into DevOps, I just really don't have the time for it.
I don't have the time to keep up on whatever is the newest hotness and whether or not in Python there was this whole thing, like replacing the print function or replacing print with a function with parentheses. If you're not in that headspace every day, you're just like, "What is this?" You don't even care. I'm really looking for ways that I can consolidate and lessen the amount of work on myself for different tech stacks.
It really lent itself very well to using this layered approach and then just to backtrack on that. I think the layered approach is so important because I think sometimes as tech people, we get a bit lost in the tech and optimizing for the tech as opposed to optimizing for the people or for the purpose. That's something that's made my career, is the fact that I'm able to go focus on this and I'm able not to just talk to the IT people and the DevOps people, but also the people who are using it, the scientists. I've heard from a lot of scientists that they really appreciate that because they feel like when they're talking to tech people that sometimes there's just this really big disconnect between what they want to optimize for and between what the tech people want to optimize for.
Jonathan: That's so important. I just want to dwell on that for just a second. The fact that you can bridge that gap between tech and your version of business. Business is a broad topic too, but you're dealing specifically with researchers and doctors. That's your area of business. That's a super power. If you can write code or do DevOps and also talk to "normal people" you will go places. If you're listening and you're struggling what frameworks do you learn next, probably none. Learn how to talk to business people.
Jillian: Yes. Learn how to write. Learn how to communicate. I do some mentoring for students at STEM-Away and I am constantly on their cases. Take a step back, sit down, learn one of these documentation frameworks or static site generators or whatever, mostly because I just feel like they're the easiest thing to get started with not because I think learning that tech stack is important, but because of the communication and skills that it teaches you.
Sit down, do something, write about it, present and then go present it to somebody who is actually knowledgeable about that topic and actually cares about this thing or this type of analysis that you're doing. It's mostly data science. For them it's analysis. Again, it's not important because Markdown versus RST versus [inaudible 00:25:02] Markdown versus whatever else is going on there, it's important because of the communication skills and because of being able to sit there and talk to the quote-unquote regular people.
Jonathan: You have this three-tiered open-source model you're working on, but you also have clients you're working with on a daily basis. Is that correct?
Jonathan: What's the overlap? Or is there any right now?
Jillian: Over time there's been more and more overlap. I think a lot of people-- I started my business and it took me a while to find my stride and find my niche. Initially, I was doing a lot of software and doing a lot of LIMS and I still do, LIMS is Laboratory Information Management System. Essentially it's like, "Let's track what's going on in the lab. What's going on with analyses." It's supposed to be a dashboard interface into any given time, like what's happening here.
I was developing a lot of those. I still enjoy that, but I found as a business it's quite difficult to do because it's very difficult to scale custom software and there's just not a lot of overlap. I felt like I wasn't really creating assets for myself and for my business. I was interested in that idea, but at the same time, I was also doing a lot of this building up HPC infrastructure. I found that was much more reusable because I would start building out and initially it was just using things like cookie-cutter, which is this really great Python package, but essentially you just create templates and you can create templates of templates and then you hand cookie cutter adjacent file, and then it fills in your template based on the JSON file. You can just do cool things with that.
Initially it was just very quick and dirty templates and over time they've become more polished and now they're being open-sourced as a part of Bioanalyze. These days I still do a little bit of custom software. There are still some things that I still really enjoy. I still really enjoy, for example, talking to scientists and a lot of times they will really specifically need some interfaces to their data as well, specifically to interfaces to their data on an HPC. I still do work quite a bit on those kinds of problems, but I would say, on a day-to-day basis, maybe around 70 to 80% is really just a high-performance compute infrastructure on AWS for bioinformatics applications.
There is quite a lot of overlap. I'm also very lucky that in science and research and most of my clients are very happy to have their work contributed back to open source. That's been a business. I don't know if business model is the right word, but what about with that business model that I've adopted where essentially I have it like right in my contracts, I'm like, "There's no intellectual property, everything is open sourced, you get all the code with an Apache II license." Additionally, a cluster is a cluster. There's no intellectual property and Kubernetes are [unintelligible 00:28:16] cluster as far as I am concerned.
A lot of the bits and pieces are based on this open-source work that I have over here. I found in terms of a freelancer that's been really great because I know-- some of my clients have specifically come to me after getting burned by other software companies on this intellectual property deal. It's good to be in research, I guess, because overall people are very open and most of them are fine with- are very, "Cool open source is great", and if they're not, it just got to the point where we just have to go our separate ways and they can try to find a lawyer who will say that a cluster is intellectual property or something. I don't even know. I just try to stay far away from that.
Jonathan: Is there anything else you'd like to talk about here before we start the signoff process?
Jillian: I did just want to reiterate this point, if you're a team of one or a small team, just try to really sit down and think about where you're going to be spending your time and where you should be spending your time. I would say now software is just getting cheaper and cheaper, which goes back to my point of nobody's trying to make money from software anymore because they're no intellectual property in it, seems like the intellectual property these days, no matter what your industry is in, is almost entirely in the data.
For example, for myself, I'm starting to look at solutions, even paid solutions for being able to build out web forms because again, for example with me, I do have to about these web forms and web interfaces, but I don't really have enough time to keep up on what I consider to be modern web development. I haven't come to any exact solutions yet, but I am looking at solutions like type form, for example, has a whole developer API behind it that you can actually use to create these very integrated form, you can have skip logic like if, "Yes to this. Ho here. Go do this. Go do that", which personally not being a web developer, I find it be quite difficult and their most expensive plan is 100 bucks a month or something like that.
How can I think about those kinds of problems and maybe for other people it's different problems, for me it's web forms. Web forms, they've been getting me for years. How can you think about these things and how can you make these decisions to outsource a lot of that work? I use Strapi as an example before and I like Strapi not because I care so much about the technology but because it's just I find it this very intuitive way to build data model. Somebody else is managing it and then you do get an open API spec. Then I can take that open API spec, create a Python library from that and it's got types and tests. It's got a tone of QC already built into it so I'm getting out of the box because I'm using Strapi.
Strapi is a-- I think it has an open-source version and then you can also pay for some additional features and things like that. Again, just think about these things, make these decisions. I think sometimes it's really easy to have this knee jerk. I'm not paying for that. When I looked at type form I was like, "100 bucks a month", and then I was, "Well, geez, how much is a web developer going to cost me? How much is my time worth?"
For me personally, how much is my time worth for me to go out and get another client specifically. Because I'm talking to scientists, they don't care about the tech behind it and they would prefer-- if they could have no tech behind their solution they would probably choose that. Making sure that I'm in line with all those philosophies and yes, I'm just still in that head space. I don't have any definite answers except just sit down, think about things, see what else is out there, see what else other people are doing.
Jonathan: Do you have anything like a rule of thumb to help you decide when you should do something, versus when you should hire someone to do something, versus when you should outsource it?
Jillian: For me if it's my main focus I keep it in high. For example with Bioanalyze I would say the main focus are these tech stacks where it's the AWS flavor of HPC, Kubernetes being able to deploy, and I use Rancher to manage the Kubernetes. Which is another thing so I'm using the open-source version of Rancher, but I'm using Rancher to manage all that and then that gets me my Grafana and logging and all these things. I'm not doing any of that from scratch.
The people at Rancher are much smarter and have already done a much better job of it. That kind of thing I'm keeping in house, but anything that I consider that's not really I suppose my area of expertise or something I just don't feel I have time to keep up on, I'm very quickly learning the value of outsourcing it. For me, I keep hammering on this web development, but really web development is not my wheelhouse. I'm going to outsource that as much as I possibly can.
Jonathan: I do the same for my own website. I use an aesthetic site generator called Hugo. I do most of my own web development but when it comes to design, layout and CSS, I'm lost. I have a freelancer who I hire to do that for me. It came down to the question of could I teach myself CSS? Yes. I definitely could learn enough to do this. Is it worth my time? No, it's really not. I'd rather pay somebody. Even my own whatever my own rate is if I could pay them that or double that it would still come out ahead versus the investment it would take to get to a competent level.
Jillian: that's good. I don't even do that. My business websites are all in Kajabi and even I'm starting up a discourse form for Bioanalyze and I was this is silly. I know could manage my own discourse deployment and I was like oh, I just don't want to I'll pay the discourse people 10 bucks a month to manage it for me and they do quite a good job. I'm very happy with you discourse people. Again, these things where, again, you think about how much is my time worth? How much can I outsource this for? And it just becomes a math problem.
Is this worth it? Yes or no. Also maybe if you could- it's not always possible for people who are working jobs because other people are setting the priorities, but if you can just get rid of stuff, even just think about, "Do I even need this?" My favorite thing to do when I'm writing software is delete code, it's the most satisfying thing to do. What code can you delete? What services can you destroy.
Jonathan: Thanks for coming on. Is there anything else you'd like to add before we do contact details?
Jillian: For my shameless self-promotion I have Bioanalyze, which I've been talking about. It is on Dabble-of-DevOps Bioanalyze. If you just go look for that or maybe it'll be linked in the show notes. I'm always looking for shares and stars and people to get the word out. It is mostly focused on bioinformatics but I am hoping to eventually be able to go and expand it, maybe get in some computational neuroscience or some proteomics or climatology projects, maybe go work with the folks at Pango or in video or something and see what's happening.
If you are interested in DevOps for the data science space, go look over there. I'm on all the social media places. If you're interested in keeping up with that news even if you don't even care so much about the data science, but you just care about the Kubernetes, and modules and things like that. I do have those, you can go grab them, everything is built as, I guess, Legos unless there's some copy infringement there in which case it's not Legos. It's something like Legos, that's totally not Legos. You can just go grab those, use the modules, do whatever you want with them.
You don't have to be doing bioinformatics and, of course, I always appreciate like and shares. I'm also e-begging on the internet lately because I guess that's where I'm at. I'm doing this as a bit of an experiment where I opened up sponsorship on GitHub for Bioanalyze. If you're working at a company and maybe the company would like to throw some money in the tip jar, that is very greatly appreciated so that I can keep on keeping on this whole building open-source software and making it available to the public.
If you're just an individual person, though, I don't really know how I feel about that, just keep it to companies that can expense things. Last thing I do have a newsletter. I promise this is the last one, it's on Bioanalyze.io. Just if you're interested and you want to keep up on a newsletter you can go sign up for it over there.
Jonathan: We'll have links to all these, the show notes, links to your social accounts. For anybody who doesn't have the time to look at the show notes, do you want to just shout out maybe your Twitter handle or how to find you for anybody with a good memory?
Jillian: I think if you just search up Jillian Rowe bioinformatics, I come up in quite a few places. Jillian spelled with a J, and Rowe with an E. As far as there's no other Jillian Rowe in bioinformatics that pop right up. I think I'm Jillian Rowe or JillianERowe on Twitter and I'm just Jillian Rowe on LinkedIn. Those are the two main places that I hang out.
I do also have the YouTube channel Bioinformatics on AWS which I am trying to resurrect. I'm hoping once I get the a couple more modules released and documentation really well done, that I'll be able to create more content for YouTube and more tutorials, more courses, maybe go do a course with free code camp or something like that. You can find me on all the places.
Jonathan: Really good. Thank you, Jillian, for coming on.
Jillian: Thank you.
Jonathan: I've learned a lot about bioinformatics, genomics, and a few other terms. Thank you for educating me and hopefully some of our audience.
Jillian: Thank you. I had a good time.
Jonathan: I hope we'll be in touch. All right. Talk to you later.
Jillian: Okay, bye-bye.
Jonathan: Bye. This episode is copyright 2021 by Jonathan Hall. All rights reserved. Find me online at Jhall.io. Theme music is performed by Riley Day.
Adventures in DevOps 111: Infrastructure as code and Amazon CDK
Have you considered the significance of infrastructure as code and its importance in the industry?
Adventures in DevOps 109: Is Kubernetes Right for You?
Everyone and their mother is talking about Kubernetes, but is it right for you?
Reaction to Ably's viral blog post and subsequent outage
I've grown tired of the constant bickering about Kubernetes or no. But this article is more an informative case study in the viability of one alternative.