What is the Key to Cloud Native Success? People and Process.

Making the evolution to cloud native is only partly a technology journey.

True, cloud providers have created powerful tech suites that mean organizations can push undifferentiated infrastructure work ‘to the platform’ and focus more on their core competency.

But while these suites make cloud native possible – and with it all the benefits of delivering better applications and services more quickly – the driving forces for cloud native success are agile processes and agile people.

People always make the journey more complex than a pure tech play, but the good news is that cloud native is not an on or off switch. While start-ups today tend to be ‘born in the cloud,’ established enterprises don’t just become cloud native. Instead, via a managed refactoring of people, process and tech, they can dismantle or phase out monolithic applications (and the team structures that support them) in favor of development architectures and patterns that embrace rapid innovation.

Making this journey requires IT leaders to understand what fully mature cloud native capabilities look like, in order to assess and pivot from their current state. And that starts with understanding the interplay between people and process — a requirement for understanding an organization’s ability to unlock the power of cloud native thinking.

Breaking free from infrastructure

Technology’s influence on this journey stems from the way cloud native tech differs from other types of cloud technology.

Full cloud native maturity embraces fully managed services — which increasingly means serverless technology — to the extent that all infrastructure concerns are offloaded to the platform. This enables the modern development practices at the heart of what it means to be cloud native, such as microservices architectures and CI/CD (continuous integration/continuous delivery).

Benefits include usage-based pricing, built-in scaling and fault tolerance, data durability and decreased time to market on new features and services. It’s also the best way to enable your business to focus on its core competencies. (It does, however, demand a deeper level of commitment to a particular platform.)

This is vastly different from entry-level cloud services such as infrastructure instances and VMs, storage and networking, where you’re still responsible for operational thinking around backup and scaling. It’s also worlds away from managed infrastructure services or applications, where despite a slightly higher level of abstraction from infrastructure concerns, you’re still responsible for managing services and applications.

Freed from the concerns of infrastructure, development teams, product owners and leadership need to re-adjust their mentality to understand where they plug in.

Turning people into cloud natives

At a high level, cloud native people have an agile mindset and are comfortable with agile methodologies. In their teams, they have a high velocity, meaning they move quickly from idea to delivery, which requires effectively identifying and delivering appropriate minimum viable products. With the help of the processes covered later on, they’re able to work with the rapid feedback loops required to create shorter product lifecycles — and they can do so while maintaining or exceeding quality.

For developers this means they need to get deep — iteratively — into new the sets of tools, tech and methodologies to be able to build cloud native apps. Technology like serverless is brand new and it moves fast. What was relevant even just a couple of years ago is not relevant now, and application development mainstays such as Java have less of a place. Adapting means liberating the technologist inside every developer by giving them the freedom to experiment with new tech and new development patterns. This also makes cloud native an opportunity to boost recruitment and retention of high-value talent.

Meanwhile, product owners need to get accustomed to delivering new features and services in days or weeks, rather than months or years, and responding to tighter feedback loops in their product lifecycles. Agile for this group means bringing users and customers into the process earlier, in order to make mistakes less costly and less likely, while becoming comfortable working with minimum viable products.

And finally, for executives, managers and support groups such as IT, embracing a cloud native mentality means adopting an enabling mindset — not a restricting one. Development talent needs fast and easy access to tools and tech to experiment with, so that means tearing down barriers to technology procurement.

New types of teams are also required to develop and maintain applications built using microservice architectures. To accommodate, this leadership’s focus should be on building cross-functional teams, divided by responsibility for individual services rather than by function (i.e., development or operations). And while these teams should be empowered to self-organize, leadership also needs to enable cross-communication and facilitate their coming together to pursue a common purpose as necessary.

Process, process, process

Enabling the cloud native mindsets described above comes down to the final piece of the puzzle: processes.

While approvals-based access to technology made sense in the data center world, where cost and complexity are higher, it makes much less sense in cloud native. Instead, a guardrails-based approach that leverages automated budget caps and tooling permissions is a more effective way to give developers the freedom they need to experiment and grow their knowledge. In a similar vein, traditional enterprise architecture groups will struggle to keep up with the pace of cloud native innovation — so don’t overstress their role.

With CI/CD so fundamental to being cloud native, the right tooling becomes essential to accelerating application delivery and maintaining quality. Automation is key to making this process efficient, particularly automated ‘smoke testing’ against production environments and the identification of issues through application monitoring. Capturing and acting on performance and functionality feedback is also critical, especially when it comes to reducing the natural waste associated with application rework.

This marked increase in information capture and measurement extends into monitoring the ability of agile teams to work together to define applications in a cohesive way, with particular attention on enabling consistent velocities across different teams. Meanwhile, measurements of overall delivery quality can be augmented further by customer satisfaction scores (such as NPS).

Finally, you need processes in place to be able to ‘train your trainers’ by scaling learnings from one team or service to potentially dozens more.  

This is not light work, and it could be the subject of an article in its own right. But the answer to who owns this work is at least a simple one: everyone. Development teams are responsible for creating quality code — as they always have been — and contributing to effective and efficient CI/CD pipelines. Product teams are key to getting feedback from customers and getting that back to the development team in an actionable way. Meanwhile, management establishes processes at a leadership level and has oversight of performance of both processes and people.

It’s never too early to start

We see interest in cloud native across the spectrum. As noted earlier, well-established organizations — as opposed to start ups — don’t just become cloud native.

So where should most organizations start? Typically, I recommend beginning the journey to cloud native thinking when building net-new products and services, or during application modernization (which is an opportunity to break up monolithic applications and reconstruct them in part or in whole using a microservices architecture).

In terms of knowledge building, serverless technology is a key area in which to build capabilities and closely track trends. The nature of these services — small, function- or problem-specific blocks that can be knitted together — means the ecosystem is growing all the time, with plenty of overlap in some cases. As this box of tools grows, understanding how they all fit together becomes a strong competitive advantage.

Cloud native systems are designed to embrace fast change, rapid scaling and resiliency. But people rarely move as fast as technology. Your teams will need time to develop their knowledge and adapt to the new processes required to maximize it.

So it’s never too early to begin creating opportunities to build and share cloud native knowledge.

Join the Conversation: Find Solve on Twitter and LinkedIn, or follow along via RSS.

Stay on top of what's next in technology

Learn about tech trends, innovations and how technologists are working today.