Cloud Native Transformation: Practical Patterns for Innovation

In our experience it takes two to three years to truly undergo a cloud native shift and adjust to this new way of working. After that, it takes five more years to truly internalize the change —

example, it is common to see a platform DevOps team in charge of building the cloud native platform, while site reliability engineering (SRE) or first-level support teams respond to incidents (and spend the rest of their time working on automation to prevent them from happening in the first place).

The culture-clash conundrum works backwards, too: you can’t have otherwise full-on cloud native culture but not have microservices. If it takes you six months to deliver, you can’t be truly distributed. There is nothing to be gained in simply re-creating a monolith on the cloud — yet companies try do it all the time.

When experimentation becomes routine, the new is no longer to be feared. Innovation as a routine process is, after all, a core cloud native principle.

Taking creativity too far: digital transformation is the balance between innovation and pragmatism. When faced with the pressure to evolve due to some new disruptive competitor, some companies go all in on innovation and get lost. They miss the point of balance: you need to be more creative, not all creative. For example, Google is one of the most

Among the safest bets to choose from are in the Cloud Native Computing Foundation’s “Graduated Projects”. These are well-established tools like Kubernetes, which are likely to be around for the long run, and there are many related/supporting tools and resources built around them.

Now we are changing everything in every part of the organization all the time, and all at the same time, which is a completely different way of thinking. You will always be doing this, innovating and moving to the next thing, and the next. Innovation now needs to be simply another piece of your workflow — one that is built right in.

other. In short, culture is the way your enterprise goes about creating and delivering your service or product.

teams are still not really in charge of what they are building; their authority is limited to how to build whatever they are assigned.