Making Effective Decisions for Your V1 AWS Design

In reviewing your existing business application portfolio to create V1 AWS designs—the first architecture design for moving to AWS—we must address two main factors that often inhibit progress:

1. Your technology teams must find a clear path forward that balances modernization and migration.
2. You must provide clear criteria to transform your platforms and also continue to deliver new business capabilities (such as feature releases) on existing systems.

We have found that having an established, efficient decision-making process is critical to accelerating cloud adoption and implementing a V1 AWS design. This process will be successful if you take an approach that balances speed, addresses technical debt where it inhibits modernization, and defers lower priority optimization until after deployment on AWS.

This blog will show you how to determine a clear path for V1 deployment on AWS and make effective decisions regarding the degree of transformation in application and infrastructure architecture, configuration, and the degree of incremental deployment automation when moving applications to AWS.

V1 AWS design strategy

Along with the seven common migration strategies for moving applications to the cloud (the “7 Rs”), these additional strategies are also useful when creating V1 architecture:

1. Move, then optimize. Move quickly with traditional “lift and shift” to capitalize on immediate run cost savings, then optimize in the cloud. Identify longer term modernization and refactoring opportunities during design review. Then place them in the backlog to address after migrating to AWS. In some cases, systems that are planned for run-out in 3 to 5 years might benefit from migration to a co-location facility adjacent to an AWS Region. This means dependent, cloud-ready workloads can move before rewriting systems to resolve dependencies.
2. Modernize what matters. If priorities and resources are aligned, invest in incremental or full modernization depending on the business value, technical debt, and other priorities. Begin evaluating opportunities to resolve structural dependencies on legacy workloads, including high technical debt systems and common mainframe and midrange systems. Retire, re-purchase, retain, or refactor these legacy workloads based on business need.
3. Minimal optimization. To fix problems stopping you from moving faster, upgrade or renew outdated technologies across the full stack. Additionally, decouple legacy systems to address pain points that slow down development of new capabilities or drag resources into non-differentiated work. In most cases, this also requires close coordination with application, testing teams, and business product owners to determine how far to modernize before migrating to AWS.

Adhering to these three strategies across your business applications portfolio will enable the flywheel in Figure 1 for your cloud transformation.

Figure 1. Cloud transformation flywheel model

V1 AWS design specification

The design decisions you make regarding the degree of transformation in application and infrastructure architecture, configuration, and the degree of incremental deployment automation will manifest themselves in the V1 AWS design. You will evaluate trade-offs to determine what components of operating system (OS), database, application code, resiliency architecture, deployment automation, and services architecture enhancements should be implemented. You must also examine services to be deferred to the backlog for post-migration to AWS optimization.

Many V1 design improvement options are available that teams can implement between lift and shift and full cloud native modernization:

• Upgrade end-of-life (EOL) or near EOL. Earlier versions of OS, middleware, and application components can expose security risks.
• Apply Infrastructure as Code (IaC). Automate infrastructure provisioning using templates, quick starts, and secure stacks available through the AWS Service Catalog.
• Phase in deployment automation. Move toward automated deployments for middleware and application code using a common cloud-based code pipeline with controls built in, and adopt DevSecOps practices or blue/green deployments.
• Use AWS Auto Scaling. Allowing horizontal scaling, instance swaps, and self-healing/auto-recovery mechanisms to automate manual operations tasks.
• Increase resiliency. Enable redeployment/failover to another Availability Zone or Region for business-critical applications with resiliency/disaster recovery requirement.
• Enhance data security and protection. Protecting sensitive data for its entire lifecycle, for example through field-level encryption for Protected Health Information.
• Move to managed services beyond Amazon Elastic Compute Cloud (Amazon EC2). This will reduce undifferentiated heavy lifting with managed databases like Amazon Relational Database Service (Amazon RDS).
• Move to containers. Break down monoliths into smaller services and containerize applications for easier management and deployment, starting with components for which Docker images are ready off the shelf.
• Enable opportunistic refactoring. Rewrite particular pieces of your application stack. For example, move event-driven components to serverless (such as AWS Lambda, AWS Step Functions, and AWS Batch), or your proprietary database engine to AWS data stores (such as Amazon Aurora).
• Standardize application layers. Standardize application stack and architecture. For example, consolidate technologies for web/application/middleware layers where minimum refactoring is sufficient (such as moving to an Apache Tomcat shared layer).
• Repurchase. For example, move to software as a service (SaaS) or purchase a replacement from the AWS Marketplace for cloud-based commercial off-the-shelf applications.

Consider these improvements when deploying on AWS. Critical changes should be implemented before migration. Less critical changes can be included in the optimization backlog to address after migration to AWS is complete.

The time and effort to achieve these improvements should be evaluated on how they align with your business needs, available skills, and resources. Then you can evaluate other opportunities to invest in V1 AWS design improvements. Any backlog items can be included in future sprint objectives using a continuous improvement mindset.

Two considerations for implementing your V1 AWS design

Speed over perfection. It is essential to involve all relevant stakeholders and make V1 AWS design decisions quickly. Then, implement the agreed-upon plan and defer remaining optimization opportunities to the post-migration AWS backlog. Cutover to AWS is a “two-way door.” This means that you don’t need belabor or second-guess V1 AWS design decisions. It’s easy to adjust either on AWS (upsize as needed) or fail back and try again.

Pattern-based design approach. Based on customer engagements, we found that over 80% of customer workloads can fit into ~10 to 15 of re-useable V1 AWS design architecture patterns to support application types. After these patterns are designed and approved, let your teams run with them. Teams can tailor and customize as needed, but subject matter experts (SMEs) and lead cloud architects need only to review incremental changes before build teams get started.

Conclusion

In this blog, we show you how to make effective decisions to accelerate the transition and improve speed to market for new capabilities. Without clear goals and business ownership, teams languish in decision paralysis—they can do nothing and leave their system on-premises, move as-is, or complete refactoring. Having a clear V1 design process and clear ownership of the decision-making will empower stakeholders, which is critical to taking the first step and moving with speed. We encourage you to empower your teams to make these decisions, move quickly, experiment, and fail.

Further reading

More guidance on scaling and accelerating your company’s cloud transformation can be found in the AWS whitepaper on Cloud-Driven Enterprise Transformation on AWS.