In this first chapter, we’re going to take a look at the history of AWS. Let’s take a trip back in time to see how Amazon’s organization has changed over the years since its inception.
Back to the Days of the Monolith
Amazon was created in 1994, and until 2001, its IT services were one huge monolith. They were designed as one module, containing all the different features necessary for Amazon’s online sales activity at the time.
As the company grew, its monolithic structure started to slow it down, inhibiting its ability to innovate continually. It needed to provide more flexibility for its IT teams while still meeting business demands, which meant that it needed to develop an alternative to its monolithic architecture.
Discover the Microservices Approach
The basic idea was to break Amazon’s monolithic sales website down into dozens of mini-applications, such as:
Delivery
Order management
Billing
Search
Product display
This is known as service-oriented architecture.
Even today, each of the different parts you can see on Amazon’s online sales website is a microservice. Here are a few examples:
The “Order” button
Product images
Product descriptions
Comments
However, to implement this ever-expanding spectrum of microservices, the organization of Amazon’s teams needed an overhaul.
Micro-teams: Redesigning the Organizational Structure
In the 2000s, how Amazon’s teams were organized wasn’t suitable for a company running hundreds of applications and needed to be changed to ensure more seamless communication.
This is where the concept of the product team came from. Previously, Amazon organized their teams in a fairly standard way:
Specialized teams
Developers
Testers
Support
However, they implemented a product approach in the new structure, which involved different members of each of these teams working together.
Product teams take a horizontal approach to projects:
Each team is composed of a small number of people—Amazon refers to this as a two-pizza team, i.e., a team that can be fed with two pizzas (two large pizzas, of course!).
Small, multidisciplinary teams considerably reduce the time between identifying a need and its subsequent production launch, known as the time to market. Communication also becomes easier.
In this type of organization, teams act as service providers for other teams, from website development, to management of the infrastructure used by developers, and everything else.
The Metamorphosis to Amazon Web Services
Little by little, the idea of selling their internal infrastructure concept as a service for public use emerged. In 2006, this became a reality with the launch of the first version of Amazon Web Services (also known as AWS), providing basic services such as:
Unlimited on-demand storage with Amazon S3 (Simple Storage Service).
Message queues with Amazon SQS (Simple Queue Service).
On-demand computing capacity with Amazon EC2 (Elastic Compute Cloud).
Since its inception, AWS has constantly been improving these services and launching new ones. The most notable are:
On-demand databases with Amazon RDS (Relational Database Service).
Virtual network with Amazon VPC (Virtual Private Cloud).
Load balancing with Amazon ELB (Elastic Load Balancer), Amazon ALB (Application Load Balancer), and Amazon NLB (Network Load Balancer).
Infrastructure monitoring with CloudWatch.
Management of access to infrastructure and services with Amazon IAM (Identity and Access Management).
Discover the AWS Services, Inspired by Amazon’s Internal Organization
As you gain more experience with AWS, you’ll see that the components are often significantly different from each other. This is normal—as you’ve just seen, Amazon’s teams work in small groups, and each group makes different choices.
Therefore, each component at AWS is fully autonomous, and is managed by its own specific team with its own roadmap and objectives. These components act as “services” that other AWS components or the public can use.
Does that mean the services don’t work together at all?
Thankfully, no! Almost all AWS services can be connected, as they all use what’s known as an application programming interface, or API for short. Each service provides features other services can use to communicate with it. So when a team wants to use the features of a different service, all they have to do is read the related API documentation and make API calls to the other service.
Configure AWS Services: The Possibilities Are Endless (Well, Almost!)
There are now so many AWS services available that you can create your own custom infrastructure, choosing the different components you need. By design, all AWS services can be managed via APIs, and this means you can use a powerful tool: programming.
You can use your programming superpowers to manage your different services completely automatically. You’ll see how to do this in the next chapter, and learn about the other benefits your programming skills can bring to your infrastructure.
Let’s Recap!
Flexibility is the name of the game for quicker and more efficient teams, using methodology such as microservices, “two-pizza teams,” and on-demand infrastructure.
Amazon Web Services are sometimes very different from each other, as each team is independent.
The different services communicate using APIs.
You can use Amazon Web Services’ APIs to automate your infrastructure.
Now that you know a bit more about the Amazon Web Services concept and how its architecture works, let’s go to the next chapter for a closer look at APIs and the benefits of this type of automation.
