If you are an IT conference buff, you have noticed the significant uptick in the number of conferences with cloud native in their name. This is just one small indicator of the speed with which Cloud native has caught on. In Spite of all these conferences, however, Cloud native is still, very much a puzzle: Is it a tool? A set of tools? A set of processes? A way of architecting applications as microservices? Automating tests and integration? Pushing new features out every day? And what does culture have to do with it?
To answer these questions and others, we sat down with Pini Reznik, the co-author of a new book titled “Cloud Native Transformation: Practical Patterns for Innovation” for a one-on-one exchange.
Pini is Co-founder and CTO at Container solutions and has been at the forefront of both shaping the Cloud native landscape as well as advocating for Cloud native as the next logical step in the evolution of the IT landscape.
As the title suggests the book takes a much broader view of Cloud native beyond simply the tools that make it up and its technical aspects. Cloud native according to Pini exists at the intersection of Cloud native tools, organizational change and culture. The book also introduces the concept of patterns: a common language for the Cloud native community to communicate about concrete pathways towards digital transformation. Below is the full text of the interview.
Q: Give us your take on Cloud Native: What is it, and why do you think it's important?
Pini Reznik: Most people think that Cloud Native is a set of technologies related to clouds, containers, Kubernetes, microservices, etc. Even the CNCF (Cloud Native Computing Foundation), a non-profit organization leading the way of Cloud Native adoption, is mostly talking about the technical aspects, such as containers, orchestration, and microservices.
We think Cloud Native is a much bigger thing. We think that, in addition to the aforementioned technical sides, it also includes organizational change, new and more flexible processes, and much more dynamic culture that will allow the company to utilize the benefits of all those modern technologies. Cloud Native requires a full organizational transformation.
In our mind, Cloud Native is not about new technologies but about faster innovation that helps to learn what your customers really want and deliver an improved product on a daily or even hourly basis.
Q: Who are “strangers” in the context of Cloud Native and why are they a threat to traditional enterprises?
Pini Reznik: In our book, Cloud Native Transformation, we tell the story of the fictional financial company WealthGrid. In that story, we're talking about three types of strangers or companies that come to WealthGrid’s market and start taking their market share:
Number one, A tiny startup, in our case a U.K.-based challenger, Starling Bank. Starling could build a functional mobile bank in just one year with less than 20 people. This is an amazing speed that allowed them to access essentially unlimited VC funds and grow to 800 people, and over 1.5 million customers in just three years.
Two, a large incumbent bank like the Dutch ING that sets itself a goal of “being a tech company with a banking license,” as its CEO Ralph Hamers says.
And three, a large tech giant like Amazon, which is currently holding a banking license and may become the largest bank in the U.S. in the matter of a couple of years.
But an even more interesting one is the latest newcomer that just landed on us totally unexpectedly and immediately shuffled the cards: the COVID-19 virus. While the rest may come slowly over the course of the years and, step by step, grab parts of the market share, this stranger is much faster and way more dramatic in its effect. Everyone is losing and has to be very quick and decisive to survive.
Q: Which cultural and technological aspects have to come together for Cloud Native?
Pini Reznik: The core principle of the Cloud Native approach is fast experimentation and research through action. This is compared to more planned and predictable ways of the more traditional approach. Teams have to be very agile and just try new things instead of spending a lot of time and effort trying to answer all the possible questions prior to jumping into the projects.
Unfortunately, we as humans are preconditioned to preserve the current state and protect the status quo. Cloud Native is about fast change in uncertain situations.
The most successful Cloud Native teams are capable of living with ambiguity and uncertainty.
Q: The book dedicates an entire chapter to the human challenge of Cloud Native. What is that challenge, and why do you think cultural change is the toughest of all the Cloud Native elements?
Pini Reznik: Because those challenges are hidden during our normal work. Companies understand the technological and organizational challenges but rarely focus on the human side of the change. Also, technology is easily changeable but our biases are genetic; we as a human race have been carrying them for thousands of years. It’s easy to install Kubernetes, but difficult to ignore our cognitive biases.
Q: The book also introduces the Cloud Native Maturity Matrix. Give us an overview of this tool.
Pini Reznik: The main goal of Cloud Native maturity is to show that the transition to Cloud Native has to be done in a holistic way. Technology and organization have to change together and support each other.
For example, when a company is moving to microservices but doesn’t introduce Continuous Delivery, it will lead to too much manual work and eventual low quality. The delivery team will be always too busy with manual deliveries.
But also, a strong hierarchical structure should change as in Cloud Native world. Decisions cannot be taken by managers, as they cannot possibly know everything that's going on and make reasonable and timely decisions. But to allow this to happen, the teams have to have psychological safety to make mistakes and not be punished for them.
So, everything has to be done together
Q: What is the one element of Cloud Native that is absolutely crucial to transformation?
Pini Reznik: Starting small and expanding over time. Transformation is mostly about change management, moving from known to unknown. If you jump all in, you almost certainly will make mistakes as they are natural in a new environment. Therefore it’s better to start with small experiments and invest increasingly more, following new uncovered information.
There’s a pattern called Gradually Raising the Stakes that applies here.
Q: The book also introduces the concept of patterns. How would you define patterns and how do they help?
Pini Reznik: Patterns were introduced by Christopher Alexander in his books The Timeless Way of Building, A Pattern Language, and The Oregon Experiment.
The main idea behind the books is to encourage evolutionary piecemeal improvement over big-bang changes. Exactly the principle of starting small.
To achieve this, he had to create a common language for architects and the actual users of the buildings. Patterns are like words in this language— table, chair, sofa, etc. They are sort of mutually agreed on everyone, but still open for many ways to implement them. Language is a collection of the words on a topic and a design is like a story: “There is a square table with four chairs and a sofa in a room.”
Patterns and pattern languages create shared understanding between experts and users and allow them to build the future together, when experts bring their domain knowledge and users bring their own needs and understanding of their people and organizational culture.
Without a common language, users can’t clearly explain what they want and experts tend to build the best possible solution they can imagine without considering the real needs of their own customer. As the philosopher Ludwig Wittgenstein said, “The limits of my language are the limits of my world.”
Q: How do team composition, skills, and communication differ in a Cloud Native organization as compared to legacy Waterfall models?
Pini Reznik: The team structure is pretty much similar to Agile cross-functional team structure.
There are some additions, though.
In the beginning of the transformation, a small Core Team is the most effective. Their task is to break ground, gain knowledge and set up the basics of the future Cloud Native setup.
Then there are typically three types of teams:
A Platform Team is the team that is building and maintaining the company cloud native platform that can be used by the Build-Run teams.
Build-Run teams or DevOps teams are the development teams that are fully responsible also for the infrastructure for their products. They are doing so by using infrastructure as code principles. They are also fully responsible for the lifecycle of their product including it’s maintenance and continuous improvement.
A SRE team, or Site Reliability Engineering team, is helping everyone to continuously increase quality.
Q: What is, in your opinion, the best way for companies to approach Cloud Native?
Pini Reznik: We’re typically approaching the transformation by doing a bit of thinking first. Finding the right people to support the initiative, define the business case, create a vision, set up a team, etc. This all can be done in a matter of a couple of weeks. Such initial investment in strategy may save a lot of trouble later on.
Then we go through a series of experiments, all the way to building a minimal viable product, or MVP, which should be done as fast as possible. Following that, a gradual transformation really starts. Teams are educated and onboarded one by one, to allow the Platform Team to continue improving the platform and providing effective support.
Q: Based on your experience, what are some common challenges that organizations face in moving to a Cloud Native way of doing things?
Pini Reznik: Starting too big.
Only doing technical change, ignoring the organizational and cultural elements.
Another one is starting with “lift and shift,” simply moving their old databases etc. to new technology. This leads to poor results and costs more than expected. And although companies may think that they will continue the refactoring later, they would typically lose motivation after all the old stuff is in the cloud.
Q: What would you identify as the three key takeaways from the book for CIOs and CTOs?
Pini Reznik: Number one, slow innovation in today's fast-changing world is an existential threat.
Two, Cloud Native transformation has to be done in a holistic way including technology, processes and culture
And three, the “start small” principle will save time and lead to higher quality.
Q: What’s next? What do you think comes after Cloud Native?
Pini Reznik: Technology will of course continue changing and everything will become even smaller. Microservices will become functions and speed of delivery will be even faster.
But a more interesting change for me is the shift from large software factories to complex supply chains producing large digital systems. Same way as normal containers not just changed transportation but allowed us to produce complex products in different parts of the world and then assemble them and distribute around the world at very low cost.
I predict similar changes to happen in the software world. Instead of creating end-user products, companies will gradually shift to production of components that could be used in a variety of other products. Those components will be consumed through APIs or as functions or though whatever next round of technological change will bring us.
Here is a free 75 page preview of Cloud Native Transformation: Practical Patterns for Innovation. If you want dig deeper into Kubernetes based Cloud native environments, download our comprehensive guide below:
Fan of all things cloud, containers and micro-services!
In this instalment of our Kubernetes best practices series we review the concepts of Kubernetes tenants and multi-tenancy, identify the challenges that have to be overcome and outline best practices for DevOps and cluster admins operating multi-tenant Kubernetes clusters.
April 20, 2020
8 min read
Part four of our Kubernetes and Cloud native application checklist evaluates service mesh tools based on ease of use in cloud native environments as well as their traffic management, security and observability feature-sets.
April 8, 2020
8 min read