Innovation has always been part of the Amazon DNA, but about 20 years ago, we went through a radical transformation with the goal of making our iterative process—"invent, launch, reinvent, relaunch, start over, rinse, repeat, again and again"—even faster. The changes we made affected both how we built applications and how we organized our company.
Back then, we had only a small fraction of the number of customers that Amazon serves today. Still, we knew that if we wanted to expand the products and services we offered, we had to change the way we approached application architecture.
The giant, monolithic "bookstore" application and giant database that we used to power Amazon.com limited our speed and agility. Whenever we wanted to add a new feature or product for our customers, like video streaming, we had to edit and rewrite vast amounts of code on an application that we'd designed specifically for our first product—the bookstore. This was a long, unwieldy process requiring complicated coordination, and it limited our ability to innovate fast and at scale.
I'm happy to announce today that the new AWS Middle East (Bahrain) Region is now open! This is our first AWS Region in the Middle East and I'm excited by the opportunities the availability of hyper scale infrastructure will bring to organizations of all sizes. Starting today, developers, startups, and enterprises, as well as government, education, and non-profit organizations can run their applications and serve end users across the region from data centers located in the Middle East.
With this launch, our infrastructure now spans 69 Availability Zones across 22 geographic regions around the world. We have also announced plans for nine more Availability Zones in three more AWS Regions in Indonesia, Italy, and South Africa coming online in the next few years. The new AWS Middle East (Bahrain) Region offers three Availability Zones (AZs) at launch. AZs refer to data centers in separate distinct locations within a single Region that are engineered to be operationally independent of other AZs, with independent power, cooling, physical security, and are connected via a low latency network. AWS customers focused on running highly available applications can architect their applications to run in multiple AZs to achieve even higher fault-tolerance.
A few months ago, I wrote the post "Amazon Aurora ascendant: How we designed acloud-native relational database," and now I'm excited to share some news about the people behind the service. This week, the developers of Amazon Aurora have won the 2019 Association for Computing Machinery's (ACM) Special Interest Group on Management of Data (SIGMOD) Systems Award. The award recognizes "an individual or set of individuals for the development of a software or hardware system whose technical contributions have had significant impact on the theory or practice of large-scale data management systems."
Customers often ask me how AWS maintains security at scale as we continue to grow so rapidly. They want to make sure that their data is secure in the AWS Cloud, and they want to understand how to better secure themselves as they grow.
Last year, I spent some time in Jakarta visiting HARA, an AWS customer. They've created a way to connect small farms in developing nations to banks and distributers of goods, like seeds, fertilizer, and tools. Traditionally, rural farms have been ignored by the financial world, because they don't normally have the information required to open an account or apply for credit. With HARA, this hard-to-obtain data on small farms is collected and authenticated, giving these farmers access to resources they've never had before.
A major component to the system that HARA created is blockchain. This is a technology used to build applications where multiple parties can interact through a peer-to-peer-network and record immutable transactions with no central trusted authority. HARA has had to develop additional technologies to make their application work on Ethereum, a popular, open source, blockchain framework.
Today, I am happy to introduce the new AWS Asia Pacific (Hong Kong) Region. AWS customers can now use this Region to serve their end users in Hong Kong SAR at a lower latency, and to comply with any data locality requirements.
The AWS Asia Pacific (Hong Kong) Region is the eighth active AWS Region in Asia Pacific and mainland China along with Beijing, Mumbai, Ningxia, Seoul, Singapore, Sydney, and Tokyo. With this launch, AWS now spans 64 Availability Zones within 21 geographic regions around the world, and has announced plans for 12 more Availability Zones and four more AWS Regions in Bahrain, Cape Town, Jakarta, and Milan.
Today, I am excited to announce our plans to open a new AWS Region in Indonesia! The new AWS Asia Pacific (Jakarta) Region will be composed of three Availability Zones, and will give AWS customers and partners the ability to run workloads and store data in Indonesia.
The AWS Asia Pacific (Jakarta) Region will be our ninth Region in Asia Pacific. It joins existing Regions in Beijing, Mumbai, Ningxia, Seoul, Singapore, Sydney, and Tokyo, as well as an upcoming Region in Hong Kong SAR. AWS customers are already using 61 Availability Zones across 20 infrastructure Regions worldwide. Today's announcement brings the total number of global Regions (operational and announced) up to 25.
At re:Invent 2018, AWS announced the AWS App Mesh public preview, a service mesh that allows you to easily monitor and control communications across applications. Today, I'm happy to announce that App Mesh is generally available for use by customers.
New architectural patterns
Many customers are modernizing their existing applications to become more agile and innovate faster. Architectural patterns like microservices enable teams to independently test services and continuously deliver changes to applications. This approach optimizes team productivity by allowing development teams to experiment and iterate faster. It also allows teams to rapidly scale how they build and run their applications.
As you build new services that all need to work together as an application, they need ways to connect, monitor, control, and debug the communication across the entire application. Examples of such capabilities include service discovery, application-level metrics and logs, traces to help debug traffic patterns, traffic shaping, and the ability to secure communication between services.
You often have to build communication management logic into SDKs and require it to be used by each development team. However, as an application grows and as the number of teams increase, providing these capabilities consistently across services becomes complex and time-consuming overhead.
Our goal is to automate and abstract the communications infrastructure that underpins every modern application, allowing teams to focus on building business logic and innovating faster.
Relational databases have been around for a long time. The relational model of data was pioneered back in the 1970s by E.F. Codd. The core technologies underpinning the major relational database management systems of today were developed in the 1980–1990s. Relational database fundamentals, including data relationships, ACID (Atomicity, Consistency, Isolation, Durability) transactions, and the SQL query language, have stood the test of time. Those fundamentals helped make relational databases immensely popular with users everywhere. They remain a cornerstone of IT infrastructure in many companies.
This is not to say that a system administrator necessarily enjoys dealing with relational databases. For decades, managing a relational database has been a high-skill, labor-intensive task. It's a task that requires the undivided attention of dedicated system and database administrators. Scaling a relational database while maintaining fault tolerance, performance, and blast radius size (the impact of a failure) has been a persistent challenge for administrators.
At the same time, modern internet workloads have become more demanding and require several essential properties from infrastructure:
- Users want to start with a small footprint and then grow massively without infrastructure limiting their velocity.
- In large systems, failures are a norm, not an exception. Customer workloads must be insulated from component failures or face system failures.
- Small blast radius. No one wants a single system failure to have a large impact on their business.
These are hard problems, and solving them requires breaking away from old-guard relational database architectures. When Amazon was faced with the limitations of old-guard relational databases like Oracle, we created a modern relational database service, Amazon Aurora.
Aurora's design preserves the core transactional consistency strengths of relational databases. It innovates at the storage layer to create a database built for the cloud that can support modern workloads without sacrificing performance. Customers love this because Aurora provides the performance and availability of commercial grade databases at 1/10th the cost. Since Aurora's original release, it has been the fastest-growing service in the history of AWS.
In this post, I'd like to give you a peek under the hood at how we built Aurora. I'll also discuss why customers are adopting it faster than any other service in AWS history.
In April 2017, Amazon Web Services announced that it would launch a new AWS infrastructure region Region in Sweden. Today, I'm happy to announce that the AWS Europe (Stockholm) Region, our 20th Region globally, is now generally available for use by customers.
The AWS Europe (Stockholm) Region is our fifth European Region, joining Dublin, Frankfurt, London, and Paris. With this launch, AWS now provides 60 Availability Zones, with another 12 zones and four Regions expected to come online by 2020 in Bahrain, Cape Town, Hong Kong, and Milan.
Subscribe to this weblog's