Adjust IT team dynamics for a cloud-native approach
As enterprises set their cloud-native strategy, they'll need to navigate major changes -- both from a technical standpoint and in terms of IT team structure and management style.
Cloud-native means application deployment on a cloud service, but the concept goes far beyond that. The purest form of a cloud-native approach makes machine ownership obsolete -- organizations rent computing resources and orchestrate them to run scalable and resilient cloud applications.
But resources aren't the only thing to change, and a shift to a cloud-native approach doesn't happen overnight. IT and development teams first need to overcome a number of technical and cultural hurdles.
The benefits of going cloud-native
With on-premises applications, the operations team manages networking, storage, servers and virtualization layers that form a hosting environment. IaaS reduces their ownership to a few layers: the OS, middleware, runtime, data and applications -- in other words, everything in the stack except the infrastructure.
Since cloud computing reduces team responsibilities at the lower layers of the stack, admins should focus on application builds and the health of applications in production. Pizza as a service is an analogy that Albert Barron, executive software client architect at IBM, uses to break down the differences between levels of abstraction. He compares on-premises management to making a pizza at home; IaaS is akin to a take-and-bake service, which provides a premade pizza to cook at home; PaaS is pizza delivery; and SaaS is an eat-in restaurant.
But pizza isn't the only analogy applied to cloud computing. The most common, cattle vs. pets, describes the evolution of server management. Admins who devote significant time and attention to individual servers cannot scale that level of attention up to larger environments. As applications scale, this behavior must shift to a more distanced, methodical practice: Broken servers aren't given special treatment to regain healthy status but rather taken out and replaced. Servers aren't named and maintained individually like pets and instead are addressed as a pool -- or herd.
Prepare for a cloud-native approach
Cloud-native refers to applications or services built and designed to operate exclusively on cloud services, rather than retrofitted from an on-premises infrastructure.
But a shift to a cloud-native approach requires a change in application management -- and in IT teams. Cloud-native applications frequently rely on microservices, along with containers, service mesh, immutable infrastructure and declarative APIs. Microservices are a distributed set of isolated modules, a radical departure from monolithic application architectures. Microservices are a natural fit for cloud-native application infrastructures because each service works as an independent component of the application and can scale automatically and independently from other services. Cloud resources are flexible to allocate and can scale automatically if desired. For traditional IT teams that have established resource management methods before adopting a cloud-native approach, this change can be painful. To benefit from microservices' advantages on cloud services, such as scalable and polyglot application builds -- which are possible because the application does not reside directly on a given machine's OS -- admins must understand advanced operational concepts around orchestration and isolation.
Build cloud-native teams
The challenge of microservices in cloud-native deployments is also a human one; any major change in IT environment shakes up team culture and management style.
Conway's Law states that an organization will design a system that copies the communication structure already in place. This principle forms the foundation of many organizations' implementation of microservices applications.
IT staff communication suffers from the same pitfall as microservices API communications: It gets worse as it gets bigger.
But IT staff communication suffers from the same pitfall as microservices API communications: It gets worse as it gets bigger. Break projects up across smaller teams to limit the number of communication links between members. For example, a team of seven people has 21 connection points. The optimal team size is 6.2 members, according to Richard Hackman, author of Leading Teams. Six people per team brings the number of connections under 20 and promotes more fluid and efficient intercommunication.
While team size matters, it's not the only important factor for IT organizations. Cross-functional teams achieve more work in less time than siloed teams composed of workers with like titles, according to some management studies, such as Peter Drucker's work on management by objectives. Cross-functional teams, sometimes called feature teams, are composed of individuals with diverse backgrounds and expertise to collaborate and solve problems faster and more creatively. They are less goal-dominated and less unidirectional, which stimulates productivity, creativity and capacity to handle complex problems. Cross-functional teams are common in DevOps organizations, where a feature team might comprise, for example, several developers, a test expert, an operations engineer and a database administrator.
A full redesign of organizational dynamics and culture for a cloud-native approach doesn't happen overnight. Often, an inability to move forward and innovate quickly is due to technical debt.
A transformation campaign takes time, and you will encounter unexpected issues. But a journey of a thousand miles begins with a single step. Start a cloud-native strategy with quick wins to gain momentum, and build trust in staff that the change is possible.
