Today’s applications have the opportunity to reach a global audience, upset the status quo and transform entire industries. With the arrival of Amazon Web Services, on-demand access to compute, storage and database resources has removed the constraints to building sophisticated, scalable applications that delight and disrupt. In this keynote, join Amazon’s CTO to explore the new rules of application architecture that power resilient, adaptive, data-driven applications. We’ll discuss new patterns of architecting for lower cost, continuous deployment, and greater scale used by some of today’s hottest start-ups such as Pinterest, Animoto, Airbnb and Instagram.
In the old world mentality, all resources were constrained: capital, physics, capacity, people, geography, and scope.
When you look at an actual capacity chart of what is being used, you’ll see lots of use on the weekdays and very little on the weekends. In old world thinking you choose to have a little buffer of 15% over the top points, and thus you have a lot of waisted resources that are not being used. Furthermore, at the end of November it spikes even more, making it a loss of almost 76% of their old world server mentality.
The new world is completely unconstrained. What does that mean? It means you can start building architectures in ways you could have never done before. This idea is: secure, scalable, high performance, cost-effective, and fault tolerant.
Everything is now, that used to be physical, a programmable resource: data cents, networks, compute, storage, database, local.
In the past, most of architectural resources went into knowing that you were restricted by those efforts. Not only can you build them in terms of resources, but you can build them so they fail less frequently. The reason why most old world servers failed is because you cannot accurately measure what resources you’ll need when customers change their mind and/or give you outlying needs for server reliance.
The Commandments of 21st Century Architectures:
Architect with cost in mind. Resources can change throughout the lifecycle of the project. Decompose into small, loosely coupled, stateless building blocks. If you want to build an architecture that can scale very fine-grained, you need to build the boxes smaller and smaller.
If you want to build new applications, you should leave behind the old world mentality, and start using the cloud as native cloud.
Automate your application and processes. If you actually have to SSH into your server to manage it, you’re doing it wrong. Let business levers control the system and manage what is happening to it. These tools will allow it to determine when it needs to scale up, and when they need to scale down.
The most important thing, even before security reliability, is security. Integrate security into your application from the ground up. With the cloud in AWS, they give you very fine tools to be able to protect yourself in terms of security groups, identity access management, and RAID.
Don’t treat failure as an exception. Working hard to prevent failure costs you more resources. Deployment isn’t much different than a failure path.
Amazon rolls out a change into production, on average, once every 11 seconds.
Objects should not be replicated beyond necessity. Those solutions, where you make the least assumptions, are likely to be the most successful. One of the things in modern architecture is you assume nothing. If our world is no longer constrained about resources, we don’t need to make any assumptions.
Change your mind, often, whenever you want. Don’t be afraid to make mistakes.
Instead of having models about how the world works, you’re going to instead use exact data to drive your application. Focus on the whole distribution. What does that mean? If you look at a bell curve, and it is based on customer experience, that means that you have 50% of customers that are getting the worst experience. And with this, you need to know how much worse. If you can actually focus on this, and you can control it, you will do great.
Amazon.com doesn’t try to recommend you anything you haven’t already bought. However, if you haven’t every bought anything with them, then you can just display anything. With past customers, they compare your last 1500 purchases, which is very process intensive. That needs to be fast.
Put everything in logs so you can determine everything that has happened in times of failure and success.
Keep in mind that you can always just switch it all off. When you go home at night, and you’re in testing, just turn it off. There’s no need to run processes when nothing is happening on it.