Those who design and build cloud applications already understand the importance of exploiting the native features...
of the cloud platform, such as AWS and others. This means you write an application to the strengths of the platform, and don't try to be all things to all clouds.
Each cloud provider has its own way to leverage its native features. Typically, you can access these features via layers, including the topmost virtual platform/OS and underlying resources (such as storage and data), and then the cloud-native services, such as provisioning and tenant management. Tenant management provides the ability to share the physical and virtual resources within the cloud with those who are leveraging the cloud services, or tenants.
The reasons you exploit cloud-native features include:
- Performance. You're typically able to access the native features of the public cloud services to provide better performance than non-native features. For example, the ability to deal with an I/O system that works with an auto-scaling and load-balancing feature.
- Efficiency. Cloud-native applications leverage the cloud-native features and APIs, which should provide a more efficient use of underlying resources. This means that the application's impact on the underlying hardware and software is better managed, and thus you have good performance (see above) and less cost (see below).
- Cost. Since you're building applications that are more efficient, they typically cost less to run. Cloud providers, including AWS, send you a monthly bill based on the amount of resources you consumed. If you're able to do more with less, that translates directly into dollars saved.
- Scalability. Since you write the application to the native cloud interfaces, you also have direct access to the auto-scaling and load-balancing features of the cloud platform.
To take proper advantage of a cloud platform, including IaaS and PaaS, you have to design the applications so they're decoupled from any specific physical resource. Of course, clouds can provide an abstraction or virtualization layer between the application and the underlying physical (or virtual) resources, whether they're designed for cloud or not. But that's not good enough.
When this architecture is considered in the design, development and deployment of an application, the utilization of the underlying cloud resources can be as much as 70% more efficient. This cloud computing efficiency equals money. You pay for the resources you use, so applications that work more efficiently with those resources run faster and generate smaller cloud services bills at the end of the month.
However, there are tradeoffs in cloud-native application development and design. Those tradeoffs should be considered before you bind your application to a specific cloud provider, including AWS.
The biggest tradeoff is that you're giving up portability for the advantages of being cloud-native. Applications that are "localized" for specific cloud platforms are not portable to other cloud platforms without a great deal of rewriting or refactoring of the code.
Many developers are getting good at placing the cloud-native features of an application into a specific domain of the application design. This allows them to easily change the application for other cloud platforms, if needed. These good application design practices are not at all common. Most developers exploit the cloud-native interfaces systemic to the application; those are much harder to change.
My best recommendation is that you at least consider cloud-native application development approaches and best practices, if not for efficiency, perhaps for cost or performance. While there is a clear tradeoff in portability, the benefits can outweigh those tradeoffs pretty fast if you run that application for more than just a couple of years.
How scalable systems are helping developers build apps