Cloud-Native is a Human Discussion

In a recent survey, 86% of businesses say cloud adoption is a top priority, and yet few understand what being cloud-native means. Firstly, a cloud-native transformation does not happen by containerizing a single application, by adopting Kubernetes, or by telling your IT department to “get on the cloud.” Being cloud-native is not the same as ‘the cloud’—it is a strategic, cultural and technological shift in how your entire business operates.

While ‘the cloud’ refers to the on-demand delivery of infrastructure (hardware/software) and other services and applications, cloud-native is an architecture for assembling these cloud-based components in a way that is optimized for the cloud environment. To take that one step further, cloud-native is the name of a particular approach to designing, building and running computer applications.

How Does a Cloud-Native Transformation Happen?

There are four phases of a cloud-native transformation and the problems they solve: think, design, build and run.

  • ‘Think’ is about identifying the problem. In this phase, companies should analyze where they are on their cloud-native transformation, what problems they are trying to solve by going cloud-native and what the best strategy is for advancing that journey.
  • The ‘design’ phase experiments with different solutions to identify which processes work best for your company and its people.
  • This leads into ‘build,’ where an MVP solution is created and tested alongside company-wide education around the new processes.
  • Once tested and ready for production, you move into the ‘run’ phase where the solution is scaled and maintained.

The technical architecture alone has many complex options to choose from, which inexperienced businesses often get wrong. It may seem quite simple, but in reality, there’s so much more than the technical aspects behind think, design, build and run.

How is a Cloud-Native Transformation not About the Tech?

One of the biggest mistakes businesses make when going cloud-native is underestimating the importance of people. Without structural and organizational change, you still have a long way to go. Kubernetes alone is simply not enough.

There are various non-technical aspects of a cloud-native transformation, some of which include:

  • Management practices
  • Organizational structure
  • Delivery processes

All of these link back to the culture of the organization, which tend to fall into three major types. These culture types track closely with the type of product or service delivery process the organization follows: waterfall, Agile or cloud-native.

  • Waterfall organizations are all about long-term planning. They are risk-averse, with a long decision-making chain and rigid hierarchy.
  • Agile organizations deliver quickly by using a more iterative, feature-driven approach, releasing updated or new features in one-to-four-week sprints.
  • Cloud-native organizations are built to take optimum advantage of functioning in cloud technologies, able to adapt quickly as the cloud technology evolves.

Why Culture Matters

Understanding which culture your business operates under means you can identify the right path to help you on your journey to becoming cloud-native. In most situations, this means undergoing a full cultural change, but there are some who find that transition easier than others. Let’s explain why.

Waterfall and Agile organizations are usually very different, but a lot of these differences are compatible; in general, that means they can merge fairly easily and successfully. Both organizations require coordination across teams to deliver separate parts together, although Agile delivers much more frequently. Organizations that are truly agile – particularly those that combine agile with a lean approach – can transition to cloud-native with relative ease due to the corresponding approach of iterating quickly and often. However, Waterfall organizations—or those that use some Agile methodology but which are not truly Agile—find transitioning to cloud-native the hardest due to the drastic cultural, organizational and structural change that is required.

Problems often arise when a company thinks adding a DevOps team to the business means they are now cloud-native. The waterfall side doesn’t understand or adapt to the cloud-native methods used by the DevOps team, and this causes a culture clash; the former thinks an application must be finished and delivered all at once, and the latter believes you should iterate and publish bit by bit.

How can Patterns Help?

Patterns are a way to visualize and simplify—to a degree—what you need to learn to get to the next stage of your cloud-native transformation. In that sense, each company will need a different set of patterns to transition depending on things like organizational culture, infrastructure and what architecture is in place. Let’s talk through some examples to help explain.

Situation A: You’re a waterfall organization that wants to become cloud-native, which means you will have to undergo extensive changes to the company’s tech, processes and culture. There’s a lot of time and money involved, which means you need to put a business case forward to ensure buy-in from senior executives. You would use the ‘Executive Commitment’ pattern:

cloud-native

Situation B: You tried to go cloud-native and failed because you thought the developers you tasked with delivering the new cloud-native system could also do their regular daily activities alongside it. To successfully go cloud-native, this organization should allocate a team of five to eight fully focused engineers and architects to start the transition before bringing in the rest of the organization. You would use the ‘Core Team’ pattern:

It’s important to understand that, when we talk about a pattern, one will not get you from Waterfall to cloud-native by themselves. The patterns highlight what you need to do to get to each stage of your journey, and so each company will use several that may change over time.

Visualizing the Goal

A cloud-native organization should have a collaborative culture where employees work together to solve problems and don’t get stuck or put into siloes. Like an evolution of Agile, these organizations deliver continuously using Lean and Agile methodologies, but focus more on delivery than iterations. Kubernetes is, of course, a must, and with that comes containerization, which both lead to an overarching architecture that focuses on microservices.

DevOps/SRE departments tend to lead the tech teams in such organizations, but the whole staff should embrace this new approach to business, with production and service offerings driven by data. It is only when all of these aspects come together that you have a self-healing maintainable application. This combination of cultural, strategic and technical change makes an organization cloud-native. But, importantly, those organizations understand that the job is not finished when you are cloud-native. In a sense, there is no end goal. Cloud is an emerging technology and, as such, to be cloud-native you have to be ready to constantly adapt and change as the technology does.

When companies fail to change their culture alongside the adoption of Kubernetes and containerization, their cloud-native transformation fails. Moving some operations to the cloud does not mean you are cloud-native. Only by changing the way your business operates to optimize cloud performance will you eventually reach that goal. But first, you need to understand where in the journey your business and your people are right now.

Jamie Dobson

Jamie Dobson is co-founder and CEO of Container Solutions, a professional services consultancy specializing in cloud migration.

Jamie Dobson has 2 posts and counting. See all posts by Jamie Dobson