The Cloud-native wave peaked over a decade ago, overshadowed by more recent waves like Blockchain, then AI. However, it remains an important consideration for both new and established businesses. This is because Cloud-native means adapting to new possibilities offered by a very different set of architectural concerns. For an Engineering Leader, this raises some important questions. What is Cloud-native? Why is cloud-native important? How to approach adoption?

Understanding Cloud Native

Cloud-native is a system architecture that is specifically designed from the ground up to take advantage of the elasticity and distributed nature of the cloud. The pillars of a cloud-native system architecture are microservices, container orchestration, DevOps, and continuous integration/deployment.

Importance of Cloud Native

A cloud-native approach provides a cost-effective strategy to address all the challenges of building a modern software solution. Some of these challenges are operational excellence, security, reliability, availability, and scalability. Your business expects you to handle all the challenges together; foregoing one for the other is not an option.

Your customers will expect security, reliability, and availability by default.

Operational excellence is expected of your function by internal stakeholders and is necessary to meet customer expectations within time and budget constraints.

While scalability may not be a consideration at the beginning, you'll find your Engineering budget will be stretched within a year of operations if operational costs scale linearly with increased usage. If your apps need to interface with external systems, their expectations may force you to acknowledge performance and scalability considerations sooner than you anticipate.

Adoption Strategy

The trick to successful cloud-native adoption is to minimize your Team's responsibility to what the system architecture truly needs.

For example, if your architecture needs a PostgreSQL database, will you spin up a virtual machine and host the database, or will you use a PostgreSQL IaaS? There's no universally correct answer. Even without the additional advantages such as automatic database backups, read-replication, and automatic failover from an IaaS solution, choosing the IaaS option may be better because it significantly reduces your Team's responsibility. On the other hand, if your Team needs to be responsible for database extensions or custom packages, choosing to host the PostgreSQL database in a VM may be a better choice.

Generally, my advice is to fulfill your system architecture needs in the following order, going down the order only if the functional aspects cannot be met.

PaaS

Recommended for authentication/authorization, app analytics, feature flags; any need that is generic to your system.

IaaS

For backing services such as databases, pub/sub, logging, and other core functions that different system components may need.

Managed services

When an IaaS offering is not enough for your needs or a previous investment needs to be capitalized. For example, using a managed Kafka service is a better choice over AWS Kinesis or Google PubSub if the existing solution depends on Kafka.

Containerization

When your system is using a niche component or your system services

Virtualization

When your system is using or developing a niche component that does not support containerization, or you need custom OS extensions or configuration, for example, a specific Linux kernel with certain custom modules.

Bare Metal

If a system component directly interfaces with hardware components.

Bonus: Measuring the Adoption Progress

This section is for Leaders who need to migrate on-prem systems to the Cloud or improve a previous lift-and-shift migration.

A recommended starting point is a strategic Domain-driven design exercise. Depending on your system complexity, you might have one domain with sub-domains, or you may have several interconnected domains, in which case you apply the following steps, domain by domain.

Classify each sub-domain as core, supporting, or generic. A sub-domain is core if that sub-domain is the reason why you are writing the software. A supporting domain supports the core business, and it is crucial for success, but you don't necessarily want to or need to build everything in it. A generic sub-domain is orthogonal to your business, or is something that is required across different products. For example, if your product offers hotel booking, then the booking process is your core domain. If the product depends on hotel listings, then a listing API is a supporting domain. If travel agents need to log in to the system, then authentication is a generic sub-domain.

Next, list the runtime components of each sub-domain, the runtime's current level in the bare-metal/PaaS spectrum, and its desired level. You may assign each level a numerical score, with the highest score to PaaS and the lowest score to bare-metal, so that when a runtime replaces a lower-level solution (for example, virtualization) with a higher-level solution (for example, containerization), the cloud-native score increases. Not all runtimes must move upward; components that directly interface with hardware may justifiably remain on bare metal. In cases where a runtime must move down a level, record the absolute change.

At the end of this exercise, you will have a list of sub-domains, their current cloud-native score, and their desired cloud-native score.

Armed with this data, you can slice and dice it on factors such as cost savings, solving a business pain, implementation effort, training time, stakeholder support, and so on. This analysis enables you to prioritize initiatives, define a technical roadmap, and communicate it effectively to stakeholders. You may also formalize progress by defining OKRs, with key results focused on improving the cloud-native score from one level to another.