While PaaS (Platform as a Service) solutions themselves may not directly change the ways individuals and teams interact, they often act as a catalyst for organizational change in response to the increased flexibility of IT technologies.
In practice, maximum return on investment in PaaS is often possible only if organizational roles, responsibilities, and relationships change. Fortunately, PaaS solutions like OpenShift Container Platform are flexible enough for each IT organization to determine the pace and scope of change concerning the people involved and the processes taking place.
In the initial phase of enterprise containerization, the main priority is to implement a container platform as a new application deployment system. At this stage, organizations align familiar tasks with established roles to respond to standard requests from development teams regarding storage systems, deployment environments, and so on. In subsequent phases of containerization, automation or providing self-service capabilities to developers is discussed to lessen the burden on system administrators and elevate developer autonomy and responsiveness. This is how an organization begins to move towards DevOps. In the final stage of enterprise containerization, a cleaner, canonical DevOps model emerges, where many previous tasks and activities are taken over by cross-functional teams that are grouped not by platforms or technologies, but by ensuring the operation of applications or application services.
In this post, we will present a guide to implementing the necessary organizational changes and discuss how traditional IT roles evolve with the adoption of container technologies in the enterprise.
Aligning new tasks with old roles
In its basic, initial form, the PaaS organizational model is formed to more flexibly and quickly allocate IT resources to applications as a runtime environment. While this provides certain advantages to system administrators, developers typically do not gain any substantial benefits or new capabilities at this stage, as the enterprise can quite well manage without starting automation, introducing self-service, or radically improving the deployment pipeline. By minimally impacting development processes at this stage, PaaS nonetheless increases the dynamism of the IT system, allowing administrators to better serve developers' requests. For example, if creating a development environment from several of virtual machines and storage volumes used to take days or even weeks, requiring the involvement of several different administrators, in PaaS everything is done much faster and by just one administrator. In other words, development teams submit requests as before, but the implementation of these requests is now performed according to a new scheme.
On the way to a DevOps organization
By launching PaaS and transitioning IT operations specialists and application developers to it, the organization can continue the implementation of the DevOps methodology, which includes the following core principles, among others:
- Breaking work into smaller stages, to obtain feedback at early stages, reduce risks, and avoid 'analysis paralysis';
- Automate operations sufficiently, to avoid creating obstacles or bottlenecks in the application deployment process;
- Knowledge sharing is the key to building trust;
- Regularly paying technical debts, allocating a specific amount of time for systematic improvements in each work cycle.
During the second stage of implementing container technologies, development teams naturally begin to see opportunities for improvements, and the enterprise leans towards a more canonical DevOps model. The traditional mechanism of submitting and executing service requests is now seen as a bottleneck, prompting the organization to seek automation of repetitive tasks and provide developers with self-service capabilities. Moreover, these developer capabilities within a given request are defined collaboratively by IT operations specialists and those responsible for application delivery. In other words, instead of system administrators handling developer requests, two aforementioned categories of staff take over, responsible for defining and enforcing policies that regulate what developers are allowed to do on their own. Automated procedures help ensure compliance with these requirements and coordinate actions when situations fall outside of existing policies.
Transitioning to an iterative schedule, where the IT environment and operational model undergo iterative changes over time, is a critical milestone in establishing a mature DevOps system within the enterprise. The degree of adoption of the DevOps methodology depends on each organization's tolerance for change and which specific changes yield the most significant benefits. For instance, if the need to create new environments or applications arises infrequently, optimizing these actions becomes less important than enhancing developers' control over the application lifecycle.
New challenges that IT organizations face when transitioning to OpenShift
In this section, we will explore the roles and tasks that organizations transitioning to OpenShift typically implement to accelerate automation and self-service using technologies and PaaS.
The table below lists the main high-level tasks that exist in any organization implementing OpenShift, along with examples of relevant work and skills. This list of tasks should not be confused with a work breakdown structure or team organizational structure; it is merely a set of tasks that must be completed by those responsible for supporting IT environments to successfully implement the container platform. In fact, we will show that the implementation of container technologies creates the groundwork for a more mature DevOps strategy within the enterprise, which in turn enhances the cross-functionality of teams and reduces the risks of narrow specialization at both the individual and team levels.
Table 1. OpenShift Task Definitions
Since I have already learned to "somewhat" port QEMU to JavaScript, this time it was decided to do it wisely and not repeat past mistakes.
Required Skills
Automation and provisioning of IT infrastructures
Tasks:
- Designing and building hardware solutions
- Organizing and supporting automation of initial setup
- Designing and automating VM and host provisioning
- Designing and implementing data centers
- Linux system administration
- Automation scripts
- Knowledge of storage systems
- Knowledge in designing and implementing networks
- Security
Installing and managing the OpenShift platform
Tasks:
- Performing cluster installation
- Managing infrastructure services
- Managing platform scaling
- Authentication and authorization at the platform level
- Linux system administration
- Knowledge of networking technologies
- Automation scenarios (Ansible)
- Knowledge of storage systems
- Knowledge of container technologies and architectures
- Knowledge of Kubernetes and OpenShift architectures
- Platform security
- Integration of monitoring
Managing tenant provisioning and isolation with IT resources
Tasks:
- Creating users and teams within the platform
- Designing and managing quotas
- Designing and implementing RBAC
- Knowledge of Kubernetes and OpenShift architectures
- Knowledge of container technologies and architectures
- Automation scripts
- Strong knowledge of projects, quotas, role bindings, and working with schedulers
Building and managing base images
Tasks:
- Developing workflows for image changes
- Developing images according to standards
- Linux system administration
- Automation scripts
- Configuring runtime components of applications and middleware
- Knowledge of container architectures
- Application build frameworks
- Strong knowledge of images, imagestreams, and templates
Design and management of deployment pipelines
Tasks:
- Design and documentation of pipeline standards
- Development of brief guides and templates
- Training for developers
- Source code management
- Design and implementation of applications
- Automation scripts
- Automated testing
- Code quality testing
- Knowledge of container architectures
- Knowledge of immutable infrastructures
- Security – managing access to pipeline stages, workflow approvals, etc.
- Good knowledge of OpenShift templates, buildconfigs, deploymentconfigs, services, routes, configmaps
Application and test development
Tasks:
- Application coding
- Development of automated tests
- Responding to test failures during the deployment pipeline
- Responding to application outages
- User acceptance testing
- Design and implementation of applications
- Automated testing
- Source code management
- Application monitoring
- Knowledge of cloud-native application architectures
Operational monitoring and application management
Tasks:
- Application design in terms of performance
- Monitoring of applications in execution
- Application scaling (or auto-scaling)
- Managing application availability
- Request quotas and resource management limits
- Performance and IT capacity testing
- Designing and implementing application performance
- Monitoring application performance
- Performance testing and load testing
User acceptance testing
Tasks:
- UI testing (design and user interactions)
- Development of automated tests
- Design and evaluation of user interfaces
- Automated testing templates
- Testing frameworks
- Application design patterns
New roles emerging in IT organizations during the transition to OpenShift
As organizations transition to a DevOps-oriented model, the specialization of roles typically decreases while the number of cross-functional teams and roles increases to maximize collaboration efficiency. Here’s how we envision the list of key positions in an IT organization using OpenShift:
- Application Operations Engineer OR Site Reliability Engineer. This position may have previously been referred to as 'Application Server Administrator.'
- Application Developer / Software Developer / Programmer.
- Cluster/Application Platform Administrator. This role was previously known as 'System Administrator' or 'Linux Platform Administrator.'
- Software Release Manager / Build Engineer.
RACI Role and Task Matrix
Finally, we move on to matching the positions and tasks discussed above to provide an overview of how the organizational structure implementing DevOps on the OpenShift platform should look. The roles listed below may initially be performed by different branches of the old, traditional organizational structure. However, over time, consolidation occurs, leading to new teams built around applications that take on most, if not all, of the tasks mentioned below.
Since I have already learned to "somewhat" port QEMU to JavaScript, this time it was decided to do it wisely and not repeat past mistakes.
Roles
Application Reliability Engineer / Site Reliability Engineer
Application Developer / Software Developer / Programmer
Cluster/Application Platform Administrator
Software Release Manager / Build Engineer
Automation and provisioning of IT infrastructures
I
I
R/A
C
Installing and managing the OpenShift platform
C
I
R/A
C
Design and management of deployment pipelines
C
C
I
R/A
Management of tenant provisioning, isolation, and IT resources
C
I
R/A
I
Building and managing base images
R
C
R/A
C
Application and test development
C
R/A
I
I
Operational monitoring and application management
R/A
C
C
I
User acceptance testing
C
R
I
I
Symbols in the RACI matrix
Source:
- Responsible – Executor – the person who performs the necessary tasks to complete the job.
- Accountable – Accountable – the individual ultimately responsible for the correct and thorough execution of the task or achievement of results; and the only one who can delegate work to executors.
- Consulted – Consultants – typically experts in the subject matter whose advice is sought; they maintain two-way communication.
- Informed – Informed – individuals who are kept up to date on developments (sometimes only after the task is completed or results are achieved); they receive information in a one-way manner.
How teams collaborate in a DevOps organization
The traditional resource acquisition model typically consists of a cycle of requests for resource allocation, which are then carried out by multiple teams. Ultimately, all necessary resources are allocated and confirmed by the requesting party. Often, these processes are carried out partially or fully manually and require frequent and numerous interactions between teams to successfully process each request.
Figure 1. Traditional IT Organization
The diagram above illustrates typical relationships between teams in a traditional IT organization. Within this model, some teams reach out to other teams with requests for necessary work, using more or less formalized communication tools, such as ticketing systems or email. These requests are then placed in a queue and await their turn, with long wait times often leading to deterioration or even escalation of relationships between teams. The tension is further exacerbated by the fact that members of different teams rarely meet in person and typically share only the minimally required information.
Figure 2. DevOps IT Organization
This diagram illustrates how collaborative work is structured within a DevOps organization. Here, the same teams from the previous diagram have moved away from ineffective communication methods that increased fragmentation, replacing them with personal contacts to create continuous interaction channels between teams. These channels foster the development of a hybrid skill set, helping employees better understand and represent the needs, challenges, and opportunities of the teams they serve. Teams enable one another to perform necessary tasks through automated self-service portals instead of manually processing change requests as was done previously. Thanks to the presence of interaction channels, these self-service systems can quickly adapt to the needs of the teams for which they are designed. To achieve even greater mutual understanding and knowledge sharing within the organization, team members periodically rotate roles to gain experience working with different teams and to better grasp the overall landscape of the IT systems they support, thereby enhancing their level of cross-functionality and usefulness.
In summary
In this post, we discussed how the adoption of PaaS solutions can encourage an organization to implement DevOps methodologies, noting that this process involves changes to traditional roles and tasks. Therefore, we listed the main IT tasks that arise in an organization transitioning to OpenShift, as well as the skills required to perform them. We also provided a core set of organizational roles that emerge when forming cross-functional DevOps teams, along with a RACI matrix linking new roles to new tasks. Finally, we explained how the OpenShift platform and its associated DevOps methodology can transform an organization's structure by shifting from traditional hierarchies and ticketing systems to cross-functional teams with greater levels of personal communication.
Source: habr.com
