A: Turn-key solution? Definitely not! Any IaaS implementation inherently cannot be a turn-key solution, since it only accounts for management of the underlying infrastructure, and not the custom application environment built on top of it. What do we mean by the underlying infrastructure in terms of Amazon? This would include:
- The facilities that house the hardware
- The combined hardware on which the cloud is realized
- The intra- and inter-networking of these facilities
- Supported Amazon Machine Images (AMIs)
- Adherence to licensing for operating system and other general software
- Personnel required to ensure support, operation, and uptime of the AWS products and services as specified in the Amazon SLAs
Note
Please note that Amazon provides AMIs that come pre-packaged with default Windows operating system installations. Windows licensing costs are bundled into the cost of using these specific AMIs. Amazon also provides AMIs pre-packaged with Windows and SQL; in these cases, Windows and SQL licensing are bundled into usage costs. However, this is the current extent to which Microsoft products come pre-packaged. Amazon only supports the default operation and condition of its AMIs; any customization/configuration is the customer's responsibility, as is any additional software installation and adherence to that software's licensing requirements (this means SharePoint).
Amazon provides your organization with the tools and the capacity to realize your vision. However, it is still your vision and it is up to you to realize it. Amazon does not manage your custom application infrastructure, and it is important for you to clearly understand this demarcation point.
As an aside, this is particularly important in terms of business continuity. Amazon provides general guidelines for highly available, redundant architectures, but does not enforce that you build them. It is up to your organization to do the appropriate amount of research, decide on an acceptable level of cost versus risk, and deploy in accordance with best practices. To reiterate, in an IaaS environment, most of the responsibility falls on your organization, so make sure you've exhaustively evaluated your proposed architecture. The success of your deployment heavily depends on adequate preparation, planning, and foresight.
In terms of a SharePoint deployment, you have to look at the architectural panorama. Understand all of the architectural pieces involved, how they need to integrate together, and what you have at your disposal to make this happen. Try to separate and envision your overall infrastructure in three layers:
- Amazon infrastructure
- Windows infrastructure
- SharePoint infrastructure
Your Amazon infrastructure will consist of the type of cloud you choose to deploy, the virtual networking topology you choose, security filters that you institute, the base AMIs you choose to deploy, and settings specific to any of the Amazon products that you choose to utilize. This layer needs to be approved and architected first, as ultimately the rest of your deployment will depend on a sound Amazon infrastructure.
The following figure highlights some considerations at the Amazon infrastructure layer of a SharePoint 2010 deployment:
Once your Amazon infrastructure is ready, you can move on to architecting all of the supporting Microsoft infrastructure services that SharePoint will need. This will include configuring all of the server instances created from the AMIs, integrating with Active Directory Directory Services (ADDS), building a sound DNS topology, determining and implementing the appropriate authentication and authorization mechanisms, integrating with monitoring, backup, antivirus, and other infrastructure management services.
The following figure highlights some considerations at the Windows infrastructure layer of a SharePoint 2010 deployment:
You've finally reached the application layer of your cloud-based deployment roadmap. The Amazon infrastructure is available, your Windows infrastructure has been provisioned, and it's time to finally focus on the actual SharePoint deployment. At this point in the game you are ready to dive into capacity planning, authentication requirements, service application scaling, SharePoint security, and so on. Basically, it's time to apply everything you learned about in the previous chapter and more. Of course this is not an isolated exercise; there will be dependencies and constraints that will be dictated by or will directly impact the Amazon and Windows infrastructure layers. Be careful of the decisions you commit to. As an example, consider geographically distributed SharePoint farms. Although discussed as part of the overall SharePoint topology, this is a concept that would require architectural decisions at all three layers. If certain choices were already made and paid for at the Amazon and Windows infrastructures, then the SharePoint topology would be subject to these constraints, or the supporting layers would be subject to a re-architecture. Either way this would be a costly proposition.
The following figure highlights some considerations at the SharePoint layer of a SharePoint 2010 deployment:
