What is the utility of an inhouse DevOps if cloud providers already provide professional services?

Question

I've seen this in past roles when I was working a devops role as an employee.

What should be the purpose of an inhouse devops in a company that already pays for something like AWS Professional Services, in other words, the cloud provider has teams of engineers who are deployed on-prem to solve business needs, put together an infrastructure, and at the same time promote various AWS services to the client.

Where does the inhouse devops fit in this picture?

I remember some years ago I was in a remote meeting, solved a task, only to be told by my manager "okay, we'll give this to our consultant anyway". Not only was the remark awkward because the entire team was in the meeting, but I also don't see what the point of doing the task was in the first place if someone else would've been assigned to do it.

Does it make sense to take on a devops role if it's not for a cloud provider?

Answer 1

Some good reasons could be:

• The salary of an inhouse devops is pretty sure less expensive as the consultants.
• The consultants are only assigned during a limited period, to temporary add (wo)manpower, e.g. while putting together the infrastructure.
• The consultants come with specific expertise that the inhouse devops do not (yet) have, whereas part of the job of the consultants is to perform knowledge transfer and/or on the job training for the inhouse devops.
• The consultants are there to do the boring parts of the work, whereas the inhouse devops are assigned to the strategic / long term tasks (so that when the consultants leave, the know how doesn’t leave the company also.

BTW, IMO the best consultants are those who:

• Say their jobdescription is like “My job is to make sure that you don’t need me anymore ...”.
• Never touch the keyboard, and instead always coach / help inhouse devops to have them complete any task (it seems so easy when you see somebody else complete some task, but it is way more difficult to complete it yourself).

Answer 2

Coming from the DevOps consulting background, on top of what @pierre.vriens has mentioned,

1. Consultants don't have any skin in the game and should not be in charge of leading your DevOps strategy in the long run. You need to have the in-house expertise to lead major initiatives. Do high-value work yourself and hire consultants to deliver well-scoped and solved problems.

2. My team provided support for Kubernetes and Azure-related DevOps services. Most of the time, what we built was complicated, and our customers were not ready to maintain or support what was delivered. We spent a good amount of time doing knowledge transfers, but it quickly became overwhelming without a good in-house team.

3. I would not recommend hiring DevOps consultants to coach only. I have done coaching and hands-off engagements and I believe that the customers did not get the full worth of their money. You should embed consultants in your team and train your team by doing stuff side-by-side. Part coaching and part delivery of the actual work.

4. In most cases, cloud vendors work with existing consultants in their network and rebrand them as "their" team. You still need a good amount of technical knowledge and leadership to get the most out of any consultant.

Answer 3

Ownership.

It's fine to pay a second party, or even a third party to provide the support that you need but at the end of the day there is a large distance between not owning the hardware and not owning the human effort.

Developer years of effort that are owned by a company are valuable. It exists in the human space and it manifests in knowledge transfer and familiarity with the product. Effectively, engineers are an investment.

There's an old story about an engineer turned consultant who gets called into an ex-employer to fix a problem. After 30 seconds and a rubber mallet the ex-employer received a bill for an exorbitant amount and promptly asks what the cost was. The engineer in this case points to the decades of experience that enabled (him/her/them) to fix the problem in 30 seconds.

On top of this, the history of enterprise software has made many heads in the software space paranoid that prices can increase after being locked in. This is why there are such big pushes for multi-cloud, or cloud-agnostic infrastructures. Avoiding your engineers being owned by your cloud provider is a good way to avoid that, while on the other side of the coin cloud providers have solid reasons to want to lock you in. They buy the hardware after all. They do the provisioning.

On top of all this, you can guarantee that your inhouse devops only works on your product, and won't leave (without notice-- I hope), and won't be working on other products.

I cannot comment on the specific case mentioned in the original question, as I don't know the nature of the relationship between your company and the consultant.