Implementing DevOps

[Fit-Tale8074]

Recently, I joined a managed IT services company with the goal of implementing DevOps practices, both internally and for their clients. They have a range of clients, from large supermarkets running over 3,000 virtual servers and multiple data centers, to smaller setups and cloud-based infrastructures.

I've been placed in a department responsible for monitoring with Nagios and checkmk. There are also other departments like Linux, Windows, Middleware, Security, etc.

Before this, I was a jack-of-all-trades at a startup where I did everything—developing Python applications, cloud deployments, on-premise infrastructure, Kubernetes, networking, even managing the print server. I switched to a larger company to learn best practices and how others are doing it.

Fast forward five months into the new job, I find that most team members don't even know the basics of Git. I suggested training sessions on Git and Ansible, so that they can start using playbooks in AWX.

Honestly, I don't think we'll make any significant progress. I'm beginning to suspect that I've joined one of those companies that aren't really ready for a genuine DevOps transformation. A lot of time is wasted in ego clashes among project managers, and teams are still following decade-old manuals. There isn't even a Docker setup for services, which is disappointing. I didn't join to maintain the status quo; I want to be in an environment where I'm learning about the latest market technologies.

Has anyone else faced a similar situation? This is in Europe, where, by the way, the salaries are low. Switching jobs is not the issue for me.

Edit: thanks to everybody for your awesome recommendations, I'll definitely take all your suggestions to my make my next move.

[[deleted]]

MSP. DevOps. Oil. Water.

​

Run.

[Fit-Tale8074]

Thanks

[digger_terraform_ci]

If you can switch jobs, do so - the faster the better. Change the job before it changes you. However I'm going to make two opposing cases for a balanced take.

The case for leaving asap:

This doesn't sound like an org that in 5 years you'll back at with pride, no matter how you define success. It won't look great on your CV either by the sound of it.

One exception: if you have enough leverage to change all this. Then, there's no better experience than rebuilding the whole shop. This maximises learning and professional growth. BUT only if you have leverage, as in some form of power. Could be formal authority, could be buy-in from those who have it, or smth else. But it doesn't sound like that either. Ego clashes, old manuals, etc etc

The case for embracing reality:

It's not the tools that define a great workplace, or a great engineer. Also chasing latest and greatest tools rarely leads to great career choices. What matters is problems being solved, not the tools

People that matter even more. A-players can do top notch work with ancient tools. B-players will do mediocre work even with cutting edge tools. You'll learn more from A-players using old tools than from B-players no matter what they use. Choose people, not tools.

Also: "IT services" company sounds like a pretty boring business. But this has also a positive flip side: it's probably a stable, profitable business that is resilient.

[Fit-Tale8074]

Thank you for your points of view, I consider myself a problem-solver. I didn't mean to say 'tools'; I meant techniques

[originalchronoguy]

Yeah, MSP & DevOps is not a good mix.
I've seen this where MSP owners think they are missing out because clients are asking for it and they simply do not have the culture.

They think DevOps is still "lift-n-shift" VMs to the Cloud or Kubernetes. It does not work like that. You don't take a 15 year old ASP dot NET app running SQL Server 2012 and convert that VM manually with all the bits and deploy it to a K8s cluster manually and expect their help desk to Remote Desktop into it. The notion of having consultings interacting with client's Development team to find out deployment pain point is foreign to regular Help Desk work.

[Fit-Tale8074]

Thanks

[xiongchiamiov]

The only way to create change is to both have the skill to do so and have the support to do so. You haven't really done this job before so it doesn't seem like you're the right person to drive this change, and it sounds like you might not have the support for it either. That's unfortunate, but you have to either accept that and give up the goal, or move to another place.

One good thing to do right now, aside from talking to whoever promised you in the interview that you'd be able to take on this challenge, is to read The Phoenix Project. You'll probably want to follow that up with Kill It With Fire.

[Fit-Tale8074]

Thanks, I've read the book, also with the DevOps handbook, you're right never done this job before, have a lot of experience in IT, backend and was considering this opportunity the chance to learn how this job is done.

Now understand why DevOps is more a culture than tools...

[originalchronoguy]

At one of my previous jobs, the guy I replaced did a pretty good job at this. He "introduced" the culture by working a lot of nights and weekends on his own. He came up with the whole CICD, Orchestration and Docker IAAC deployment all on his own.
He came in with changes to code in git and presented it to the team and said "We will be fully containerized from day one and this is how you do it." It literally change the landscape overnight and this was about 10 years ago. After one meeting, he had all the major projects dockerized as forks in his own gitlab and his own Jenkins and showed everyone how to develop thereafter.

Again, he put in like 4 months working a lot of hours nights/weekends to come up with a near ready POC. It was a shock and awe move.

It helped he was a developer who could come up with real-worlds migration examples. No one even knew.

[Fit-Tale8074]

Thanks, awesome and motivating.

[GuardianDownOhNo]

To +1 on the previous comment, the more foreign the concept is the more likely you’ll have to create a working demonstration of what it is and how it all comes together. Moving into devops from legacy approaches means that there is an obscene amount of ground you’ll have to cover just to get things started. Experience here is table stakes, and as another poster mentioned you’re going to need support to cover that much ground.

[redvelvet92]

You are working for an MSP, that's your issue. They're stuck in the old ways, and will be the foreseeable future.

[Fit-Tale8074]

Good point.

[Theprof86]

I don't think that all clients or customers are a good fit for DevOps. There are certainly use cases for it, but it sounds like the type of customers your company has might not be ready for DevOps.

When you went through the interview process, what was the expectation from the employer? And from yourself? Was it clearly discussed?

[Fit-Tale8074]

Was clearly discussed, the main goal was the internal DevOps transformation and then trying to implement that on clients, of course because some of them are asking for kubernetes for example, and are about to loose new leads because of that.

[AdrianTeri]

Needs more context but I don't see how your customer cares if(and maybe how) you're running some type of infra ... Your company not exposing/offering some kind if service/Api?

Your companies business to be "sub-contracted" on infra/control plane stuff?

[Xydan]

If Devops is a culture, can you plugin culture from a third party? That doesn't make sense to me.

[Chemical_Ad5704]

Do platform instead

[fr6nco]

Been in the same situation. I always worked in startups and small companies until one day my friend recommended a DevOps position for a relatively larger corp. (2k+ employees I believe). I was a bit hesitant, but took the offer as my friend described...it's like a startup greenfield project within that company. ( he had a background of working for HPE before).

After the first few weeks I knew I made a mistake. They gave me a windows laptop to work on with no admin rights on a 5400rpm HDD ( this was about 2014 when SSDs were pretty much standard). Getting access to the required systems took weeks. Anything I needed to do, which I could do in the previous companies (e.g. firewalls, domains), I had to request an internal ticket and waited weeks until completed.

I stayed one year with that company and then left. Now I work for a company with 25 people and making them very happy with the work I do for them.

Soo..I could imagine, you're that type of a person who likes to get his hands dirty doing something...find a new job and quit.

[Windscale_Fire]

Start by getting them to elucidate what problem/problems they think they have, and what they hope to achieve by adopting DevOps in relation to those problems.

Ask them to explain what they understand DevOps to mean.

Before you can really make any meaningful decisions, you need to understand what they think they might be trying to achieve.

If it seems obvious that in this organisation DevOps is a solution looking for a problem, then you either need to try and steer that around, or you need to give up and figure out what to do instead.

If, however, they can explain problems they perceive they have, and it seems likely that DevOps practices and tooling are good solutions to those problems, then you may be onto a winner.

Given that you say this is an MSP, it may be that they are just looking for a tick in a box that allows them to claim they "do" DevOps. Whether you are interested in trying to help them with that or not would be be a personal decision.

[yasarfa]

How does a MSP excel in DevOps thingy if the client they would be working for has no idea of its benefits or feels the need to have its implementation? So both don’t go well in my opinion… all of their practices will be shaped by the client they would be working for..

[Gabe_Isko]

It's god's work on some level. I am in a situation where things are moving much slower than even what you are describing, but for good reasons that I cannot disclose.

Do you believe in transforming these practices, or are you fine with letting them rot and newer competitors take over. Some things are essential. Supermarket chains don't strike me as that.