What is Devops? with Pablo del Pino Mejia

Chances are, even though you have been following the tech industry, you probably have never heard of DevOps. DevOps or Cloud Engineers are in high demand as they are the linking pin between Developers and the Cloud. They are the experts that know how to configure Cloud Packages like AWS, GCP, or Azure. 

It may seem trivial, but it is another profession. As such, I am talking to Pablo del Pino Mejia about his work as a DevOps. We are talking about AWS life in Vancouver and other Cloud Services.

Pablo is very much an old-school DevOps with approximately 15 years of experience. He has worked for a range of Agencies in Colombia and abroad.


Listen to us on all our platforms

https://tilt.buzzsprout.com/

Our Social Networks

Facebook: https://www.facebook.com/tiltshow

Instagram: https://www.instagram.com/tilt.show/

Twitter: https://twitter.com/tiltshow

Official website

https://tilt.show/

Listen to us on all our platforms
https://tilt.buzzsprout.com/

Our Social Networks
Facebook: https://www.facebook.com/tiltshow
Instagram: https://www.instagram.com/tilt.show/
Twitter: https://twitter.com/tiltshow

Official website
https://tilt.show/

Transcript

Unknown Speaker  0:29  
In this episode, we're talking about DevOps. Now, this is gonna get a little bit more technical than most episodes. First of all, I mean, you need to understand what's a DevOps? And I would say, most companies, he didn't have no idea, or they don't implement it very well. So imagine starting off an app or a website. Most people just think, hey, I need a couple designers. I need a developer. And that's it. Right? But what's the DevOps actually? And what does it DevOps do? In this episode, I'm talking to Pablo del Pino. And he's explaining us more about what DevOps is, what the DevOps does, and how to implement a DevOps strategy in your startup. Let's get started.

Unknown Speaker  1:21  
Hello, thank you for joining the show today. I mean, you're a DevOps Gurney stuck in Vancouver, I understand. When you're ready to go back to Colombia. That is right. So we're about Vancouver. I've been here in Vancouver since probably May last year, if I'm not mistaken, lovely city. I'm located near downtown. I'm actually very lucky because I have a very clear view of the beach. So it's kind of weird, because there's a beach but they're usually very cold here. So it's kind of a weird contrast. I really liked the city, the city's pretty interesting. It's a change of pace to what I'm used to. But at the end of the day, home is home. And I completely understand. I mean, I'm home currently. And it's really, I mean, it's different. Right. So yeah, I totally understand your point here. I wouldn't, you know, change it for the world, either. I mean, for the most part, I mean, I live in Colombia. So yeah, you ready to go back to Colombia? Right? Absolutely. I mean, honestly, the only thing that I'm waiting for is just go ahead, forget from the airports, from what I've been reading, things are sort of, you know, going in the right direction, there's the approvals that need to happen. Hopefully, I'll be home before Christmas. Awesome. Awesome. So Paulo, I mean, what I like to discuss is you're a special breed kind of developer which we call DevOps. I mean, it took me at least a year before I even hear about, you know, what a DevOps does and what it is, so could you I mean, for people who haven't no idea what a DevOps is, sort of, like, you know, could you give an introduction of what a DevOps does? And you know, what a DevOps is? Sure, absolutely. DevOps is basically a new term coined. Well, I say new very vaguely, but it's a term coined approximately in 2003.

Unknown Speaker  3:14  
Back then, it's not that DevOps didn't exist, it's just that it didn't have a name associated with it. Proper DevOps started approximately around that year, when flicker showed electric cold 1000 deploys, or 100 deploys in a week. Now, back in the day, this was absolutely unheard of a regular software release, or deploy could easily take three months in very advanced companies. And in companies that were not as advanced, you could probably take six months, he was very clear, it was very common to have releases maybe twice or three times a year. So the scenario where a company would attempt to have not only several releases during the year, but actually releases during the day was not only unheard of, but it was absolute science fiction. So based on that lecture, a lot of people started to notice that there were many similarities between the regular production chains that you find in manufacturing companies or in factories, where supplies going to one side of the chain, and then a finished product comes at the other side. So a lot of people started noticing that most of these philosophies could also be applied to software development, and to the lifecycle management in general. And that's how DevOps started. Basically, DevOps is just an abbreviation between developer and operations, and effectively means that the DevOps engineer is the middleman between the development team and the infrastructure that it's supposed to be in place for those developers who actually deploy code successfully. So at the end of the day, we are middlemen that want to ensure that the process of releasing code is efficient, optimal, redundant. And the infrastructure that receives the code is always up to par. homogenous, and it's always the same. So yeah, it's an interesting

Unknown Speaker  5:00  
Setting philosophies actually got it. So I mean, I can imagine, but now a lot of, you know, startups think or startup listeners think like, Hey, I mean, that sounds kind of expensive, I do have a Roku walk on the benefits would bring to me, right. I mean, a lot of startups just think, you know, let's take something cheap, like a Roku. If you don't know, Roku, it's just like, you know, you put your code on there. And that's it, right? There is no need for, you know, like, understanding of Linux or any of that stuff. So why would you go the hard route and hire a DevOps instead of going iroko? Or what are sort of the differences there? Sure. I think one of the most common misconceptions that a lot of companies have not just startups, but even, you know, bigger companies is associating DevOps with a specific piece of software, like Heroku is really good. pulumi is really good. There's a multitude of, you know, different pieces of software that can help you deploy the code. But that in itself is not DevOps, DevOps is it's actually a sort of philosophical shift that needs to happen within the company to be truly called DevOps. One of the early mistakes that happened, when people started adopting this was thinking, I'm just gonna buy software that can deploy code for me, and then I can call myself a DevOps compliant company, the reality is that this couldn't be farther from the truth, you need a fundamental cultural change within your teams, the developers need to understand how responsible they are for their own code. And certain processes need to follow a specific pipeline. So that if you change any developer, or if you move any of your pieces, and you insert a new piece, and you professional, a new addition to the team, the product keeps on rolling, like nothing happened. So I wouldn't worry too much about the fact that DevOps is expensive. One of the great things is that it can accommodate a lot of budgets, you have very great solutions that are open source, and you have commercial brands and solutions that are also really good. But none of those options, and none of these solutions actually mean anything, if you don't have the orchestra director, sort of like keeping the pace on things. So DevOps does not need to be expensive, in my opinion, it's more expensive when you try to implement continuous integration and continuous delivery software, without someone to actually conduct the orchestra, so to speak. That last part, I definitely can adhere to. So and I would say, I mean, if you sort of look at the not startups, but any company, I would say the bottom third are sort of the, you know, local, sort of, like, you know, bakery shops, local gyms website, right. And then you sort of start to become in the in the middle and the top part of the pyramid. I mean, that's where I definitely would expect DevOps to be more like a culture, right? I mean, if you're deploying a lower end bakery shop website, I mean, I don't think they would go for anything other than Wix or Squarespace, right? I mean, that's the reality. But if you're a startup, you shouldn't go for, like, a lower end WordPress site or lower end Squarespace site. Right. Do you agree on that notion that, you know, for which sort of level? Is it that you think, okay, Niels, you definitely need a DevOps for that sort of thing, right? Where do you sort of draw that line? Okay. I would say that on on side, DevOps will be a necessity, if you already have a software development team, if you have a software development team, if you have a project manager, if you have a product owner, if you have a team that is consistently churning out, releases, hot fixes, product updates, and you are feeling that these releases do not meet the expectations of either the client or even yourself, because at the end of the day, if it's your product, you're the first client first and foremost. But if you are always aiming for a release every two months, and you end up releasing every three months, or you need to push a hotfix and the eta is two weeks, but you end up pushing it in four weeks, then there's something definitely wrong on how the pipeline is working. I would agree with you that smaller businesses probably don't need a DevOps person per se, but they could benefit from you know, some of the the philosophies and teachings bigger companies, on the other hand, if they're consistently missing deadlines, and if their quality of the releases are constant headaches, then probably that's a sign that a DevOps person is needed. God I Got it. Got it. So let's imagine Pablo for a second, like your startup, right? And you are either pre you're still bootstrapped. Or you're like, you just raised some money, let's say $100,000. Right. At that point. How would you benefit in the future

Unknown Speaker  10:00  
of having a DevOps at that moment, right? Like, if you said like, hey, look, you got to have a DevOps on the payroll, is there any sort of like thing you can do before you actually get somebody full time? Is there a way maybe to have some of the developers already implement some of the theories? Or would you say like, you know, you can hire somebody at that point. But maybe as a freelancer, how would you prepare for your growth, to make sure that the server doesn't go down, for example, I will say that, okay, just to give you an idea, let me propose a metaphor, like, let's say that you're building your house, we're not talking about a giant building, we're just talking about your house. And let's say that in order to save costs, or because you know that your house is not going to be that big, you don't use strong enough foundations. So at the end of the day, yes, you build your house, your house is comfortable, your house is pretty, but then you start noticing that the foundations you live in are not exactly solid. And this is something that is almost impossible to fix once the house has been built. Now, leaving that metaphor, the image of the DevOps does not necessarily need to represent a person, sort of waiting at a desk for things to happen, kind of like the idea of old consulting is a definite possibility, if you are budget constrained, if you have developers, for instance, that are super involved into the deployment and their continuous delivery process, it would be very smart to actually invest in some sort of training for your own developers, there's no rule that says that you need to have the one DevOps person within the company. Now, what you really need to have is just some DevOps knowledge that could be achieved, by attending trainings by, you know, hiring a consultant for a couple of hours, the most important thing is that the company acknowledges where the issues are. And they acknowledge that from the get go, it's a lot easier to build your pipeline out your pipeline, right from the first time than to realize years down the road, that your pipeline has fundamental issues that cost a lot of money to fix right now. So you don't really need to hire a full time DevOps if you're just starting your pipeline. But it wouldn't hurt to hire maybe a consulting partner, or maybe attending some trainings, to at the very least starting with a familiarity of the concepts, then later down the road. If you find the need, you can act upon it. Got it? Got it. Got it. So what you're basically saying is, DevOps isn't like a one solution fits all kind of thing. Like, you don't necessarily have to have somebody full time, for sure. But even if you're just starting out, it's probably a good idea to make sure that you think about it in the future, right to get back to the house. I mean, if you think you're just building a cottage, right, but six months down the line, you need an entire 64, you know, building, it's good to have the right foundation in place. That's basically what I hear you say, right? So what kind of advice like, I mean, I see a lot of startups like the either pitch myself or my team, right? for, like, you know, for either money or So what advice would you give to anyone? Who is just starting out? And what kind of advice would you give them to prepare for the future? I mean, you should think about failure. But more than that, you should think about failure when you're successful, kind of right. So if you're, you know, you're you build an app or mobile app or web app, is there anything you would advise people to think about, like day one, you know, in terms of dev culture, the first thing that I would say is, nobody starts a business, regardless of how small or big it is, nobody starts a business, thinking that the business is going to succeed just for two or three months, I would say 100% of the people that start a business is because they want that business to endure. And they want the business to grow at a certain point. So if you're already thinking about a business is because you're thinking about a future running that business. That being said, the most important thing that you need to understand is DevOps is not a catch word. A lot of companies decide to have a DevOps person simply because DevOps is a trendy word or is just something that a lot of people are using. The same thing happened when a lot of companies were using benchmarking. And the same thing has happened when a lot of people migrated to the cloud. There are companies that sort of jump into these fads without fully knowing what they're getting into. So the most important thing is, as an owner, as a developer, as a person actively involved in the success of a company, educate yourself read about DevOps, most of the resources available for DevOps are not even paid. These are resources that you can find in very reputable websites, and they don't cost a thing. If you feel that when you read and when you research might benefit you do it from the start, budget or budgetary constraints should not be an issue because you can start DevOps pipeline with

Unknown Speaker  15:00  
Without having to pay absolutely anything. I mean, most of the cloud providers have a free tier, there's a lot of deployment orchestrators that are either open source or completely free, or even free with some limitations. So budgets should never be a constraint. When you want to implement DevOps, either at the start middle or in, the more you wait, or the more you tried to fix something that was already broken, when you start it, the more expensive it will get. The DevOps individual needs to accommodate to the kind of money you have, if you don't have money for if you have money for either a developer or a DevOps, please go for the developer, because the job is going to be more essential. But like I mentioned before, as long as there's the acknowledgement, that DevOps is important, you can always have your developers trained into DevOps so that they can be responsible for their own pipelines. As long as the philosophy is considered, it doesn't matter how much you spend, I would believe that every startup company with serious aspirations to make it in the future needs to at least understand the DevOps culture. Got it? Got it. Got it. So let's shift our focus a little bit Pablo. So we focused on startup founders, right? I know that in our beloved Columbia, for example, there's a lot of people that actually might want to, you know, shift their careers towards DevOps. They're either developers, or they're exploring, like the tech world, right? What is sort of, you know, their options. I mean, I know that many of the cloud providers, they offer a career towards what I would call cloud engineer, which is kind of like, you know, very close to DevOps, right? If you had to give any advice to somebody who's, you know, 20 to 25, you know, young, right? And then want to have a great DevOps career, what kind of advice would you give them? Okay. The first advice that I would give anyone interested in DevOps is that reading, and educating yourself is not only a necessity, but it's an ongoing struggle in the sense that every two years, there's something new, four or five years ago, we're all excited about using Docker containers. Now everybody's excited about using Kubernetes. And who knows what's going to happen next two years ago, it was the emphasis on serverless. So we really don't know what's going to happen. So be ready to always read to always do some research to always learn something new. If you don't feel comfortable with learning. Or if you don't feel comfortable with adding some new skills to your resume, then definitely DevOps is not for you. That will be advice. Number one, advice number two, there are different kinds of DevOps. In my personal experience, I'm not that much of a developer, I work mostly with bash scripting, and I can sort of understand a little bit of Python. But at the end of the day, I wouldn't call myself a developer, because I don't feel confident developing. And it's not part of my strengths. I do, however, feel very confident on my infrastructure and ops skills. So just because you're DevOps doesn't mean that you need to know everything in between, there are going to be dev ops that are more inclined to the ops side of the spectrum like myself. And there are others that are going to be more into the development side. And there's room for both. So the most important thing is that you can still call yourself DevOps. Even if you're more into development, and less about infrastructure. The most important is that you need to understand at the very least, the building blocks of each of both sides. And something that is extremely important as well is learn to spot where the trends are going. When I started working on studying AWS and everything, AWS only offered EC two instances and s3 buckets. Today, they offer a multitude of service and I'd be lying if I said that I know all of them. So the always on the lookout of the next big thing, infrastructure as code is extremely big right now. serverless, Kubernetes, microservices are still are still going strong. So have the ability to identify the next big thing, but the most important thing is always be ready to learn something. You brought up an interesting term, which I find, you know, kind of deceiving and it's the term serverless. I mean, many people have used it, many people have, I mean, I see it, a lot of times in my own, you know, business people are working on serverless. I mean, I think it's a Steven because the first thing you need for serverless is actually a server, right? I mean, could you explain to people aren't so technical? What exactly is serverless? Okay, so serverless? Yes, like you said, I mean, it is a little bit deceiving to talk about serverless especially when you know that you're just setting something up in a different server. It's kind of like saying cloud cloud is also this evening because at the end of the day, there's there's really no cloud is your someone else's computer. But the concept of serverless is not really where where the application is hosted, but the way it is hosted normally, when you deploy an application you need

Unknown Speaker  20:00  
either an instance of virtual machine something that you need to configure patch update, and then get ready for deployment. serverless as it is means that you can deploy your application without having to worry about the infrastructure as it is to give you an example, that is probably not very accurate. But Elastic Beanstalk was probably one of the first beginnings of true serverless, you don't need to know exactly what's going on within the surface. All you need is a Tomcat WAR file, or you need something specific that you need to upload. And then it basically runs itself. And you don't need to worry about updating dependencies or packages, that all happens behind the scenes. So when we talk about server lists, we talk about you not having to worry about maintaining a server, there's always going to be a server at some point and somewhere. But if you don't have to worry about maintaining the server, setting up the server, configuring the server, and then effectively, your application is serverless. to you. So that's basically what serverless is, you don't have to worry about prepping, or you know, sort of configuring where the application is going to be. You just need the app. Got it? So yeah, I mean, I can imagine a lot of people be like serverless. So what you're basically saying is serverless still uses a server, but you just don't need to worry about that anymore. It's like Dropbox or s3, and like, all those services, Google Drive, they'll use a server, but you just see the files. And that's it. Yeah. Yeah, you could probably argue that if we follow that logic, most of what we use is serverless. Because we never get to see the servers. But in a sense of the word, anything that you can define a service is something that you don't need to consider your to configure yourself think about RDS, or Firebase databases that you only need to provide the information or the data within the database. But you don't need to configure it, you don't need to worry about the hardware behind the database, all you need is to start interfacing with the database directly. That's an example of serverless, same as dynamodb, for instance. So there's a lot of variations on that concept. But that's how I interpret the service. So I have a little bit of background in technology I can program but I really shouldn't. I mean, I'm one of those people. And one of my trainers once said that, I mean, going back to starting a starting a business, right? He said that once you need to worry about like, you know, configuring your databases and making sure you have multiple instances and that they all sync up. I mean, at that point, you sort of should be financially at the point where you should actually be able to pay someone to do it, is that sort of the right answer to like going from serverless to having your full time server as well, I would say that it partially is in the sense that if, like you said, if you have enough budget to actually go serverless. And again, this is not something that applies to everything. The same situation. With microservices, there are applications that are not optimized to be running on containers. And yet a lot of companies jumped into containers, because they think is what they should do. At the end of the day, going serverless does represent that your level of maturity is higher than say, a startup that just began assembling a team, I wouldn't say that you need a DevOps to sort of set things up. But you do need someone could be a DevOps could be an SRP, or it could be just a very advanced developer to at the very least know how the process works. Most of the companies, they're very happy with just deploying everything seeing and work. But if they have to do it, again, they have no idea how. So if you go to serverless, thinking that you don't really have to configure anything again, well think again, at some point, you're going to have to migrate or upscale, or I don't know, in certain cases, just build the same thing. So while serverless sort of gives you a lot of convenience, you still need someone to at least understand how the process of getting your application to that infrastructure works. It really depends on how mature the company is. I wouldn't advise companies that are just starting to jump directly into serverless, or containers or micro services. The first thing that I would advise is feel comfortable with how your application works. deploy it more than a couple of times without issues and then once you have that pipeline, pretty much pat down. That's when you start considering upgrading to the next big thing. Yeah, about upgrading. I mean, I think you touched an interesting part of, you know what I would say DevOps or like running a server. I mean, what I've seen don't people do is like you can either be too early, right? I mean, I think with Roku, as we mentioned before, without you know with running your own RDS instance, maybe using a package, you can get a long way. I've seen people do multiple well millions of dollars to run

Unknown Speaker  25:00  
In revenue that way, but I've also seen people like they had a big instance in a Roku, they spend over $100,000 a year in just a Roku cost, nothing additional, like no subscription. Additional, I mean, I think in total, they spend two $300,000. There. I mean, to me, it seemed like they would tremendously benefit from having somebody like yourself, and then just running it on a server, when do you sort of see in terms of monetary value, when you really, really need a full time DevOps to start your cloud infrastructure? Okay, so I don't know how common it is now. But it used to be very common a couple of years ago, when the last remaining companies that were not migrating to the cloud, were actually taking their legacy applications into AWS or Azure or GCP, what have you. And they started to notice that it was a very painful process, not just because it's difficult to migrate from actual on site servers to a to AWS, for instance. But because a lot of the code and a lot of the procedures were not very well documented, let's take Heroku, for example, Heroku is a great service. And it certainly brings a lot of convenience to the deployment of an application. On the other hand, it also brings a false level of security in the sense that what happens when at some point, you need to deploy your application somewhere else, or there's an outage, and Heroku cannot deploy that essential hotfix that you need to deploy to your customer, you can't tell them, I can't do it, because Heroku is not working, you need to have a backup plan. So I love tools like that, as long as you know exactly how those tools work, and what to do when the tool stops working. That's where having a DevOps actually pays off. I've seen a lot of companies that rely on either Jenkins, or Heroku, or Travis CI, or any other piece of software or get lab ci. And most of these knowledge is monolithic, in the sense that usually one or two people, usually the people that actually set it up are the ones that actually know how it works. If that person no longer stays in the company, or that person is unfortunately unavailable during a time of crisis, the whole company grinds to a halt. So these tools are very, very good. They're very convenient. But there's always a need to understand how the process works. If you at any point need a DevOps, the best moment to actually hire one either as a consultant or as a full time is when you require clear documentation about how the process goes from the developers computer, into deploying to AWS to GCP to a remote server, whatever you want. So at that point, when you rely too much on software, you always run the risk of not knowing what to do if that software is no longer available. And we've seen it before outages happen to absolutely everyone only last week, there was a general outage with Gmail and Google Drive. And I can assume a lot of people felt the impact, there was an outage with zoom last week, and a lot of people, especially classrooms could not really continue their training. And these are the things that should affect people. But it shouldn't affect you to the point where you can run your business. So software is good applications are great. But always have someone that has clear concise knowledge on how the application works and what to do in case it doesn't work. That's where the DevOps coming. Alright, so what you're basically saying is that a lot of businesses in recent year moves from having physical servers, maybe in their offices to having the flexibility, I would assume with COVID-19 dos who had to move to the cloud. I mean, they will move to the cloud right away because people couldn't read the offices anymore. But what you're basically saying is that while cloud is great, it's probably a lot cheaper than having your own servers. It does not mean you should get rid of the Server Manager, even though he's no longer like physically installing servers. He still needs to maintain your server base, even if it's in the cloud server. that correct? Yeah, that's a very good point. And the example that you gave regarding COVID shows exactly how unprepared a lot of the companies were for remote working, or cloud based working or mobile office. I mean, a lot of the companies sort of dip their feet into remote working. And this is especially true in Latin America, and especially in managing for instance, where working from home is seen most as a perk that you offer to potential hires than to an actual valid shape, or form a working. Colombia does not have legislator on remote work. It's only starting due to the COVID contingency. And you have no idea how many companies had a really tough time moving from their office into a complete remote environment simply because they were not prepared.

Unknown Speaker  30:00  
They never saw it, as you know, a future proof, they just saw it as something that you could potentially give your developers once or twice a week. But there were a lot of companies that were ready. There were a lot of companies that were not, but they took the step. And there were other companies that were not ready, and they felt the heat. So regardless, where you have your infrastructure, be it on site, via in the cloud, you have every right to keep your infrastructure wherever you want. There's a lot of regulations. For instance, if your company's PCI compliant, or if your company handles very sensitive data, maybe the cloud is not for you. So you still need to have on site servers, regardless of what you do. I think one of the mistakes that cloud providers have made is showing everybody how easy it is to set up and how easy it is to have your own server in the cloud. But they never go to the tribulations of actually maintaining that server, everybody can go to AWS register for a free tier, enjoy all the resources for one year, and start just, you know, setting up servers and s3 buckets and everything. And then they get surprised when at the end of the month, they get a bill and the bill is 2050 $100. And they say wasn't this supposed to be free for the first year, trust me, I've been there. So regardless of where your infrastructure is, know what you have, know how to set it up and know exactly how much it is costing, trust me, a lot of people feel the pain moving into a remote friendly environment, because they were not ready for that. So it's obviously a very radical contingency, this is something that no one expected. And it would be terrible of me to actually blame companies for not being ready because nobody anticipated this. And nobody anticipated lasting this long. But preparation is key. So if at any point, you're thinking about changing your infrastructure, hell even changing your server brand, at the very least know where everything is, and how to set it up. I completely understand the shark that some people might have with, you know, getting a bill from AWS. I mean, $20 is okay, for most people, I would say hundred dollars is a little bit of shark. But I mean, I frequently get more than $1,000 a month, but yeah, we host for for many of our customers. I mean, our bill is easy in the thousands of dollars, right? alongside multiple accounts. But if we were to host on site, or you know, we would need to get an office somewhere or do what's called colocation, I mean, it's, it's adding up quickly as well. And it's not as flexible. Because what you will see if you grow bigger is there as moms you need, you know, a lot of resources and there's one, you don't really need that many resources, right? I mean, you would see that as well. So to round up a little bit, the story, I mean, I see a lot of people that are hesitating to move to the cloud as well, because of the look of the cloud locations, right? So the US has, has a great infrastructure. If you look at Latin America, what I always was surprised about if you keep having AWS as the example. There's just one location there. It's it's some Polo, and for the last, I would say at least 10 years that I've seen AWS there, they haven't added any locations. Do you happen to know any reason why that is? Like why? Why is there no, AWS, Chile or AWS, Colombia, and what and what does actually matter having having servers in your country where you reside? Well, this is not something that is exclusive of AWS, I'm going to give an example that is a little bit off topic. But for instance, if you play World of Warcraft, or if you play Call of Duty, you'll realize that all I do, yeah, costings that they work on dedicated servers. And most of these servers are widespread in the US, Europe. But then again, Brazil is the only one that has it. So I can't claim to be an expert on this. But from what I gather the location of dedicated servers, or call centers for big companies like this, I think at the end of the day, boils down a lot into government bureaucracy, and how the rules are set up. It's my understanding that in the last couple of months, pre COVID, Amazon actually set up a warehouse in Bogota. So that means that when you order something from Amazon, you don't have to wait for it to arrive from the state. It actually ships out from Bogota, to me, that's the first step to potentially having a data center added there. It's a very valid question. But to be honest, the only thing that I could think of is there has to be some government rules, or some government hurdles that have to be passed over before actually opening up a data center. Maybe it has to do with the fact that Brazil has a very robust, open trade 3d with the states. Again, I'm assuming because I have no direct knowledge of this, but setting up a data center for an American company. It's something that needs to be very clear for both parties and I don't know if for the cases

Unknown Speaker  35:00  
of Colombia, at least that's clear, I still believe that the opening of the new warehouse for Amazon, it's a step in the right direction. And I wouldn't be surprised if another data center would be added. I am surprised that there's no data center in Buenos Aires, for instance, or Chile, like you mentioned, these are very, very big technology hubs, specifically when it hardens. So let's just wait and see. But in my opinion, I just think it's just, you know, government things. So Paulo, I mean, as we started off, you're currently in Vancouver, you're working for a local company they're using? I would assume AWS or GCP. Is there any reason why companies in the US or Canada would not use somebody in Colombia? I mean, soon, you'll be on a on a flight, I hope for you in the next month or so when you know, the borders are opening again, COVID is behind those a little bit? So is there any reason for you not to work for a Canadian firm from Columbia, or from the US? And if you're in a firm, firm position? I mean, is it trustworthy to have somebody you know, in Columbia manager service? Okay, that's a very solid question. In this specific case of Canada, Canada is really the only other country aside from Colombia that had lived in Canada has very strict rules regarding remote work. Canada, for instance, has remote work available to local workers, which means that if you reside in Canada, and you want to work remotely for your company, you're absolutely allowed to do shell, things sort of changed a little bit when you want to work remotely from a different country. I am assuming that it's because of labor regulations, because the states for instance, they don't have that sort of a problem in the States, though modality of working remotely for any country has been picking up a lot of steam. I know there's a lot of people and fellow colleagues in managing Ebola die in Cali that are working remotely for American companies. For United States, it makes a lot of sense. And it makes a lot of sense for a very simple reason. And that reason is, it's actually twofold. One near short, and to budget. If you think how much an American developer can earn per week, it's pretty much the same amount of money that you can pay a Colombian or Latino developer per month. And I'm not saying that this is a good or a bad thing. I'm just saying that it's the way it is. So in terms of investment for an American company, it becomes a lot more convenient to hire people that are nearshore, which means people that are on or close to their own timeframe, or their own time zone. And the money investment is a lot lower than if they actually had to pay someone within the state. Again, I'm not American, I don't have any sort of insight into how labor laws work in the States. But in my experience working for American companies, which I have for a few years, I think one of the best one of the main issues of why they do what they do is aside from cost and the near shore convenience. Latino developers and Latino technology professionals are extremely good. And they are extremely desired in pretty much any country in the world. Canada is trying as much as possible to bring as many professionals from Latin American countries, specifically Colombia and Brazil. And I think for the first time in many months, the influx of Latin American immigrants surpassed the number of Indian immigrants. And it's because the quality that we have to offer, it's actually really, really good. So they noticed that in the States, they noticed that in Canada, as long as working with sensitive data or critical data, Every company has their own version of an NDA, for people that don't know is a nondisclosure agreement. But it's pretty standard. Basically, it means that whatever you develop, or whatever you work on, during your tenure, as a company employee is company property, and you cannot use it anywhere else. And this is actually very easy to enforce. In problem. Let me cut you off a little bit. So what I try I mean, I understand that labor laws differ by state differ by country. But I mean, independently of where somebody is located. I understand because that's my sweet spot with my company as well, that having somebody in the same timezone has very many advantages. I also know that Latin American developers are at part of their North American counterparts, I would argue with it's the same, but I mean, I can imagine a lot of companies are actually hesitating to give away access to the sensitive data or any data for that matter, user data to somebody who's remote. What would you say to companies that are sort of like, Look, I'd rather have somebody in my office, that control then somebody who is located imagine or Bogota or, you know, anywhere in the world for that matter. What sort of your thought around that. Do you have experience where

Unknown Speaker  40:00  
with remote DevOps for sure I have, the one thing that I can tell you is, you can't expect to hire someone to work for you if you won't open the door for them. Or if you don't let them into the office, or if you don't let them have their own resources, access to resources, is always going to be a touchy subject, regardless if the person is in the office or outside of the office. Just to give you an anecdotal figure, I used to work with ethical hacking and network security. And I can tell you that 75% of corporate intrusions data espionage come from within the office, and they're usually people with the highest level of access, working remotely does not change that as long as you have a very clear cut access strategy, you can only have access to those resources that you actually need for work. In my experience, when I have worked remotely, I don't have access to the whole thing. I don't get the keys to the kingdom, I only get access to the resources that I specifically need to perform my job well. So if a company has 50 servers, I don't automatically get access to those 50 servers, I probably get access to just the servers that I require to work on, then again, This all depends on the company itself, I'm going to use the access that is provided. But I'm not going to lose any sleep, trying to think if I have access to more or less, I'll work with what I have. The company is the one that needs to have very clear cut policies on what does this person need to access what s3 bucket this person needs to access? What GCP Firebase database this person needs to access. If he's in DevOps, he has absolutely no need to access finance or marketing data, it doesn't really change that much from the level of access that you would have locally, the only real difference is that locally, you actually get to see the person sitting at the desk. But the level of axes is identically the same. I think a lot of people found this very insightful, um, in many people I can imagine in the podcast, up until this point, had never heard of a cloud engineer or DevOps. So thank you very much, Paulo, for joining the show today. And yeah, I mean, I wish you well, going back to Colombia. I mean, it seems like you're Stark, many other people are stuck. So let's do this big chair dance in the next couple of months. And, I mean, I hope to see you soon. Hopefully, it'll be that way. And thank you for inviting me to show. All right. Thank you.

Transcribed by https://otter.ai