Amazon Web Services¶
There are a lot of options we could explore to host our solution, but AWS is by far the biggest, most well known solution. Most open source tools have deeper integrations and support for AWS versus other public Cloud providers.
It's also just a choice. We've got to pick something, so AWS is what I'm picking as it's what I know best.
Amazon Web Services (AWS) is a public Cloud provider that charges for its services. You may incur a bill if you create resources in your AWS account. Please ensure you're comfortable with this prospect before continuing on with this book.
The author(s) of this book, nor OpsFactory Pty Ltd, will not be liable for any financial obligations or hardship you develop or suffer as a result of following the instructions in this book.
People coming into the DevOps community as professionals will find themselves using public Cloud to host solutions more than they will physical on-premise (physical) solutions. In my experience only (large) enterprises and governments still have some physical presence in data centres - most organisations have since migrated to the Cloud or are "born" in the Cloud - and even then they tend to have a hybrid approach, which includes both options with some sort of dedicated link between the two.
In this book we're going to be discussing public Cloud only, and our choice of platform to get you up and running quickly is Amazon Web Services (AWS).
There are some core benefits to using public Cloud that you'll see mentioned a lot:
- Cost - it's cheaper
- Elasticity - it's scalable
- Utility billing - you only pay for what you use
These benefits mostly go undisputed, but let's cover the benefits of public Cloud versus physical hardware you buy, host and maintain yourself.
Comparing Physical to Cloud¶
When people try to compare physical infrastructure against virtual infrastructure in AWS they tend to fall into a common trap that Cloud is more expensive because, on paper, it looks more expensive. There are a lot of considerations that aren't taken into account during these calculations which skew the figures in favour of physical infrastructure.
Firstly most of these calculations are based on running physical hardware 24/7, which of course it does. But that's not how you're meant to be using public Cloud. The idea behind the elasticity of public Cloud is you can scale down resources when you're not using them. This means your compute resources, your servers, can be scaled down horizontally (reducing the number of servers) and vertically (reducing the size of the servers) whenever you're able to. This is one clear way you can drastically reduce costs.
Inventing your own AWS¶
Another point to consider is how much automation a public Cloud provider like AWS affords you. When you buy physical infrastructure you're limited to a very few number of options when it comes to building an automated, scaling platform (OpenShift, VMWare, etc.) What tends to actually happen is people start inventing their own automation around the platform which, in effect, means they're re-inventing AWS. That costs a lot of time and therefore, a lot of money, way more than you'd spend simply shifting your workloads to public Cloud.
Thirdly physical infrastructure has to be maintained and managed. If a server needs to be replaced, upgraded, and more, you're going to need a human to do this for you. That's going to cost you a lot of money. In comparison when I need a bigger EC2 Instance (a bigger virtual server in AWS terminology) I just create one and I have it a few minutes later. This point somewhat rides on the back of the previous point: there is some much automation around public Cloud that's actually quicker to ask for and receive a new server in AWS than it is to write the email ordering a new, bigger server from your current provider.
Finally there's redundancy. When building a solution based off of physical hardware you buy and host your self, you're very likely tied to a single data centre. There's an obvious flaw in this plan when it comes to considering a power failure or disaster at that DC - you have no other redundancy options. Public Cloud providers like AWS have, in virtually all of the cities they're present in, at least three completely isolated data centres you can provision your servers in. In Sydney, Australia we have three Availability Zones (AZs). That means if I want to ensure I have the highest possible degree of redundancy for my Sydney based solution I can build three EC2 Instances across all three AZs and have a load balancer send traffic across them. A failure in one AZ has no effect.
There are other reasons public Cloud infrastructure is superior, but we need to move on and start building instead of trying to understand the pros and cons.
AWS Products and Services¶
AWS offers a huge catalogue of products. It ranges in the hundreds of services. There however a core set of AWS services that concern most people and fullfil most people's needs 80-90% of the time (in my experience). These services include:
Instead of going into detail regarding all of these services I've instead linked to the best documentation AWS has to offer. This is the better option given they're updated often and things change a lot in this field.
- Elastic Cloud Compute (EC2) - virtual servers
- Virtual Private Cloud (VPC) - virtual networking
- Simple Storage Service (S3) - object storage
- Identity and Access Management (IAM) - access control and policy management
- Relational Database Service (RDS) - managed database engines such as MySQL, MS SQL Server
- CloudWatch - logging and monitoring
- Route53 - DNS registrar and management
- Elastic/Application Load Balancing (ELB/ALB) - load balancers for compute resources
For all other AWS services and their documentation, check the AWS Documentation Gateway page
You could argue there are other services which constitute the core of AWS' catalogue, but I believe the above cover everything most organisations will need when uplifting an existing solution into the public Cloud (a very common thing at this moment in time.)
Now that we have a good overview what AWS is and why it's beneficial, let's get an account created. You're going to need one to follow along with this book.