

However, some of the fundamental assumptions about how that fabric performs change when you’re in the cloud.

This means that almost all of the principles of good architectural design still apply for cloud-native architecture. The good news is that cloud is made of the same fabric of servers, disks and networks that makes up traditional infrastructure. A well-architected cloud native system, on the other hand, should be largely self-healing, cost efficient, and easily updated and maintained through Continuous Integration/Continuous Delivery (CI/CD). If architects fail to adapt their approach to these different constraints, the systems they architect are often fragile, expensive, and hard to maintain. While the functional aspects don't change too much, the cloud offers, and sometimes requires, very different ways to meet non-functional requirements, and imposes very different architectural constraints. 'orders must be updated on our existing mainframe system'). Constraints (what is out-of-scope to change e.g.The non-functional requirements (how it should perform e.g.The functional requirements of a system (what it should do, e.g 'process orders in this format.').Consider the high level elements that we as software architects are trained to consider: But what exactly do we mean by cloud-native? More to the point, how do you go about designing such a system?Īt a high level, cloud-native architecture means adapting to the many new possibilities-but very different set of architectural constraints-offered by the cloud compared to traditional on-premises infrastructure. At Google Cloud, we often throw around the term ‘cloud-native architecture’ as the desired end goal for applications that you migrate or build on Google Cloud Platform (GCP).
