Traditionally, system administrators have been responsible for designing, implementing, and managing hardware and underlying operating systems. However, advances in edge computing, machine learning (ML), and intelligent applications have broadened sysadmins' scope of work and skillset required for software development projects.
[ Download now: A system administrator's guide to IT automation. ]
This article explores five things sysadmins should know about software development.
1. Communication is key
Communication between teams is key to success, and it begins by asking the right questions from the start.
In a typical software development project, there are many players: architects, data engineers, data scientists, ML engineers, software engineers, front-end developers, and of course, sysadmins. Because of how specialized these roles are, it can be challenging to communicate across teams. For this reason, all teams responsible for an end-to-end project should participate in the discovery and planning phase, including IT professionals and system administrators.
Asking the right questions to the right people is critical to meeting environment, security, and hardware requirements. Here are some ideas about what to ask the participants:
- Data engineers: Ask about the nature of their queries. For example, how many terabytes of data will be stored, processed, and pulled?
- Software engineers: Find out which libraries and packages will be used. What languages will they be coding in (Kotlin/Swift, Java, C)?
- Data scientists: Will the app involve machine learning models? If so, what hardware is required to run and train the models? Ask whether graphics processing units (GPUs) are needed. Find out what programming language their models are coded in—for example, are they using Python, Scala, or R? What libraries are required to run the code? It would also be beneficial to know if any technologies will be included, such as Tecton, Seldon, or Kubeflow.
- All participants: Finally, it is critical to discern which security policies are required for different users. Who will need to access the database with a read-only policy? What about read-write? Which users will require access to environments or other platforms for this project?
Record the answers to these questions in the software development plan.
[ Free cheat sheet: IT job interview tips. ]
2. Set expectations
Set infrastructure and hardware expectations as soon as possible to avoid conflicts down the road.
In some cases, developers depend on sysadmins to explain security policies, hardware limitations, and what resources are available to them. For example:
- Are too many people requesting access to an environment unnecessarily?
- Do the project's memory or storage requirements surpass what can realistically be provided?
- Can some of the redundant data tables or views be consolidated?
Challenge the requests, describe why they may be problematic from an IT perspective, and provide an alternative solution. The sooner the development team is on board with your goals on the hardware and security side, the less likely you will be butting heads with them later.
[ Download now: Git cheat sheet. ]
3. Expect deviations
As development progresses, application requirements and staffing changes will alter the initial software development plan. You may have to return to previous discussions about hardware requirements, security permissions (including adding new users and changing access), and adding libraries to environments. While sticking to the original scope is essential, there must be some wiggle room for adaptability and flexibility in software development projects.
4. Prepare to manage many dev environments
You may be responsible for more development environments than you initially expected. Development environments refer to the isolated workspace developers use when making changes to the code without affecting the live application. When environments are not identical across machines, it leads to bugs, inconsistent app behavior, and infamously irritating "Well, it worked on my machine…" conversations.
It is best practice to maintain isolated environments by logging into a remote managed environment or using virtual environments. For example, Python's project and package managers are virtualenv and pip. You can specify the packages needed in the environment using a requirements.txt file and then create the development environment on a local or remote terminal. Keep in mind that development environments can also be containerized using Podman.
[ Download the Podman basics cheat sheet. ]
You may install more libraries or packages than you anticipated, especially if you manage environments on a cloud platform such as AWS. In addition to maintaining identical development environments, it is also critical to use a versioning tool such as DVC or Git to keep track of modifications to the codebase and who made them.
5. Use similar tools
Developers appreciate it when sysadmins go out of their way to learn about their tools. You may be surprised to learn that developers use many of the same tools and techniques sysadmins use. For instance, many scripting languages such as Python and Perl are used as the codebase for ML models and data-processing pipelines. Data engineers and web developers use Linux commands to transform data (tr, paste) and test connections between servers (ping, curl). The more knowledgeable you are about their tools, the more developers will care about respecting security policies and the underlying hardware.
Wrap up
Sysadmins are essential to the success of the software development process, and the nature of the role is constantly evolving. Be aware of new technologies and tools incorporated in software development pipelines. Take a look at the Red Hat Developer's Blog to stay in the loop. You can also search trending or starred projects on GitHub to find new tools, languages, and applications for your benefit and that of your developers. Also, read The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations by Gene Kim, which I referred to when writing this article.
[ Download now: A sysadmin's guide to Bash scripting. ]
Thanks to Stephen Wilson, Chris Kang, and Trevor Royer for their insight!
