Knowing the Best Practices, FAQs, and Common Pitfalls
Incorporating a new service into the enterprise infrastructure landscape is not easy. A lot of factors must be considered to make the project a success. In this chapter, you will learn how to make the adoption of VMware Cloud on AWS as smooth as possible.
The following are the topics to be covered in this chapter:
- Best practices
- Avoiding common pitfalls
- FAQs
Best practices
When you are designing, implementing, and operating a service, it’s vital to follow common best practices to prevent performance, availability, and security issues. In this section, we will summarize the most common best practices for VMware Cloud on AWS.
Design and architecture
A solid design is the basis for successful implementation and a positive user experience. Never start deploying the service before completing the design phase. Once production workloads are running on the SDDC, it will be very hard to redesign the implementation without affecting the user experience. Most production outages occur in infrastructures that are deployed without a proper architecture design.
The standard industry flow for the design and architecture phase is as follows:
- Discovery workshops with key business and technical stakeholders
- Key design decisions
- Logical and physical design
- Implementation
Let’s see more details about each of these activities in the following section.
Discovery workshops with key business and technical stakeholders
This is one of the most important steps of the design phase. Failing to properly collect and document key requirements, along with risks, constraints, and assumptions, may affect the implementation of the whole service. For example, if an organization has a strict deadline to migrate workloads from a data center but you fail to check whether a direct connect is available for the project, it may not be possible to accomplish the migration in the required amount of time. Or if a organization has workloads with hardware accelerators or an extremely high number of input-output operations per second (IOPS) and you did not properly identify them, you might not be able to migrate and/or meet performance SLAs later on, leading to project suspension.
As a result of discovery workshops, your team should have a clear understanding of the business and technical requirements. These will be the foundation for your design, and you should ensure the new cloud infrastructure can meet all of them. Here are some typical examples of the requirements for the hybrid cloud platform:
- An example of a business requirement – a new platform must guarantee four nines of availability (99.99%)
- An example of a technical requirement – a new platform must be able to host VMs with up to 256 GB of RAM
In addition to requirements, you should capture constraints and document assumptions. Assumptions may pose risks to the project by affecting timelines or making some of the requirements not achievable. Your design should provide a clearly documented risk mitigation procedure.
The following examples illustrate possible constraints, assumptions, and risks:
- Constraints:
- Some VMs use Raw Device Mapping (RDM) to support Windows Server Failover Clustering
- Direct Connect is available but does not support the MaCsec feature
- Assumptions:
- Technical personnel will receive adequate training to ensure proper Day 2 operations of the service
- The networking team will be able to implement the required networking changes in a timely manner
- Risks:
- If network configuration cannot be completed by the defined timeline, migration of the workload will not be possible
- If the training budget is already exhausted, necessary technical training must be provided as a part of the project, possibly increasing costs
All requirements, constraints, assumptions, and associated risks must be clearly documented and acknowledged by the project’s stakeholders. You may find some of the identified requirements might be overwritten by senior management or even completely removed. It’s not uncommon to see every application team requiring the highest possible availability for their application service even if only 15% of the application’s workload is considered mission-critical.