提到阿里云，多数人想到的是双十一扛住的流量、各地的数据中心，还有面向企业的一整套云产品。但把时间往回拨十几年，会发现它的起点并不清楚，一路走来也没有人一开始就规划好了路线。弄清阿里云前身是怎么来的，能看到云计算在国内是怎样从公司自己的需求，慢慢变成对外提供的服务。
大促让旧架构吃不消
2008年前后，淘宝和支付宝的业务量涨得很快，商品、交易和访问都在往上翻。那时的主流做法是靠小型机、商业数据库和集中式存储撑场面，圈内常叫它IOE架构。它稳，但扩容慢，一台设备从采购到上线可能要等好几个月。流量一拐弯，机器就跟不上。
最让技术团队头疼的是大促。活动前要提前几个月估算容量，然后把设备成批买回来。活动一结束，这些资源大部分闲着，利用率上不去，成本却一直在涨。对一家想把业务做大的公司来说，这样的节奏很难长期撑下去。
先在自己家里跑通
阿里巴巴开始尝试用普通服务器搭分布式系统，靠软件调度代替昂贵的专用硬件。这条路当时并不好走。普通机器故障率更高，系统变复杂，工程师要处理以前不用碰的问题，比如数据一致性、节点挂掉后怎么自动恢复，以及不同业务之间怎么隔离资源，互不干扰。
团队的做法比较稳妥，先在内部验证。例如，把一部分离线计算任务迁到自研的分布式平台上，然后看成本、效率和稳定性各自有什么变化。规模慢慢变大，平台开始承接更多在线业务，内部的“云”才有了雏形。这个阶段的目标很实际，就是让自己的业务跑得更稳、花得更少，还不急着对外卖。
2009年，内部工具变成对外产品
2009年，阿里云作为独立业务单元正式成立，总部在杭州。它一边服务集团内部的电商生态，一边开始尝试给外部开发者和中小企业提供计算能力。这一步的难点在于，内部工具只要自己能用就行，对外交付却要把计费、售后、安全合规和多租户隔离都想清楚。同一台机器上住着不同客户，一家的流量高峰不能拖垮另一家，这件事必须从设计阶段就考虑进去。
对外开放之初，客户愿不愿意把数据放上来，往往比技术本身更难跨过去。很多企业习惯了自建机房，对公共云的数据安全有顾虑。阿里云的思路是先从门槛低的场景切入，比如网站托管、数据存储和开发测试环境。一些初创团队可以按需付费，不必一次性买下大批硬件，就能先把产品上线。这些早期用户的反馈，又反过来推着产品往前改。
前身经验能用在哪
回头看阿里云前身的发展，有几条经验对正在做技术选型的团队比较直接：
- 先看业务压力：如果资源长期闲置、扩容周期又长，才有必要动基础设施。别因为概念热门就跟着换。
- 内部先跑一个小场景：挑一条离线任务或一个非核心模块先迁移，记录成本、效率和故障数据，再决定要不要推广。
- 用软件调度补硬件：通过分布式架构和智能调度提高资源利用率，适合流量波动大、峰值明显的业务。但要预留处理一致性和故障恢复的人力。
- 对外交付先看计费和隔离：客户最先关心的通常是账单是否清楚、上手是否简单，以及别人的流量会不会影响自己。
今天的云计算已经相当成熟，但不少问题换了形式还在。成本和弹性之间怎么平衡，数据安全和开放协作之间怎么划线，当年的探索者也一样要面对。把这段历史当作参照，比单纯记住几个时间点更有用。
