I spent 5 years in DevOps – Solutions engineering gave me what I was missing

I too am working on my out of the country back up plan. My wife and I are going to one of those countries for 5 weeks in a couple of weeks. We have already looked into residency requirements as a Plan B.

I am just starting to get a peek under the cover for sales. If I understand it correctly.

- “Someone” is hustling to make first contact with the customer or if you are a partner of one of the cloud providers, they send customers your way. I have no clue how this part works.

- The SA talks to the potential client enough to get high level business requirements to shape the contract. I’m not an SA. But there is a certain AWS speciality where I’m usually pulled in at this phase. We are trying to build expertise around this specialty. My former mentee is an SA at AWS so I know how they operate.

- After the contract is designed, I work with sales to understand the opportunity and I am the first person that does a deep requirement analysis - the business case is known, the technical requirements are ambiguous. I am responsible for getting the requirements and doing the design, talking to the technical guys, finance, security and the business folks to make sure their needs are met.

- then I lead the project, before AI, I would have needed a couple of people on the project. Now I can do it myself most of the time. It was never lack of knowledge, there are only so much I can do myself.

To your second question, the last 2016-2024 when I set on this path is a lot different than it is now.

I guess the best way is to work backwards from where you want to be to where you are.

1. How often do you know the business requirements in advance compared to how often are they given to you?

2. The money and the opportunities are in leading migrations. There are very few decent paying hands on keyboard “doers” those are easy to outsource. I lucked up that I got my job in a division that does care about “developers who know cloud and can lead implementations”

3. How are your project management skills? The ugly truth is PMs are useless when it comes to tech projects, you are the one that has to have the proper context to know dependencies, how to break things down, critical paths, etc.

4. Have you led implementations larger than what you can do yourself? Hands on keyboard folks are a dime a dozen and companies can pay them a fifth of what they pay you.

5. How are your presentation and communication skills? Can you explain what you did to someone non technical but knows their business, sonríe who understands technology but not what you did and someone who knows the technology and wants to know why you made the decisions you made?

6. Do you have experience juggling conflicting stakeholder agreements

7. How is both your small talk and business speak - “adding on to what Becky said”, “finding alignment”, “a single pane of glass”, “taking things to the parking lot”, “we aren’t solutioning yet, let’s talk about your business opportunities and challenges “?

upon remembering, it was actually just Token Auth - for some reason, when i created a machine identity in my parent organization, tbe CLI would always return a 403 for any project ID, regardless of whether i gave the identity the adequate permissions.

i got around it by just generating an identity for each project, which was probably a better idea anyway for granularity

>BTW: I am “expert” in cloud by any definition (did at a startup, worked at AWS ProServe, staff consultant at a 3rd party consulting company) and I develop. How hard do you really think it is for someone with a developer mindset to learn how system design works at scale and bring their same developer mindset to infrastructure as code?

It depends! Do you mean clicking in the AWS console and spinning up infrastructure? It takes a few days.

Learning terraform/CloudFormation so it's repeatable? Probably a few weeks.

Kubernetes design patterns and troubleshooting? I feel like it takes at least a few months of hands on and theoretical.

To build infrastructure that lasts, is monitored with an APM as well as infrastructure specific tooling (not Cloudwatch) has cost dashboards set up to account for workloads across a dozen product lines (not Cost Explorer), has a CI CD pipeline automation for hundreds of repos including automatic onboarding of new ones, understands cloud security enough to have designed a tight perimeter with some automation around detection and remediation, has strong network level knowledge and knows how to deal with external vendor/client connectivity options (since you have to adapt to their limitations or demands)... Instead of server babysitting, you know in advance how to prepare the inevitable situation where workloads need to scale, and already have tooling and horizontal and vertical auto scaling either automated or ready to go...

If you know these things after 2.5 years, and I say this fully seriously, you are in some sort of .5 percent elite in this industry and deserve something like 1M a year, or you should be leading something huge.

Otherwise there's a risk here that you don't know what you don't know, which was my original point about over confidence by software engineers when it comes to infrastructure.

But if they never say no, how do you maintain central infrastructure standards?

If you say yes all the time, I feel like that's how you turn devops into Ops monkeys who are reactive, since people are operating on Sprint timelines instead of optimizing for long-term stability.

I'm with you on the avoiding tedium, on-call and monitoring and overall Operations pieces of it.

There's an infrastructure creation aspect where you're creating automation systems and passing it along for others to maintain. I personally think that's a sweet spot.

Everything you said here I relate to, it seemed like you were arguing that infrastructure design and systems engineering is just "app dev ++" as opposed to a collection of skill sets that take years to learn.

It's no different than AI slop if someone thinks cloud automation is just another programming framework to learn. I've worked exactly in 0 companies that got it right when it came to intelligently designed, bullet proof systems. Some of the slop and chaos is so bad it takes big new projects and smarter hires to repair it.