There are quick ways to move an application to the public cloud. These ways might not be optimal – i.e. taking advantage of cloud-native features – but they get you to the cloud. With cloud infrastructure, you trade capital expenses for operational expenses and have new ways to look at scalability, reliability and security.
Two of the ways applications are moved to the cloud are:
- Re-hosting (i.e. Lift and Shift)
- Re-platforming (i.e. Lift, Tweak and Shift)
Both methods can get you to the public cloud quickly. But be sure to revisit an application’s architecture after moving it to add resilience and cost savings. While all applications are different, the first step in transforming an application to be more cloud-native is to focus on the following two areas: Foundational Application Constructs and Application-Specific Design.
Ways to make your application more cloud-native
1. Foundational Application Constructs
These include:
- Logging (Trace/Error)
- Auditing (user actions/events/service invocations/etc.)
- Queueing
- Workflow Framework
- Authentication / Authorization (Claims)
For example, applications are made up of multiple subsystems (website, API services, application tier, etc.). Each subsystem usually logs to local storage. But by unifying all logging in a standard JSON format consumed by one service (e.g. CloudWatch), consolidated log analysis may be achieved. Adding a trace ID or identifier through each subsystem enables log/error tracing through the entire invocation call or time period.
2. Application-Specific Design
While this may be unique to each application, good application design should include the loose coupling of smaller subsystems to build the needed functionality. Common areas to analyze include the workflow of synchronous/asynchronous and stateless/stateful communication between subsystems. How these subsystems communicate with each other may vary when layering in public cloud features (e.g. Loose Coupling with serverless technologies).
Example: Invoke Loose Coupling Techniques
- Lifted and shifted technology: Driven by a timer, a subsystem’s cache is refreshed from a relational database.
- Cloud-native functionality: When the database is modified, cache file is dropped to an S3 bucket. Lambda function is invoked on data-write to S3. Lambda function calls REST endpoint on Subsystem to refresh cache.
During your elevation to the public cloud, many decisions must be made around existing applications. While these may be rewritten to be cloud-native, sometimes the right business decision is to get it all out to the public cloud first, and reconfigure the application’s architecture later.
Have questions on which is best for your organization—lift and shift or rewrite to cloud-native? Please don’t hesitate to reach out to the experts at Anexinet for help with this important decision.
Share on 
