Picnik并不将EC2用于Web办事器和MYSQL数据库办事器器。我们的Web办事层与数据库是慎密耦合的，所以使它们之间的收集延迟最小化是很主要的。这意味着它们要么全在云里，要么全在云外。直到比来，EC2的磁盘I/O机能一向不睬想，所以有需要将数据库放在现实(且特制)的硬件上。跟着AmazonRDS(运行在EC2上的MYSQLI的打包版本)的推出，情形可能会有转变。

固然数据库机能达不到运行在现实办事器上的高机能，我也想试一下，用EC2实例作为数据库子机(slave)，这些子机可以用来做备份，也可以用于生成报表或运行其他批处置功课。

Amazon早期供给的云办事缺乏负载平衡才能。固然在EC2实例上实现必定水平的负载平衡也是可能的，但要跨越一年夜堆障碍能力到达恰当的可用性。最后Amazon推出了负载平衡器，从而免除了这些挂念。

云盘算风景缤纷，变更快速。我们开端做Picnik时，供给云办事的公司寥若晨星，并且也都是没有经由实践磨练的，所以我们决议照样运行本身的办事器。假如我们是在今天开端Picnik的话，我们的做法在很年夜水平上就会分歧。

尽管有年夜量告白吹捧完全托管在云里的运用若何，从运维的角度来说，混杂运用架构或许是最有趣的。混杂架构中，你可以让年夜部门运用都托管在云里。

网站扶植的治理和监控是有用实现主动伸缩的基本。混杂运用还强调了一点，就是传统运维中的最佳实践仍然是胜利的云运用所必需的。设置装备摆设少文件，如许就可以或许提前意识到那些潜在的问题。监控云里的单个实例是不需要的，因为连贯性很差。主要的是高层器量，如S3上存储了多里做得纷歧定好。脚踩两只船，你才会游刃有余。除非你有充分的来由，不然的话，争夺应用最好的对象。