Cloud Native Transformation: Practical Patterns for Innovation

Complete separation of duties: execs in charge of strategy, managers in charge of setting objectives, engineers free to execute their work as they see best.

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.

Risk reduction today is the ability to respond to sudden or unexpected changes in market conditions when you don’t have much notice, in time to meet or beat the competition. And you achieve this ability through strategy.

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.

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).

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

Agile organizations normally have wide responsibilities within cross-functional teams but narrow responsibilities for each team.

This is how we de-risk change: by building continual evolution and learning into the architecture itself. If you do it all the time, suddenly change is no longer scary.

Cloud native transformation is never just about microservices and Core Teams and Kubernetes, or even about evolving from Waterfall/Agile. The true metamorphosis was from being an organization that rarely faced change, and that probably even feared it, to an adaptive organization that can change direction as needed, quickly and confidently.