From the "how it should properly work"/"how it was meant" perspective there is no real "DevOps engineer" because DevOps is a methodology/culture which emphasizes also on technical practices which should stretch across as many roles as possible and feasible.
How can we apply the CALMS (Culture, Automation, Lean, Measure, Share) mantra here? (Taking into approach that depending on factors like maturity, complexity and resources in the context, approaches need to be adapted to what helps to solve problems in an efficient and sustainable way)
- Requirements engineer: can I automatically qualify maturity of requirements and track their delivery?
- Software engineer: what is required to run my software in test either productive environment?
- Architect: can I have a big picture based on live metrics?
- Tester: can I create virtual temporary infrastructure to support execution of my code?
- System administrator: how can I better organize my help desk / 1st user support and leverage self-help / automation solutions?
Somebody with a wish to focus on the methodology itself will be somewhere in-between all these guys and obviously become "jack of all trades, master of none".
Given this, my consideration how I would approach your customers' inquiries could be:
- Please follow the instructions to setup VPN in this Wiki/code from this Git repo and if it's not working, document/show steps you have taken.
- Please share more details on the context (here is not clear who owns which parts).
- Let's allocate time to develop emergency plan for immediate action if required and also run scaling tests on a test system to model experiments, collect data and finally learn under which circumstances the performance problems appear. Then, we will know why it is happening. :-)
- Follow from 3.? What does mean schedule from your perspective and if you mean regular execution, how often? So please let's go back to previous item :-)
Possibly, have you got more specs which infrastructure option (Cloud, on premises) should we use for that and what and what are you going to do? Here is a link to generic infrastructure planner, let's allocate time to discuss what is specific for Spark/Hadoop here and how will delivery to it look like.
If identity management is not part of our architecture, let's assess what are you going to do. An outcome could be that you include creation of users to your database scripts.
So the bottom line in DevOps culture regarding the role boundary is:
- professional communication first
- the boundary is to set boundaries inviting people to a professional conversation between adults, to get more conscious on both sides (!) about requirements, responsibilities and goals. Not just thinking in solutions and delegation but also make a plan and assess risks.
Therefore seasoned and successful professionals who are today maybe 50+ yrs old say sometimes jokingly "we have been doing DevOps from the very beginning" and partly, they are right.
To conclude and highlight and reflect on the real-world existence of such job-role, organizations who do not have a DevOps culture proceed to define DevOps roles as the following, for example:
- DevOps engineer is an advanced systems administrator who can code up the infrastructure and automate it completely.
- DevOps engineer is a tools administrator with coding skills to support the Dev team and ensure delivery towards production (CI/CD, deployment scripting but also Jira administration)
- DevOps engineer is a developer focusing on including infrastructure elements into development, like containers and cloud APIs.
After all, many companies still look for the "full stack engineer" who should obviously become additionally the DevOps engineer (along with "AI/ML, blockchain and foobar").
Finally, the role boundary, possibly not only in the DevOps context, but in this special context indeed very likely:
- is also in your responsibility
- may change between projects and employers or just from time to time.
