甚么处所不适合云计较(对Picnik而言)

picnik其实不将ec2用于web服务器和mysql数据库服务器器。咱们的web服务层与数据库是严密耦合的，以是使它们之间的网络延迟最小化是很首要的。这象征着它们要末全在云里，要末全在云外。直到比来，ec2的磁盘i/o机能一直不抱负，以是有须要将数据库放在理论(且特制)的硬件上。跟着amazon rds(运转在ec2上的 mysqli的打包版本)的推出，情况能够会有改动。
虽然数据库机能达不到运转在理论服务器上的高机能，我也想试一下，用ec2实例作为数据库子机(slave)，这些子机可以用来做备份，也能够用于生成报表或运转其余批处置功课。
amazon初期提供的云服务短少负载平衡威力。虽然在ec2实例上实现必然水平的负载平衡也是能够的，但要超过一大堆障碍才气到达适量的可用性。末了 amazon推出了负载平衡器，从而免去了这些挂念。
云计较景致缤纷，变革疾速。咱们起头做picnik时，提供云服务的公司百里挑一，并且也都是没有颠末实践测验的，以是咱们决议仍是运转本身的服务器。假设咱们是在今日起头picnik的话，咱们的做法在很洪水平上就会差别。
虽然有大量广告吹捧完整托管在云里的应用怎样，从运维的角度来讲，混淆应用架构或许是最乏味的。混淆架构中，你可让大部分应用都托管在云里。
网站制作的管理和监控是有用实现自动伸缩的根蒂根基。混淆应用还强调了一点，就是传统运维中的最好实践依然是胜利的云应用所必需的。设置少文件，如许就可以提早意想到那些潜在的问题。监控云里的单个实例是不须要的，由于连接性很差。首要的是高层怀抱，如s3上存储了多里做得没必要然好。脚踩两只船，你才会熟能生巧。除非你有充沛的理由，不然的话，争夺运用最好的工具。