How OpenShift is changing the organizational structure of an IT organization. The evolution of organizational models when moving to PaaS

Although PaaS (Platform as a Service) solutions alone are not capable of changing the ways of individual and team interaction, they often serve as a catalyst for organizational change in response to the increased flexibility of IT technologies.

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

Tasks Required skills
Automation and provisioning of IT infrastructures

Works:

  • Design and construction of hardware solutions
  • Organization and maintenance of initial setup automation
  • Design and automation of VM and host preparation

  • Design and implementation of data centers
  • Linux system administration
  • Automation scripts
  • Knowledge of storage systems
  • Knowledge in the design and implementation of networks
  • Security

Installing and managing the OpenShift platform

Works:

  • Performing Cluster Installation
  • Infrastructure Services Management
  • Platform Scale Management
  • Platform Level Authentication and Authorization

  • Linux system administration
  • Network technology knowledge
  • Automation Scripts (Ansible)
  • Knowledge of storage systems
  • Knowledge of container technology and architecture
  • Knowledge of Kubernetes and OpenShift architectures
  • Platform security
  • Monitoring integration

Management of tenant provisioning, IT isolation

Works:

  • Creating users and teams within the platform
  • Design and manage quotas
  • Design and implementation of RBAC

  • Knowledge of Kubernetes and OpenShift architectures
  • Knowledge of container technology and architecture
  • Automation scripts
  • Good knowledge of projects, quotas, role binding, and work with planners

Build and manage basic images

Works:

  • Design workflow for changing images
  • Standards-based image development

  • Linux system administration
  • Automation scripts
  • Configuring runtime application components and middleware
  • Knowledge of container architectures
  • Application build frameworks
  • Good knowledge of images, imagestream and patterns

Design and manage deployment pipelines

Works:

  • Design and documentation of conveyor standards
  • Development of quick guides and templates
  • Developer Training

  • Source code management
  • Design and implementation of applications
  • Automation scripts
  • Automated Testing
  • Code Quality Testing
  • Knowledge of container architectures
  • Knowledge of immutable infrastructures
  • Security – access control to the stages of the pipeline, approval of work processes, etc.
  • Good knowledge of OpenShift templates, buildconfigs components, deploymentconfigs, services, routes, configmaps

Application and test development

Works:

  • Application coding
  • Development of automated tests
  • Responding to test failures during the deployment pipeline
  • Application Failure Response
  • Custom Acceptance Testing

  • Design and implementation of applications
  • Automated Testing
  • Source code management
  • Application monitoring
  • Knowledge of cloud native architectures

Operational monitoring and application management

Works:

  • Designing applications in the context of performance
  • Monitoring applications at run time
  • Application scaling (or autoscaling)
  • Application Availability Management
  • Quotas for requests and limits for resource management
  • Performance and IT Testing

  • Design and implementation of application performance
  • Application Performance Monitoring
  • Performance testing and stress testing

Custom Acceptance Testing

Works:

  • UI testing (design and user interactions)
  • Development of automated tests

  • Designing and testing user interfaces
  • Automated Testing Templates
  • Testing frameworks
  • Application Design Templates

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.

Tasks Roles
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.

Summarizing

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.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *