21世纪初期，亚马逊的应用臃肿不堪，经常导致服务不可用，贝索斯受够了这一切，强行规定应用必须通过web service接口来交互。同时推行新的准则“谁构建，谁运行”，团队的职责不仅仅是构建应用，还得让它在生产环境中跑起来，而不是像过去那样，把应用扔给其他团队。

亚马逊很快让应用扩展来支持快速的增长，在这个过程构建了AWS。 其他的公司纷纷想仿效亚马逊的成功。

亚马逊通过应用快速的规模化来支撑业务的发展，在这过程中打造出了一套web service服务（AWS）。其他公司也想复制它的成功，但这并不件容易的事。你需要面临组织架构需要大幅的调整，用户需求延迟交付，团队重组等等问题。但回报也是明显的，团队会比以前更快的实现交付。

那么，组织如何来拥抱“谁构建，谁运行”呢？

“谁动了我的奶酪？”：组织架构变更

构建云应用的第一步就是创建跨部门，多功能产品团队。没有专门的角色区分开发，测试，运维，系统管理员，dba等，但这些技能产品团队必须全部拥有。团队之间的依赖往往让人头痛，想象一下，团队完成了所有的工作，准备发布了，却发现数据库的脚本还需要数据团队来验证运行，你除了干等，别无它法。多功能团队消除了这样的瓶颈，团队成员可以自己来验证脚本，而无需依赖数据团队。

那是好事情，发布devops年度报告的团队研究表明，如果由外部团队来审查代码质量，还不如不审查。因为没有带来任何的质量改进。 一种有效的审查方式是结对审查，会带来更好的交付质量。因此，审查团队需要和产品团队更紧密的合作，变成团队的一员，这样的审查才能带来效果。

不要拖延客户的功能

Zynga是一家社交游戏公司，它的产品Farmville在facebook上发展非常迅速。但公司没有专注于快速满足用户需求，反而选择完善基础IT架构。放弃使用AWS，选择构建自己的云。最终没有成功，又重新选择了AWS。 但公司失去在手机端爆发性增长的最时机。

打造面向产品团队的组织并不意味着要从头开始构建基础云架构。 首先，用web service来构建云应用被证明是可行的，云服务更关注如何为软件提供良好的运行环境，而不是软件本身。其次，产品团队可以专注于产品本身，加快了创新的速度。 聚焦于用户需求而不是内部需求导致用户功能能快速的交付。

当你的巨无霸应用还要增加功能时，试着单独构建这部分功能，并且提供web service接口。巨无霸应用通过接口来调用功能。通过这种方式，使得你关注与你所擅长的：构建应用。应用运行的环境则交给云平台去处理。不要试图自己去搭建云平台，那样会耽搁用户功能的交付，用户会不满，从而影响你的商业目标。

改变是可怕的

让组织能持续产生有效改变的的唯一办法是让改变本身变得有吸引力。 改变是必须的，问题不是如何来改变，而是让团队想要改变。答案很简单：奖励那些投入并且驱动改变的。那些拒绝改变或者旁观的人最终会看到成效并做出选择。

为了成功，你需要一个变更催化剂。 所以，只要团队采用新的方式构建，交付应用的，立即给与奖励。当人们看到奖励了，偷懒的人会跟进。

但是，这不是可持续的方法。团队需要明白他们能做的更好，更快。 那就是自我实现，这是一个更有效的奖励系统。当团队看到自己的产品发布越来越快，并且更少的故障，他们会全身心的采用“谁构建，谁运行”原则。

亚马逊在2000年早期就采用了“谁构建，谁运行”的哲学。从那时开始，公司内部经历了组织架构的调整，面对延迟交付的无谓的害怕，让成员相信拥抱变化。 一旦你像amazon一样学会了有效处理这些问题，你会更容易的转向云应用，并且获得更多的回报。

In the early 2000s Jeff Bezos mandated that all applications at Amazon offer web services that other applications could use to access data and functionality. At the time, Amazon was struggling with a ponderous, unwieldy group of applications. Downtime was an issue, and Bezos had had enough.

Amazon not only rapidly scaled its applications to support growth, it accidentally built Amazon Web Services (AWS) along the way. It’s no surprise that other companies want to duplicate its success.

But it’s hard. You will dramatically change your org chart, run the risk of delaying functionality that customers are demanding, and say goodbye to many employees who don’t get onboard. The reward is clear, however: Your team will be able to deliver improvements faster than ever.

Here’s how to embrace “you build it, you run it” in your organization.

‘Who moved my cheese?’: Changing your org chart

The first step in building cloud applications is creating cross-functional product teams. No longer do you have dev, test, ops, system administrators, and DBAs. You have product teams that encompass those roles and skills.

One of the most frustrating aspects of application release is waiting on external teams to complete tasks that are blocking you. Cross-functional teams eliminate this bottleneck. For example, instead of waiting days or weeks for an external data services team to review an SQL script for execution, the product team can review and execute the SQL script themselves. Goodbye, waiting.

That’s a good thing. The research team behind the State of DevOps report found that companies with zero review prior to application pushes had the same IT performance as companies that had external teams reviewing change. That’s right: External reviews make no difference. The one type of review that did predict software delivery performance was peer review of changes. Thus, if you have a peer-review process, you will have better software-delivery performance.

That’s scary for the teams that perform those reviews. But if you move those reviews into the product team, your company will have better software delivery. Thus, the team members currently performing reviews must work closer with the product teams and become members of those product teams.

Don’t delay customer functionality

We have all seen companies that focus on internal infrastructure at the expense of customer functionality. Zynga was a classic example of how IT decisions can wreck a company. During the explosive growth of its Farmville app on Facebook, it decided to leave AWS and create its own cloud. Not only did it fail, eventually returning to AWS, but it missed out on the explosion in mobile gaming.

Moving to a product-team-oriented organization is not the same as building your own cloud infrastructure from scratch. First, it’s proven that using web services for cloud applications works. Contrast that to Zynga, which worked on how it hosted its software instead of on the software itself. Second, product teams accelerate the rate of innovation in a company. A focus on customer demand over internal demands results in better customer functionality that’s delivered faster.

You can test this yourself. Find a new bit of functionality you want to add to your monolithic application and build it separately, exposing data and functionality via a web service. Then have your monolithic application call the interface to use the functionality. Finally, improve it.

By measuring how each step takes, you’ll prove to others that you can deliver customer functionality faster. In the end, focus on what you are good at: building your application. There are plenty of good cloud computing options out there to house your app. Don’t make the mistake of trying to build one yourself. If you do, functionality will surely be delayed, your customers will not be happy, and your top line will suffer greatly.

Change is scary

The only way to see long-lasting, impactful change in an organization is to make change appealing. But change you must. The question is not how to change, but how to convince your team that it wants to change. The answer is simple: Reward those who engage and drive change. Those who fight change or sit on the sidelines will ultimately see the results and choose appropriately.

To succeed, you needed a change catalyst. So identify teams that are adapting to this new way of building and delivering applications and reward them immediately and loudly. As people see the rewards, the laggards will follow.

However, tha’s not sustainable over the long term. Employees need to see that they can perform their jobs better and faster. That’s self-actualization, which is a far more efficient reward system. As employees see that their own projects get released faster and with less hassle, they will whole-heartedly adopt the “You build it, you run it” mandate.

Amazon shifted to a “You build it, you run it” philosophy in the early 2,000s. Since then, it has struggled internally with changing its org chart, addressing unfounded fears of delaying customer functionality, and convincing employees to embrace the change. But as with Amazon, once you are able to manage these issues effectively, your move to cloud applications will be far easier, and much more rewarding.