You have a legacy application that is not so friendly for cloud platforms like AWS. Let us work together to re-architect it and turn it into a cloud-native application in the most cost-effective way.
Several organizations are wondering (and sometimes struggling on) how to port their current workloads to cloud environments.
One of the main characteristics of a cloud environment is that the infrastructure is provisioned dynamically. This implies, for example, that we don’t know a priori where our resources are being allocated (we can find that out, though). VMs or containers will receive a dynamic IP. Storage will be allocated somewhere and attached to our VMs or containers and so on.
So, how should we design our applications to cope with this dynamicity?
None of these cross-cutting concerns need to be addressed immediately when your application is migrated to the cloud. It is therefore possible to organize the migration of workload to the cloud as a set of incremental steps in each of which more and more architectural concerns are addressed and more and more benefits are gained.
Building on the shoulders of these giants, here is a list of cross-cutting concerns that a cloud native solution should address:
- Service discovery
- Load balancing
- Configuration Management
- Data and state management
- Log aggregation
- Distributed tracing
- Fault and Latency tolerance
- Feature Toggles
- Health checks