Roles and Responsibilities of Cloud Native DevOps Engineers
Cloud Native DevOps is a relatively new collection of old concepts and ideas that coalesced out of a need to address inadequacies in the “old” way of building applications. To understand what Cloud Native DevOps engineers do on a daily basis, one needs to understand that the objective of the Cloud Native model is to build apps that take advantage of the adaptability and resiliency that are so easy to achieve using cloud tools. There are four main concepts that serve as the basis of cloud native computing: Microservices, Containers, CI/CD, and DevOps.
Microservices is an approach to developing an app as a collection of small, purpose-built services that come together to form a complete product. These features are packaged into containers like Docker and then pushed through a continuous integration/continuous deployment pipeline. The modularity of microservices enables different teams to work in parallel on different parts of the product without interfering with each other, and it also strengthens the product by lessening the impact of the failure of any of these services on the others.
Using containers to host microservices is extremely efficient because containers use system resources more efficiently than traditional virtual machines. They only need to run the services relevant to the apps they host, as opposed to an entire guest operating system and its corresponding processes. Containers are essential to the agile deployability of Cloud Native apps, especially when paired with management software like Kubernetes. All of this is the foundation that makes CI/CD possible. Without the flexibility afforded by these tools, the CI pipeline that allows a change, fix, or feature to go into production from development through automated code review and testing would be extremely difficult.
DevOps uses all of these tools and more to solve the problem of silos — that is, the issue of what happens when developers write code and then throw it over the wall to the Ops department. The results of developers not owning their code from start to finish are that the operations department is often left responsible for maintaining code that has not been written with the infrastructure in mind. The solution here is not to just create a third silo combining the developments and operations roles.
DevOps is not just a process or a job posting, it’s a culture of ownership.
DevOps engineers try to cultivate a philosophy of “YOU built it, so YOU run it”, which means they need to evaluate the possible bottlenecks that could plague the app in production from the very beginning of the software development process. A Cloud Native DevOps engineer needs to be able to take an app through a CI/CD process that ensures the code can be built, pass tests, and deploy with minimal to no disruption to the production environment. This encourages them to think of how the app will run before it is created, and they write scripts to create continuous integration pipelines that guarantee faster time-to-market for the products and positive user experience.
The best DevOps engineers will have the ability to use or learn a wide variety of open-source technologies and are comfortable with programming languages that are heavily used for scripting. They have some experience with IT systems and operations and data management and are able to integrate that knowledge into the CI/CD model of development. Crucially, DevOps engineers also need to have their sights set not just on writing code, but on the actual business outcomes from the product they develop. Big-picture thinking like that also requires strong soft skills to enable communication across teams and between the client and the technical team.
Of course, no person is an island. DevOps teams operate under the same umbrella but need distinct roles to work. The actual titles of these team members may change from place to place, but the general responsibilities remain the same:
- Product owner (responsible for what the team works on) — This person serves as the client-team liaison. They need particularly strong soft skills and the ability to effectively communicate technical concepts in order to work with the client to come up with a product that meets expectations. They know the big picture and can tell the team how the app should run and what infrastructure to use.
- Team lead (responsible for how the team works) — This person is a managerial type for the technical team. They delegate responsibilities based on team members’ individual strengths and skill sets. They also contribute to the code, but they keep the team on track with the Product owner’s big picture in the shorter-term context of development sprints. They generally have final say on technical decisions.
- Automation architect/Site Reliability Engineer — This person is experienced in building cloud infrastructure and understands what’s needed to support the app in production. They develop automated systems to keep things in continuous deployment running smoothly. They specialize in ensuring the stable performance of the infrastructure in a large-scale setting, and know how to scale that infrastructure as the company grows.
- Software developer — The software developer will work with all of the previously listed team members and with the requirements set by the client to produce code that they then test, deploy, and monitor.
As the team grows, these roles may separate out into several other more fine-grained positions so as to take advantage of the increased manpower. UX engineer, Test engineer, and Security engineer are some examples that would take important responsibilities from some of the others listed and expand on them.
Thanks to the Holberton School of Software Engineering, which connected The New Stack to author Essence Boayue.