Levers to improve the frequency of iterations and time to value - Cloud-Driven Enterprise Transformation on AWS

Levers to improve the frequency of iterations and time to value

Without hard timelines or top-down aggressive goals, teams often lack a sense of urgency or clear deadline to complete their cloud transformation. This contributes to an extended period of “dual operations”. As long as the longer product or portfolio teams are operating across two or more platforms, an extended period of increased complexity is created. There are many levers to increase the frequency of iterations and accelerate time to value. Some common AWS best practices are as follows:

  • If you can’t decide on a migration path, pick the easy one — If you can, migrate with minimal refactoring, then continue transforming on AWS. It is easier, quicker, and simpler to tune, experiment, or transform architecture on AWS. Evaluation of performance data will also inform what theoretical configuration changes may be effective, and changes can easily be scrapped if they are not performant or cost effective. Pace yourself and your teams, and adopt a crawl-walk-run mindset on design decisions and operational capabilities. Create an optimizations log for phases post cutover.

  • Consider the automation path — Use the CloudEndure rehosting pattern or the VMware Cloud on AWS relocation pattern for non-differentiated workloads with low rate of change and low modernization value potential. Those workloads can still be re-factored once on AWS. This can create capacity on-premises, help avoid hardware refresh cycles on-premises, de-risk your migration, and focus limited skilled resources on re-deploying or re-factoring workloads with high value potential.

  • Address vendor applications early in the process — There is widespread inclination to leave vendor applications, whether vendor-installed or customer-installed, until the end of the migration. A better approach is to schedule necessary vendor support and begin vendor-installed application migration at the start of the migration. In all but the most complex installs, vendor applications can be decoupled from other work and single-threaded after the initial build is well documented. Identification of dependencies early in the process is the key to avoiding a “pile-up” of work at the end of a team’s migration journey. These dependencies include contractual due diligence, obtaining vendor commitment for the migration timeline, evaluating automation opportunities to reduce time to deploy, and dependencies on single resources.

  • Build consistently by building on initial builds for all environments — Parallelize build and automation to “build faster”. Keep the architecture consistent from development through non-production to production for the first deployment. After cutover on AWS, the environments can be optimized to reduce costs. Keeping consistency across builds removes a number of variables and greatly accelerates the path to production. Application cutovers in production is key for migration factories. Be sure to follow up by deprovisioning and/or right-sizing lower environments after successful cutover to ensure costs are optimized.

    When you need to “build faster” to stay within a specific time frame, parallelize paths for infrastructure build, application deployment, testing, and automation. After the design is completed, this process allows the infrastructure as code with AWS CloudFormation Templates (CFT) automation and the application installation, configuration, and testing to occur in parallel. Specifically, the first development build of the infrastructure can be deployed manually, and the application teams can begin test deployment in Dev immediately. While the application teams are developing the initial install pattern, the infrastructure code can be automated using a CFT deployed by the pipeline.

    With the consistent build deployed in non-production, the application teams can deploy incremental automation for configuration and code deployment. At the end of this stage, testing can be run on the full stack installation. After all use cases and UAT is validated and documentation is complete, the production build can replicate the non-production procedures, then final validation and cutover can be implemented. This enables teams to move more rapidly and complete more work in parallel than with a purely sequential staging strategy.

  • Borrow a monthly cutover window from application teams for migration testing — Planning far ahead for validation and release planning and getting business buy-in will solve a lot of problems. With enough advance notice, developers and testing engineers can plan accordingly and avoid conflicts with test resources schedules, which may be the biggest risk to schedule slip when test resource conflicts arise. Additionally, developer and test teams, with enough runway, can plan incremental automation of build, configuration, and testing steps to land in a more resilient posture on AWS, moving to infrastructure as code, adding auto-scaling groups, and reducing manual deployment procedures.