In fact, the maximum return on investment in PaaS is often possible only if the organizational roles, responsibilities (tasks) and relationships are changed. Fortunately, PaaS solutions, such as the OpenShift Container Platform, are flexible enough so that each IT organization can independently determine the speed and extent of change relative to the people involved and the processes that take place.
At the first stage of enterprise containerization, the main priority is the implementation of the container platform as a new application deployment system. At this point, organizations tie familiar jobs to familiar roles in order to respond to standard requests from development teams in issues such as storage systems, deployment environments, and more. At the subsequent stages of containerization, we are already talking about automation or providing developers with self-service capabilities in order to reduce the burden on system administrators and bring the autonomy and efficiency of developers to a higher level. This is how the organization begins to move towards DevOps. At the final stage of containerization, the company comes to a cleaner, canonical DevOps model, in which many of the previous tasks and work come under the control of cross-functional teams, which are grouped not on the basis of platforms or technologies, but from the point of view of ensuring the operation of applications or application services .
In this post, we will provide guidance on the necessary organizational changes and tell you how traditional IT roles are changing with the introduction of container technology at the enterprise.
Linking New Jobs to Old Roles
In its basic, initial form, the PaaS organizational model is formed in order to more flexibly and efficiently allocate IT resources to applications as a runtime environment. And although this gives certain advantages to system administrators, the developers here, as a rule, do not receive any significant benefits and new opportunities, since at this stage the enterprise may well do without starting automation, introducing self-service or radically improving the deployment pipeline. Minimally affecting the development processes at this stage, PaaS nevertheless increases the dynamism of the IT system, which allows administrators to better serve developers’ requests. For example, if earlier it took days or even weeks to create a development environment from several virtual machines and storage volumes, and several different administrators were required, then in PaaS everything is done much faster and only by one administrator. In other words, the development teams submit applications as before, but the work on the implementation of these applications is already being carried out according to the new scheme.
Towards a DevOps Organization
By launching PaaS and transferring IT system operation specialists and application developers to it, the organization can continue to implement the DevOps methodology, which, among others, includes the following basic principles:
- Break work into small stagesin order to get early feedback, reduce risks and avoid “analytical paralysis”;
- Automate operations sufficientlyso as not to create obstacles or bottlenecks in the process of application deployment;
- Knowledge Exchange – the key to building trust;
- Regularly pay technically debts, allocating in each cycle of work a certain time for systematic improvements.
At the second stage of implementing container technology, development teams naturally begin to see opportunities for improvement, and the company is leaning towards a more canonical DevOps model. The traditional mechanism for submitting and executing service requests is now perceived as a bottleneck, so the organization seeks to automate repetitive actions and provide developers with self-service capabilities. Moreover, these capabilities of developers within the framework of a particular application are determined by the joint efforts of IT specialists in the operation of platforms and those who are responsible for delivering applications. In other words, the system administrators performing actions at the request of developers are being replaced by the two above categories of employees who are responsible for the description and application of policies governing what developers are allowed to do on their own. Automated procedures help ensure compliance with these requirements and coordinate actions in cases where the situation is outside the scope of existing policies.
Switching to an iterative schedule in which the IT environment and operating model undergoes iterative changes over time is a critical milestone in terms of building a mature DevOps system in the enterprise. The degree of adoption of the DevOps methodology depends on the tolerance of each particular organization to change and on which changes are most beneficial. For example, if the need to create new environments or applications arises infrequently, then optimizing the appropriate actions will be less important than strengthening the control of developers over the application life cycle.
New challenges that IT organizations face when moving to OpenShift
In this section, we will look at the roles and tasks that organizations that switched to OpenShift typically use to accelerate automation and self-service using technology and PaaS.
The table below lists the main tasks of the top level that exist in any organization that has implemented OpenShift, with examples of relevant work and skills. This list of tasks should not be confused with the work sharing scheme or the organizational structure of teams, this is just a set of tasks that must be closed by those responsible for supporting the IT environment (s) for the successful implementation of the container platform. In fact, we will show later that the implementation of container technologies creates the prerequisites for the formation of a more mature DevOps strategy at the enterprise, which in turn increases the degree of cross-functionality of teams and reduces the risks of narrow specialization at the level of both individual employees and teams.
Table 1. OpenShift task definitions
|Automation and provisioning of IT infrastructures|
|Installing and managing the OpenShift platform|
|Management of tenant provisioning, IT isolation|
|Build and manage basic images|
|Design and manage deployment pipelines|
|Application and test development|
|Operational monitoring and application management|
|Custom Acceptance Testing|
New roles that arise in IT organizations when migrating to OpenShift
As you move to a DevOps-based organizational model, the number of role specialization tends to decrease, and the number of cross-functional teams and roles in turn grows to maximize collaboration. Here, in our opinion, is the list of key positions in an IT organization using OpenShift:
- Application Operations Engineer OR Site Reliability Engineer. Previously, this position could be called “Application Server Administrator”.
- Application Developer / Software Developer / Software Engineer.
- Cluster / Application Platform Administrator. Previously, this role could be called “System Administrator” or “Linux Platform Administrator.”
- Software Release Manager / Build Engineer.
RACI Role and Task Matrix
Finally, we move on to comparing the positions and tasks discussed above to give a general idea of what the structure of an organization implementing DevOps on the OpenShift platform should look like. Initially, the following roles can be performed by different branches of the old, traditional organizational structure. But over time, consolidations take place and new teams are built around applications that lock onto most or even all of the tasks below.
|Application Operations Engineer / Site Reliability Engineer||Application Developer / Software Developer / Software Engineer||Cluster / Application Platform Administrator||Software Release Manager / Assembly 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 manage deployment pipelines||C||C||I||R / a|
|Manage tenant provisioning, isolation, and IT capabilities||C||I||R / a||I|
|Build and manage basic 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|
|Custom Acceptance Testing||C||R||I||I|
Conventions in the RACI Matrix
A source: Wikipedia
- Responsible – A contractor is one who does what is necessary to complete a task.
- Accountable – Responsible – an employee who is ultimately responsible for the correct and thorough implementation of a task or achievement of a result; and also the only one who can delegate work to performers.
- Consulted – Consultants – as a rule, these are experts in the subject area whose advice is requested; two-way communication is supported with them.
- Informed – Informable – people who are kept informed of events (and, sometimes, only upon completion of a task or achievement of a result); they receive information unilaterally.
How teams work together in a DevOps organization
The traditional scheme for obtaining resources, as a rule, is a series of requests for allocation of resources, which are then executed by several commands. Ultimately, all necessary resources are allocated and confirmed by the requester. Often these processes are partially or even completely carried out manually and require frequent and numerous interactions between teams to successfully process each request.
Figure 1. Traditional IT organization
The diagram above illustrates the typical relationships between teams in a traditional IT organization. Under this scheme, some teams turn to other teams with a request to perform the necessary work using more or less formalized means of communication, such as a ticket system or e-mail. Then these requests fall into the queue and wait in the wings, and a long wait often leads to deterioration, and even to aggravation of relations between teams. The tension is exacerbated by the fact that members of different teams rarely meet each other personally and, as a rule, share only the minimum necessary information.
Figure 2. DevOps IT organization
This diagram shows how collaboration works in the DevOps organization. Here, the same teams from the previous diagram abandoned inefficient communications, which increased disunity, and replaced them with personal contacts, thereby creating permanent channels of interaction between teams. These channels help build a hybrid skillset that helps employees better understand and represent the needs, challenges, and capabilities of the teams they represent. Teams give each other the opportunity to perform the necessary work through automated self-service portals instead of manually processing someone else’s change requests, as it was before. And thanks to the presence of interaction channels, these self-service systems are able to quickly adapt to the needs of the teams for which they are created. To achieve even greater mutual understanding and knowledge sharing within the organization, team members periodically rotate roles in order to gain experience interacting with different teams and better understand the overall picture of the IT systems they serve, thereby increasing their level of cross-functionality and usefulness.
In this post, we talked about how the implementation of PaaS solutions can encourage the organization to implement the DevOps methodology, and traditional roles and tasks are subject to change as part of this process. Therefore, we have listed the main IT tasks that arise in the organization with the transition to OpenShift, as well as the skills necessary for their implementation. We also presented the main set of organizational roles that occurs when building cross-functional DevOps teams, and the RACI matrix linking new roles with new tasks. And finally, we talked about how the OpenShift platform and its associated DevOps methodology can change the organizational structure of an organization when moving from a traditional hierarchy and application processing systems to cross-functional teams with a higher level of personal communications.