题记：对于CT方案来讲，要奖赏那些敢于说Yes的架构师，因为CT的问题明眼一看就能体现难度，通常在困境的时候能有人指出一条明路是难得的；而IT领域的方案，要多倾听对方案的批评建议，因为IT的方案只要被提出来再不济技术上也是可以行得通的，但是方案可实施性、可复制性、落地成本和维护上的坑，却只有真正经验的技术者才能识别并勇于指出来，来规避产品交付的风险。
AWS的混合云产品Outposts从2018年11月提出概念到2019年12月西雅图 AWS re：Invent全球大会正式发布上市，一被业界友商、客户和云计算从业者所关注。私有云市场以前对AWS来讲是不承认的，其一直推崇公有云，在2019全年仅AWS云计算业务给亚马逊带来了超过350亿美金的收入。AWS截止到现今，全球越有22个Region，69个AZ，比全球第二大云服务商的要多一倍，服务全球245个国家和地区；其中中国部署有三个Region，分别是北京、宁夏和香港。
（2014-2019年AWS在亚马逊的营收比重）
AWS Outposts将AWS的公有云部分服务，以硬件集成的方式部署到客户本地的数据中心，以实现客户数据本地化归属；按照AWS自己的产品理念，“AWS Outposts 通过提供一个使用与 AWS 上相同的软件、服务、基础设施、管理工具、开发和部署模型的解决方案来消除混合云的复杂性，从而实现一个无缝的混合云解决方案”，“Outposts 支持由于低延迟和本地数据处理需求而留在本地的工作负载，例如电信虚拟网络功能、高频交易、工业自动化、金融服务、医疗保健和其他应用程序”。“AWS Outposts 提供两个版本：1) 在 AWS Outposts 上运行的 VMware Cloud on AWS 服务；2) AWS Outposts：允许客户使用与 AWS 云中相同的本地 AWS API 在本地运行计算和存储。”，“2020 年即将推出 VMware 版 AWS Outposts。VMware Cloud on AWS Outposts 提供在本地 AWS Outposts 基础设施上运行的完全托管式 VMware 软件定义的数据中心 (SDDC)。” AWS Outposts的产品仍然是公有云向客户DC的延伸，由于其公有云产品已经非常完善并且市场占有率/全局布局都非常多，这样可以基于成熟的公有云产品去裁剪得到一份私有云的版本并构成混合云方案，成本相对重新做一套私有云产品比较来讲是非常低的；AWS Outposts概念提出后，就引起了很大的业界轰动，被认为是私有云领域的创新产品理念，也有部分的友商跟随。但是对于使用者客户和跟随者，都应该对AWS Outposts产品理念/能力尤其是相关约束有一个比较全面的了解。
作为AWS Outposts的潜在客户和技术跟随者来讲来讲，需要知晓：
1）AWS Outposts从使用界面来看，租户需要选择部署DC附近想对应特定Region来申请，并客户本地部署的DC提前准备好机架位和风火水电等机房的基础设施；也就是AWS Outposts并不是所有的Region都提供，而只是一部分才提供（截止目前，总共有15个，其中美国有4个，加拿大1个，欧洲5个，中东1个，亚洲5个其中包括香港的Region，也就是说北京和宁夏的Region没有提供）；对于客户申请一个对应DC的Outposts局点，在AWS对应Region上会可视看到增加了一个对应的AZ；从VPC实用角度叫，客户VPC是可以跨对应Region的多个AZ以及该Region下该租户所有的Outposts局点的；对于云服务商跟随者而言，如果想对客户提供对应的类似产品，就必须有对应的公有云Region建立，这个是硬性条件，而且国内的所有做公有云的厂商就全球布局而言相比AWS/Azure/GCP等能力都还有极大的差距，即海外没有公有云Region的话根本没法提供类似AWS Outposts的产品服务，更不要说及时对客户问题处理和故障排除等相关方面的快速响应能力。
2）AWS Outposts的软硬件是一体机承载的，不允许客户使用第三方的服务器等硬件做异构方案，并且禁止客户对AWS Outposts的软硬件提出定制的需求；而在AWS Outposts中，云服务包括基础特性（比如ECS的规格、存储能力等）、容器/数据库服务的种类等都是公有云里较少的一部分，也就是云服务种类做了很大裁剪；这一点对客户来讲，私有云相关设备的采购流程（尤其是大规模竞标采购的大客户）是否能改动需要提前明确，否则需要认可采购一家设备软硬件全中标的做法；而对于跟随云服务厂商来讲，需要有软硬件一体的能力，包括服务器、交换机、存储设备等。
3）AWS Outposts在客户DC部署后，需要有一根***或专线的网络连线打通与对应AWS Region的管控面、数据面及运维面，并且通过该网络接收AWS云服务提供的7*24小时运维/升级服务，并且在故障时会通过该网络在15分钟内提供支撑；对于租户而言，也就是AWS Outposts的客户仍然要信任公有云服务商，这里类似邻居老王有你银行卡的密码，你所有的银行操作他都能看到，只是他承诺不会动银行卡里的资金；对客户而言的另一个问题是数据内安全合规和等保要求，很多国外对数据监管比较严格，甚至连运维/敏感日志数据不出境等，所以对AWS Outposts的对应Region提供该产品是有一定要求的；对于跟云服务商随者而言，除了前面说的要提供对应当地的Region外， 还要提供对应的本地7*24小时的及时响应团队，以面对客户本地DC部署据点的故障发生和维护问题，另外还要有较好的网路***服务或专线连接能力，为此有必要和全球较多的本地专线服务提供商进行合作。
4）AWS Outposts产品属于新理念的私有云产品，和传统的私有云本地部署/本地运维/本地升级/本地运营的方式有很大不同；对于客户而言，基本会存在对以前大量虚拟化产品的资源池或第三方私有云云平台的资源池，AWS对这些资源池的延续性并不负责，需要客户自己提供相应的迁移或协作能力（猜测这块很快会有创业公司或集成商来提供解决方案），VMware提供VMware on AWS Outposts的部署，一定程度上是解决了该问题，但是只能针对VMware的资源池，而客户业务在AWS Outposts在自主升级或按需升级时，对自身业务影响的评估和适配，否则会导致AWS Outposts升级流程对客户业务带来不可评估的潜在影响；对云服务商跟随者而言，需要考虑这种方式的客户接受度是否真的认可（从国内外多位云计算业内人士沟通得到的观点来看，国外客户还在犹豫和识别，而国内客户在国内数据保护的情形下更为特殊，很难接受该方案），因为这个决定了该产品在私有云或混合云所能有的市场空间，而AWS纵然该产品失败了仍然有公有云可以持续大量的营收，每个跟随者要考虑自己的情况；
5）AWS Outposts产品只提供了软硬件一体机设施，相应租户需要有相关的人员参与该产品的培训并深入理解，才能对一定规模的AWS Outposts物理组网进行设计，这里的交换机可以使用第三方设备的，不过要满足能够提供对AWS Outposts管控面/数据面/运维&运营面的互通，并且能够在访问本地的数据中心其他资源池和本地数据中心出口的互联网能力，并且对于故障后对于上门人员支撑的服务购买以及流程机制的适配：而云服务商跟随者而言，除了在公有云提供类似产品的网络互通能力外还要提供相应产品的培训和资料，并提供和网络设备商做集成交付的能力。
AWS Outposts的混合云方案本身并没有好坏，作者个人也并不认为有太大创新性，只是按照自己全球公有云布局能力的一个到客户DC的能力延伸，有自己的积累背景和产品理念，而其他云服务商没有AWS规模积累的情况下，提供类似方案的私有云方案会对自身产品有较大颠覆，客户接受度也颇有挑战。但是也有类似Azure等混合云提供部署到客户DC局点的可选连线方案。IT技术并没有什么行不通，但是要考虑业务连续性、客户接受度以及产品复制能力，否则必将是一个失败的产品，并带来云服务提供商在相应领域布局的失败。
