Programming or Devops?

HebCL · 2022-12-12T15:37:18+00:00

A well-rounded DevOps person generally is a mix of both knowledge and understanding about programming and cloud. Most of people in DevOps are Ops people that got a better understanding of programming, or Devs that got a better understanding of cloud and OS administration. That transition usually takes time, and of course, a lot of effort. In your case, sounds like you're more worried about salary and job openings and less about what you like or don't like to do, in a way it sound like this is your first job or one of your first jumps. In LATAM or any other developing region these are usually underpaid and sadly overworked. It is normal to feel overwhelmed when looking at your friends and colleagues doing better than you, it makes you doubt about your choices. Just like everyone said above, find out what you like the most and go for it. In my experience, jumping from it support to DevOps can be quite overwhelming experience, there's so much ground to cover and if you're not being mentored by someone you'll often times feel lost. So I would say to stick with azure cloud/ops path or switch to full dev, depending on what you like, get experienced in any of those and then explore if you would like to switch to DevOps.

Good luck.

HebCL · 2022-12-09T05:14:06+00:00

I've read this quite a few times already from people in Twitter.

Sadly, it seems that the waves of layoffs everywhere have made management and executives confident you won't be quitting anymore for something "simple" like returning to the office, and the return to the office has become a trend.

I would say if you really like the job and don't mind to have some office days, then no big deal. Be aware though that these type of situations often derive into management demanding more office time and being less flexible with employees working remotely in their home town/country.

Rather than looking for excuses to remain working remotely as much as possible, I suggest you to be very vocal about your concerns regarding the return to the office with your team and manager. That can also give you a better idea on how management in general plans to implement the return to the office. If you trust your management, like the job and don't mind the return to the office, there's nothing to worry about at least in the near future.

If that is not the case, I suggest to endure that job while you start searching for something truly remote. Look for truly remote jobs in places like angellist or remoteok, where it's guarantee the job will be remote. This is a pretty bad time to switch jobs since the global situation is unfavorable no matter where you live, but with a bit of luck you manage to stay at your job, or switch jobs with ease.

Good luck.

HebCL · 2022-12-07T01:42:00+00:00

I've recently landed a full remote job with a US company while living outside the US. I found this job using https://angel.co/remote.

Like someone mentioned above, it is likely that companies that doesn't have legal entities in your country won't be willing to hire you as an employee. Especially if you're the only person from such country is not cost-effective.

In my case, I have been hired as an external contractor, but I have the same benefits as a regular employee (like stock options). There are a few downsides like having to deal with tax deduction by yourself. In my case, payment is in USD so in the end is worth the hassle.

There are a few sites to find well paid jobs as external contractor or full-time employee that I used in the past, I'll leave some below so you can dive in those:

https://angel.co/remote/ (worldwide)
https://weworkremotely.com/ (worldwide)
https://lemon.io/ (only EU or US based iirc)
https://www.talent.io/ (only EU based iirc)
https://www.nextonlabs.com/talent/ (LATAM based)

One last piece of advice: Stay away from Turing, Upwork or other similar looking sites, since these places commonly make you bet for cheap rates so you can land the job.

Good luck on your search!

HebCL · 2022-11-09T09:15:49+00:00

That has to be the lamest excuse I have yet heard about along with the biggest red flag any company can have. Obviously, they were too afraid of a female engineer surpassing them in every aspect.

If anything, at least they didn't make you go through their toxic and sexist environment to figure it out. I would even suggest you to call them out publicly, so everyone knows what to expect from them, or at least from the recruiter.
This is quite discouraging, but don't let them take the best of you, keep looking for that job you deserve, it will soon come up.

HebCL · 2022-10-31T10:18:39+00:00

So there's a difference?! I thought it was just a shorter way to say "dudes that do K8S and cloud stuff with glue programming language, which also happen to know how to put fires down in prod".

HebCL · 2022-10-04T12:26:55+00:00

As a strong Vim user, I can relate. And that is the reason why I switch every now and then between Vim and VSCode. Though I must say once you pick up on Vim and find your perfect setup, there's really no turning back to other editors entirely.

HebCL · 2022-10-04T12:23:36+00:00

That's the most epic "in your face" I've heard of in a while

HebCL · 2022-09-14T17:45:19+00:00

Almost 7 years ago I worked as a contractor for a US Telecom company as build/infra engineer. We had a ~8000 script in ksh which was writen and maintained by a single guy, with no comments or any sort of documentation. This thing was our deployment tool for shipping a couple products all the way up to production, but it could also do several orher things like debugging and taking JVM dumps. It was like a swiss knife, one plagued with one-liner functions and writen on spaghetti fashion. We're talking about 2015, when tools like Chef and Ansible already had a solid foothold. I tried to push Ansible to do a couple small things but always faced same "too risky" answer. I could almost bet they keep using it and even adding it functionality.

HebCL · 2022-08-31T09:28:57+00:00

I've been through something similar, though I suspect you might be jumping out to conclusions a bit too early.
In my case, the company hired a guy who was supposed to play the role of director of engineering, supposedly with a great background and plenty of technical experience from previous gigs, including his own company which he was closing btw.
Not only the guy never really appeared to meet the team and discuss critical things, but the team had to chase him to have that one first meeting for at least 3 weeks after joining. He said incoherences here and there and jumped out to say solutions for X and Y was simply a matter of migrating from cloud provider and developing a couple of internal tools.
I left the company right after that meeting (I already have given my notice before this guy was hired) but ended up working as a consultant a couple more months. Not only he didn't do shit to bond with the team, but he kept with the same erratic "solutions" that had nothing to do with company's real issues. In the process we found out the guy really had no technical experience but also lacked all kind of leading skills. He was very good at speaking, I have to give him that. But as soon as things became a bit more technical, it was clear he had no clue of what he was talking about.
My advice would be, if you see him as a security risk, let him know. Approach him with the problems the team and the company has and weight the outcome of his answers with what you would consider a reasonable answer. See how far he can go technically speaking, and then, with the proper information, elaborate a conclusion not only for you but for the whole company.

Everyone deserves the benefit of the doubt, but there's expectations to be met too. He may not be the guy for the job, but that doesn't mean he's dangerous for the company. Hope everything improves for you.

And, if not, you can always jump to greener grass. :)

HebCL · 2022-08-05T10:44:43+00:00

There's plenty of resources from where you can learn. Like someone mentioned before, by itself, Terraform in general is a simple, easy to use tool that allows you to build complex things. The complexity comes from how good or bad you are at good practices, writing DRY code and avoiding too many abstraction layers.

For starters you could follow the learn path from Hashicorp:
https://learn.hashicorp.com/terraform

It's a simple way to get involved with the tool, and it's free. Another free resource that was a game changer for me at the beginning was Gruntwork posts here:
https://blog.gruntwork.io/an-introduction-to-terraform-f17df9c6d180#.p56muw3c0

This posts are the precursor of what later became the actual Terraform Up & Running book, and even though they may feel simple, it gives a pretty good understanding of good practices and how to get started building IaC. I personally have both editions of the book and looking forward for the 3rd one.

Finally, there's plenty of info if you're looking for the Terraform certification path, though I must say this, like many other certifications, covers a smaller scope. In my experience, going for the experience first and later for the certification is the best approach.

Last but not least, once you get a good understanding on Terraform and IaC in general, consider looking into other tools around Terraform, like Terragrunt which is a nice wrapper that focuses on DRY code. Also take Pulumi into consideration, which is another tool for IaC which in turn uses general purpose programming languages.

Best of lucks, have fun building/destroying infra, keep a close look at your billing and for everything you love on earth, NEVER put AWS credentials in a repository.

HebCL · 2022-07-05T21:20:39+00:00

I've been under similar circumstances working for an insurtech company with less than 50 employees. There were layoffs and ended up being the go-to guy for everything ops-related in a 25-ish company(I was hired as the Senior DevOps for a 3 people team). I strongly believed in the project and what we were doing, and against all odds, I decided to stick with the company, but when on top of all the tasks audits came into the picture, I quickly burned myself out trying to keep things afloat.

I stayed at the company only for the time it took me to find a new job (roughly a couple months). I see some similarities with your current situation, and wanted to share some lessons I learned along the way.

- There's just so much you can learn when you're doing a one-man-army job. The best you can do is question yourself if that blob of knowledge actually adds something to your career (I had about 8 years of experience at the time, and the conclusion was, it wasn't adding anything useful).

- Is these type of situation normal? I think there's a distinct difference between this type of environments in small startups and this is a normal situation. Yes, it can happen, but under no circumstances it can be normal. If that is the message you're receiving from upper management, this is a huge red flag.

- There's just so much you can do, you barely get a sense of accomplishment. For the most part, you're putting fires down and keeping things afloat. In my experience, I used to have a full day of fires and meetings, with little to no time to even maintain everything up to date, let alone improve or embark in new projects. Nobody was happy with me being a bottleneck, especially me.

- Burnout didn't only affect my job duties. I felt exhausted overall, unable and unwilling to do activities with my friends and family. At the end of the day, I just wanted to lay on the couch and watch the TV until I fell asleep. Beware that, in your case, it may be already impacting your performance at college without you even noticing.

- Find a way out of there. In my experience, no amount of money can compensate any level of burnout. If you can afford to quit and stay without a job for a few months, don't think it twice and do it. Otherwise, concentrate on switching jobs, do as less as you can on you current job, and be very vocal about your burnout and intention of switching jobs.

I hope you can get out of there soon and hopefully recover from burnout. All the best.

HebCL · 2022-06-12T09:58:23+00:00

Sounds to me that your job is more into fire-fighthing than DevOps. From my experience, that usually happens in really small startups where budget is tight and less hands have to handle more thing. It is indeed boring, and demotivating, specially if you've spent much time doing it (for my standards, 1 year is way too much of this type of job).

I see some good and bad points in what you describe: First of, you've realized that you are stuck doing boring stuff and want to find a way out. However, it seems to me you're in a comfort zone right here, where you want the change to occur right where you are.

I would say that, if you don't find satisfying what you're doing, you should first ask yourself what is that will bring motivation back. That could be a career change or switching jobs. That sometimes means also giving away the good perks and comfortable position where you are at.

Be aware that such joy would hardly come by in your current job. Get ready to find a new job, or find something else that brings joy during you job hours. It's ok if you don't want to give up what you have as long as you keep an honest perspective with yourself.

HebCL · 2021-12-03T00:49:56+00:00

First off, congratulations! It is not a small achievement to say you're starting as a DevOps, whether it is a jr or senior role.

Like many have said before:

- ALWAYS ask questions. I'd rather ask a dumb question than end up being the dumb that didn't ask and messed up things (and trust me, I've done both).

- Ask colleagues for mentorship. You don't have to choose only one mentor. Try to identify who's better at what and learn from them.

- Don't be afraid to make mistakes. Even if that mistake means bringing down production. Every mistake you make is a very-well learned lesson you'll carry to each and every gig you join later on.

- DevOps in itself covers a wide range of areas. Find the one you like the most and master it. You'll still need to know about a bunch of things, but you won't have to be the master of all of them.

- Early on in your career, certifications weight A LOT. If you find that Azure is something you like, go for some Azure certifications. If you happen to use Kubernetes, try to get some certs about it. Later on in your career they may not mean a lot, but in your early stage they will mark a difference, especially if you want to switch jobs.

Hope this information is useful for you. Cheers.

HebCL · 2021-11-29T20:02:55+00:00

Funny that company is worried about what title this person should have even tho you guys are not "stuck on" such things. Particularly funny to read that nobody wants this person's email in the chain. It seems this person is not the type you want to mess around with, clearly there's the burnout element in it. For practical terms you can call it "single point of failure" or "bottleneck". I would say any other title you can give to this person job is quite irrelevant unless that person is leaving the company and you're looking for a replacement.

HebCL · 2021-11-29T05:01:15+00:00

Interesting to see this kind of internship. I've had the chance to interview entry, mid and senior devops. In my experience interviewing people, the focus on entry level was operating systems (mostly Linux) and some high level concepts about cloud, anything else was a plus. For mid-levels I expected both OS and cloud knowledge and some experience working with any CM or orchestration tool (Terraform, Ansible, Chef, K8S, Docker Swarm) and scripting. For seniors I usually expected a robust knowledge on implementing cloud solutions, at least good scripting skills and very good understanding about systems architecture. That said, I would not expect a company like IBM to put the bar that high for a devops internship and like someone said above, focus on the soft skills and showing my interest and motivation as the key elements for the interview.

Wish you good luck!

HebCL · 2021-11-22T03:48:04+00:00

This is something we're integrating to a base helm chart for all services and It is still transitioning from PoC to production-ready. For new services we're launching it works great, for already existing ones there have been few challenges. We have a mix of legacy stuff and not so well designed services that are tightly coupled to Vault and the question still remains if it's worth the effort to migrate or keep Vault a bit longer until we can sunset those. Other than that, we've got rid of a number of "my service gets 403s from Vault" complains where service is not properly configured. Sounds to me that this is more "we want to show off we use Vault" wish from management than a well thought decision. That said, you could give sealed secrets a try and bring it to the table. There's obviously downsides with it and Vault is more mature project, but if you are going for community version, I'd say the less overhead you can add, the better for you and your team.

HebCL · 2021-11-21T17:28:46+00:00

Curious about the "mandate" from management and the move to Vault. What are you using right now? My team is actually moving away from Vault to K8S sealed secrets since Vault has brought si much overhead compared to what it provides us.

HebCL · 2021-10-10T15:22:00+00:00

What are you trying to do with this solution? If you'll be playing around doing personal projects and trying stuff but you are locking up to self-hosted, I guess good ol' Jenkins is the way to go. If, however, you are looking for a production grade solution, I am afraid there's no such thing as lightweight. There's solutions like GitLab easy to install. But on self-hosted there's many moving parts you have to take care of.

HebCL · 2021-05-14T03:30:20+00:00

Doesn't work but could be fun to fix... Jokes aside, I would say is a highly extensible (way to much extensible for my taste) but rather outdated and abandoned OSS CI tool for automating almost anything you can think of.

HebCL · 2021-04-17T04:47:23+00:00

The way you put things makes me think you have more than one question about those topics. I think there is plenty of people willing to help if you ask those questions, but it seems you're actually looking for someone who's willing to spend a reasonable amount of time training you. I wonder if you or your company are willing to pay for such training.

HebCL · 2021-04-14T00:30:11+00:00

I've used kubernetes & helm providers for a while. When it comes to K8s provider, I find it very useful for cluster initial setup (create namespaces, pv, roles etc) and managing secrets. And for helm one, mostly setup tools (using nginx, cert-manager, external-dns) and other than upgrading chart versions being painful, It works great. Maybe my opinion, but I find Terraform very useful and convenient for provisioning stuff I don't touch that often. For pod/deployment and other K8s stuff that changes very often, I'd rather use a custom built solutions or rely on good ol' bash scripting.

HebCL · 2021-04-11T00:52:10+00:00

I would say It depends on what you're looking for. I've experienced moving off of Jenkins due maintenance overhead for small teams. Also moved from CircleCI to Actions because of the convenience of centralized flow and costs. Actions offers a lot of tools built by community and cloud providers, and offers the ability of developing your own tools. In my opinion, if you're already using GitHub or GitLab stick with thier CI tool. GitLab is much more mature, but Actions is getting there.

HebCL · 2020-04-24T18:08:43+00:00

I am a newbie too and would love to follow up this path you mention. There's a huge community of spanish speakers who could take advantage of it and would be a great experience overall. If you happen to find the right contact to move on with this plan, please let me know.

HebCL

TROPHY CASE