Many businesses are looking to migrate their applications so they can run on a public cloud platform, however, what most do not realize is there are multiple ways to accomplish this task and which one you choose will impact costs to develop, maintain and operate. The problem for many of these businesses is that there isn’t currently a strongly-adopted taxonomy for cloud applications architecture that allows them to compare and contrast options. To that end, I’ve come up with a taxonomy that I use when talking to customers: cloud native, cloud adjacent and cloud derived.

Cloud Native

While I debated early the merits of the term “cloud native” (see: Virtual Roundtable: The Role of Containers in Modern Applications“) the term has become synonymous with microservices running in a containerized platform. Cloud native simply defines a scale-out architecture that leverages distribution of a service across multiple physical nodes and a routing service that distributes load across those nodes. Many existing legacy applications can be migrated very quickly shifting them from scale up to scale out. The benefits of this approach are easier maintenance and lower cost to operate since many of these are moving from dedicated hardware platforms.

Cloud Adjacent

A cloud adjacent architecture is one that leverages cloud services, such as database, AI, content distribution, etc. in combination with an existing application architecture. The existing application could be any application that make REST-based API calls to the public internet. These applications can reside in on-premises data centers, SaaS-based applications, integration engines or migrated cloud-native applications. The key for cloud adjacency is the use of public cloud services.

Cloud Derived

A cloud derived application is one that is developed completely using non-infrastructure-based public cloud services. There are a number of ways to build a cloud derived application. For example, serverless compute engines, such as AWS Lambda or Azure Functions. Another method is called pipelining, which is calling one cloud service based on the execution of another cloud service. An example of this might be writing a record to a database when a message arrives via email. Microsoft Power Automate (previously Flow) or IFTTT (If This Then That) are popular cloud services with many connectors to other applications and services that facilitate this action.

Many will argue that cloud native offers the maximum level of protection from lock in, but I believe that cloud adjacent offers the best ability to limit lock-in while offering a cost-effective approach to application development in the cloud. Cloud derived, however, typically offers the lowest cost-of-operation since it is completely based on consumption.

Leave a Reply

Your email address will not be published. Required fields are marked *