Cloud native transformations with Pini Reznik

If you’re interested in receiving interviews with thought leaders and a digest of exciting ideas from the world of DevOps straight to your inbox, subscribe to our 0800-DEVOPS newsletter!

###

Pini Reznik is Chief Revenue Officer and co-founder of Container Solutions, our partner company dedicated to delivering cloud native solutions and driving cloud native transformations. I met Pini last year on our annual QED conference where he was delivering a talk and wrapping up last chapters of what turned out to be an excellent book. This year we’re stuck at home but nevertheless don’t miss our conversation on cloud native transformations.

Ivan: As organizations are moving through the “Trough of Disillusionment” with microservice architecture, some of them are seriously considering moving back to monolithic architecture. What is your take on this and is it possible (or wise) to develop and run monoliths in cloud-native environment? Are microservices a necessary prerequisite for Cloud Native?

Pini: I think there is a lot of misunderstanding about why microservices exist. They help to solve specific technical and organisational challenges. But microservices or any other technology, methodology, or architectural principles cannot solve all the problems in the world.

To use microservices effectively, teams have to adjust not only their infrastructure and development practices but also their way of working and their culture. Without a holistic approach, a transition to microservices may lead to worse results than the use of old and well understood monoliths. We’ve created a Cloud Native Maturity Matrix to explain this paradox.

Ivan: We can see many organizations acing Kubernetes pilots and, encouraged by these initial successes, moving quickly to production without any supporting services such as observability and security. Have you also seen this in the wild? What is the minimum platform-maturity level that you would be comfortable running the production with?

Pini: We see it all the time. A lot of companies come to us after a few years of a struggle with the Cloud Native technologies. For us, the critical parts to be ready before full-scale production are deployment automation (CI/CD), observability, and a good level of training for the developers moving to the new platform. Basically, you have to know what you are deploying and what’s going on in the system after the deployment.

There are of course other critical parts, such as security, scale, etc. that are critical for production-grade systems. But in our experience, the most overlooked elements are a good CI/CD setup and a reasonable ability to observe the system.

Ivan: What are, in your experience, typical mistakes that organizations make when going Cloud Native?

Pini: The most common mistake we see at our customers is when they consider adoption of Cloud Native technologies as a purely technical initiative that is done by the engineering team without any support from the higher management. This almost never leads to successful results, until the people involved in the transformation realise that the real change is organisational and cultural.

Other common mistakes we see are lack of a proper CI/CD setup and “lift and shift” in the beginning of the transformation. In both scenarios, in different ways, the team will spend a lot of energy on the wrong tasks, leading to poor results and frustration for the engineering and management teams—and eventual stagnation of the initiative.

Ivan: I like how in your book Cloud Native Transformation you talk in terms of patterns. This suggests a tailor-made, non-linear approach to transformation?

Pini: The process is very similar, but each company has its own culture and its own business goals. We know what is Cloud Native and understand the best path towards it, but there is no one better in understanding company culture than the people who are actually working in the company.

For these reasons, every transformation is a co-creation between us as experts and the customer who eventually has to move to Cloud Native. Patterns are just a common language we use to communicate effectively during transformation.

This approach is best described in the book called Humble Consulting.

Ivan: Understanding that every organization has its own way, do you still see some patterns emerging as more important than the others? What patterns do you see successful organizations typically start with?

Pini: In our experience, very few companies understand the full scope of Cloud Native transformation and do not allocate enough time and resources to it. To address this we use a combination of three patterns: Transformation Champion, Business Case, and Executive Commitment. These three patterns together lead to strong commitment of the organisational level and remove a lot of the roadblock that most teams will encounter on the way to Cloud Native. They are significantly more important than any of the technology or process patterns.

Ivan: When going Cloud Native, some people promote the “lift and shift” approach as a first step in their journey. Can such an approach be effective?

Pini: As mentioned before, I believe this is an approach that often leads to poor results. Main reason is psychological rather than technical. The main idea behind “lift and shift” is an easy move to a cloud to gain the immediate benefits of leaving behind the maintenance of your own infrastructure. This is perceived as only the first step towards later re-architecture of the system to get the full benefits of the Cloud Native world.

Unfortunately, it isn’t as easy as expected and still requires large investments of time and resources. By the end of the process, that team is tired, demotivated, and not particularly happy with the results—but the setup is functional and no one really dares to go back to the management team to get an approval for another difficult and lengthy project.

We would typically recommend our customers start small, acquire the relevant capabilities by gradual re-architecture and then, after most of the frequently changing systems are successfully running on the new platform use the pattern Lift and Shift at the End to move the remains of the old setup that isn’t worth refactoring to the public cloud, to be able to retire old data centers and get rid of the maintenance burden.

Ivan: Can you share with us what are you reading these days and who are the people you follow that make you think differently and do better?

Pini: One of the most interesting books I read recently was a book written by Ed Catmull, founder of Pixar. It’s called Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration.

This book is full of inspiration and of amazing stories about one of the most innovative teams that ever existed. Pixar never failed to produce amazing digital animation movies for many years and it didn’t stop after Pixar was acquired by Disney. Instead of slowly degrading into Disney’s corporate culture, the opposite happened and Disney itself returned to its glorious days when it was run by Walt Disney.

Our book and a lot of our work resembles a lot of Pixar’s story, and we have even borrowed tools like Braintrust from the book to help us to push the innovation forward.

###

If you’re interested in receiving interviews with thought leaders and a digest of exciting ideas from the world of DevOps straight to your inbox, subscribe to our 0800-DEVOPS newsletter!