There is a tendency at any conference to get lost in the message. Spending several days immersed in any subject tends to do that. The purpose of such gatherings is, after all, to sell the company or technologies being featured.
Against the beautiful backdrop of the city of Barcelona last week, we got the full cloud native message at KubeCon and CloudNativeCon. The Cloud Native Computing Foundation (CNCF), which houses Kubernetes and related cloud native projects, had certainly honed the message along with the community who came to celebrate its five-year anniversary. The large crowds that wandered the long hallways of the Fira Gran Via conference center proved it was getting through, at least to a specific group.
Cloud native computing involves a combination of software containerization along with Kubernetes and a growing set of adjacent technologies to manage and understand those containers. It also involves the idea of breaking down applications into discrete parts known as microservices, which in turn leads to a continuous delivery model, where developers can create and deliver software more quickly and efficiently. At the center of all this is the notion of writing code once and being able to deliver it on any public cloud, or even on-prem. These approaches were front and center last week.
At five years old, many developers have embraced these concepts, but cloud native projects have reached a size and scale where they need to move beyond the early adopters and true believers and make their way deep into the enterprise. It turns out that it might be a bit harder for larger companies with hardened systems to make wholesale changes in the way they develop applications, just as it is difficult for large organizations to take on any type of substantive change.
Putting up stop signs
These technologies, and the cloud native ethos in general, have reached a point where we are beginning to see that transforming the way a company creates applications is not a simple matter after all. It requires a full-blown cultural transformation, and coordinating a cultural shift is never going to be easy, especially in large organizations with complex security and governance requirements.
you still have to sell security and compliance on the idea that you can move faster without breaking things, and that takes some diplomacy
As an example, one company at the event believed it had embraced cloud native principles, but it turned out to be more complicated than that. This company spent two weeks working on software and two weeks doing QA and security checks. You can’t blame a mature organization for working this way, but this process is more a traditional programming workflow than true cloud native.
Companies like this one have these stop signs in place to protect the organization, and it’s hard to fault them for it, but this example illustrates just how difficult it is to take these cloud native ideas and put them into practice inside large organizations, who aren’t always willing to give up the controls that have been built to protect the company.
Helping them transform
Red Hat, which was acquired by IBM last year for $34 billion, is a company that tries to relate to these kinds of organizations by stripping away the jargon and just looking at the underlying issues the cloud native ideal is trying to solve.
Brian Gracely, director of product strategy at Red Hat, says that cloud native isn’t a concept that most line-of-business leaders think about. They are trying to solve business problems, and that is where Red Hat tries to relate to them. The industry jargon thrown about at conferences like KubeCon has little relevance in that context.
“For the most part, our customers say we need things that are going to help us build software faster, deploy it faster, and help it scale where it makes sense to scale. And those tend to be the criteria that they focus on the most,” Gracely told TechCrunch. That is of course, what cloud native is trying to achieve, he just doesn’t see much value in framing it in those terms.
Moving faster without breaking things
That approach can make large non-technology enterprise companies more open to the cloud native philosophy, but you still have to sell security and compliance on the idea that you can move faster without breaking things, and that takes some diplomacy.
Gabe Monroy, partner program manager at Microsoft, says it’s important to remember that each company is different and you have to think about those cultural and business differences when you work with companies to help them understand this stuff.
“Unfortunately, there is no single playbook because every company is different. When you are trying to solve organizational problems, or people problems, people are messy. So oftentimes, it requires a unique approach,” Monroy explained.
He says that starts with understanding that the folks in security and compliance are not simply saying no to make your job difficult. They have a valid role in the organization and it is incumbent upon cloud native proponents to recognize that. “The key is approaching folks in compliance and security with a healthy degree of empathy. These folks have to approach their job with a degree of risk management that development might not [always] appreciate,” he said.
While it’s easy to lose that thread at a conference like this, it’s absolutely essential to keep in mind as you think about transforming the way you develop software, whether it’s embracing cloud native or something else that speeds up your delivery cycles.
The fact is that many large organizations are going to move slowly and cautiously, most likely because they have seen a similar movie before where they were told with great certainty that they needed to embrace this next big set of technologies coming down the pike, or risk getting left behind. And while they may truly risk getting left behind in this instance if they don’t find ways to speed up their development cycles, large organizations are not going to move full speed ahead because a conference of true believers said they should. They need proof points and methodologies that fit how they do business, and if they don’t get that, it doesn’t matter how convincing your messaging is.
That is the challenge for this community moving forward. They have done an amazing job growing the project and its underlying philosophy. The rest is probably up to vendors to package these tools and technologies in a way to make them relevant to large organizations (as they have begun to do). The community as a whole also has to understand that developer requirements and large organization requirements will not always fully align. From this point forward, it is essential for them to keep this mind if they want this approach to really take off in business.