From US Marines to AWS, a DevOps Career. Jake Furlong is a Technical Lab Developer at Amazon Web Services (AWS) and a self-taught DevOps expert, Site Reliability Engineer and cloud architect. He tells us how he went from being in the US Marine Corps to DevOps Career and to becoming an all-around DevOps specialist. And shares DevOps career tips and insights.
Interested in DataOps? Learn more about a career in data science.
I got out of the US Marine Corps and, honestly, I just took the first job that I could find. I started training new employees on how to use an Avaya telecom system; which I myself had no idea what that was. I did that for a few months and then they moved me into another role; as director of admissions systems and analytics. I had access to some free courses. So I took calculus and some computer architecture classes because that was kind of was interested in.
Then I stumbled across a CompTIA certification road map online and picked up an A+ book. I started reading through that and I stumbled across a book called Automate The Boring Stuff and started learning some Python. And most of my job was done through CRM and a lot of Excel, a lot of functions. I just started converting it to Python to automate my job and then I automated my friends’ jobs. And before you know it, it was all just running Python.
And I was talking about it while playing World of Warcraft, of all things. I had a friend in my WoW guild who worked for an SAP company and said “hey, we’re hiring if you want to switch into tech”. I talked to my family about doing a complete and total career switch.
The interview went horrible, but they were very very nice. I was willing to learn and they had seen how much I had learned in such a short time at my previous job and gave me a chance. I got an offer and that was the beginning.
As I said, I read through that A+ book, but mostly for the knowledge. Based on what I wanted to do in IT, I didn’t really want a hardware-related certification. Because I think that, for hiring managers, sometimes it’s easy to misconstrue a person’s skills based on what certifications they have. So I wanted to make sure I was marketing myself in a way I thought was relevant for the things that I wanted to do.
That’s when I found AWS and I kind of looked at the state of IT at the time and figured that cloud was really the way forward. I got AWS certified and then my company was getting really hands-on with GCP. So I got GCP certified and all of that was through free online courses and a paid Linux Academy subscription. I thought about getting an IT degree but it was just too expensive and there wasn’t enough hands-on. It was mostly theory. So I kind of took the theory from the books that I had, and then once I found Linux Academy, I just did every course.
Anything operating systems, Windows, Linux, database programming, web stuff, web development, cloud — whatever I could find. Then I found a site called Open Source Society University, and they have a GitHub page that basically gives you a list of courses from edX, Coursera or other free online tools that teach you the equivalent of a computer science degree.
That was very, very helpful. Then I just took that information and volunteered for every project at work. I took any ticket and tried to automate it, stuff like that. And the whole time, I was told that certs aren’t important to all the people that I worked with. But I think that hiring managers and HR might disagree. And let’s be honest, it’s kind of hard to get jobs without proving you have the knowledge and.
Since I don’t have a degree in anything technology related, I felt I needed to kind of differentiate myself a little bit. So I got those to kind of compensate for not having a degree.
I always go with free stuff or at least like the inexpensive Udemy sales. I think bootcamps are great for entry-level, but they don’t really allow you to work past that and most of the content online will get you through the basics. Try to solve a problem or find a problem to solve and really get your hands dirty with development or cloud engineering.
Certs are fine if you need them for a specific position or career goal. But I wouldn’t do one to learn. I might take the study guide and use that, but I think certs are a huge market and there’s a lot of money to be made from people that are looking to get certified.
I honestly just went to a lot of meetups. And I pretty much changed my podcasts to tech podcasts and just listened to those all the time.
I had a great time in the Marine corps. Believe it or not, I thought it was a lot of fun.
My biggest takeaway was really about how to work on a team. As much as there’s a lot of technical things I learned and things like that.
There’s just something about being humble and being a life-long learner and always striving to be better. About knowing your weaknesses and seeking self-improvement and being self-reliant and self-disciplined.
In tech, you have to because nobody is going to force you to hone your skills or learn a new programming language or how to administer Docker containers. You know, just that whole self-reliant aspect of being a continuous learner.
I work on the training and curriculum team, and we deliver content to our AWS customers. We have an awesome team.
I work with them to help build and design labs and lab instructions. So, if you were to go to AWS, and want to take a course to learn how to be an architect, for example, we have designers and curriculum developers, architects, managers and product managers that we worked together with to formulate a plan to build a course.
And my job day-to-day is to go through and support them so that, when they get to the hands-on portion, that a student can click start lab and that everything underneath the hood is provisioned and ready, works every time, and is repeatable across multiple devices or operating systems. I also ensure that the lab instructions are clear and easy to understand, from people who may have a lot of experience to people for whom this is their first time working with the cloud.
So it’s a technical role, but there’s a lot of human aspect to it. Understanding how people learn and how people learn technology – as a person who is basically self-taught, I use that a lot in this role.
I will start by saying that I don’t think DevOps is a real thing. As a community, we can’t even agree on what it is. We’ve been doing this since the 70s, the 80s? Really since the 60s. With Deming, and all of the work he did toward continuous improvement, total quality management, things like that.
And I think what we’re going to see is that we’ll revisit value stream mapping. How can we best automate and streamline value stream maps. Right now, we’re automating everything, and it’s all about pipelines and getting the developers close.
I think that’ll be short lived. We should have always been doing that, and I think connecting development to automation and ops problems is good. I think DevOps, the core of it, we want the developer problems and ops problems to kind of be the same problems, right? Where ops informs development workflows.
Developers use that workflow to produce either new tools or better tools, or even more consistent infrastructure. But sometimes ops doesn’t want things to change. And, as somebody who’s worked in the ops world, I totally respect that and I completely understand. As somebody who’s worked on the devish side of DevOps, I understand needing to get new versions of things out and upgrading things and patching things so that there’s a balance between it.
But I think what we’re really going to see is that, as you get to DataOps and really anything that needs to inform ops, is that everything is going to be data-driven. But it’s going to have to be value streamed.
So, what is the most important? What do you get the most benefit from as far as value? How much money are we really making or saving by approving X project or making Y operations a department priority?
I think, eventually, and once you start finding an efficient way and accurate way to attach dollars or time to these things, you may have some time and value attached to them as it pertains to the business and not just how many commits you made last month or something
A lot of it is requests for automation, declarative infrastructure, tons of monitoring, moving into containerization or modernizing orchestration tools, stuff like that.
I think a lot of it is also developer advocacy and just DevOps evangelism. Because it’s been around for a while, but it’s still relatively new. It hasn’t really permeated all the cultures yet. So, while a lot of people have a DevOps team, the cultural side I think needs a lot of work. So a lot of time is spent explaining why we’re doing this.
It sounds like the value is obvious, but it still takes up a lot of time to describe why we need resources, why we need time, why we should be doing certain projects.
A lot of the time is spent researching new tech, building up labs on your workstation or in the cloud somewhere, and testing a deployment meeting with ops teams to discuss their pain points.
And then, of course, all the pipeline things, so it’s a very collaborative job. You’re not going to see a DevOps person in a silo.
On a given day, you never know what you’re going to do. But it’s always going to be automating something or fixing something or updating something or monitoring something, justifying what it is that you’re doing.
Ironically, it actually came from a conductor of a music organization. He said “find something you love and do that because, no matter what you do or where you go, you’ll always be doing something that you enjoy.
Just do what you know is right and provide value to everyone around you and don’t worry too much about certifications. If you have the knowledge, it will all come together.
Just always be learning.
For more tips about DevOps career, make sure to follow Jake on LinkedIn.
Connecting Europe’s top IT talent with the most innovative brands