This is an early release version of the contents of the Navigator’s Guide book, an offering from the DigitalOcean Solutions Engineers. The goal of the book is to help business customers plan their infrastructure needs, provide working examples along the way, and include technical nuance and the “why” that makes some decisions better than others.
How do I scale and grow my infrastructure for my business?
More importantly, how do I prevent a crisis? How do I know what my decisions will also impact? Am I asking the right questions?
This book will help answer questions, but also help with the background information needed when making decisions that impact your business’s infrastructure.
In the introduction, we said that this book would give you the tools and the understanding you need to run a successful infrastructure on DigitalOcean — but what is DigitalOcean, and who are we to tell you what to do?
Before we set sail, we want to share a brief infrastructure history lesson. This will help provide context on the needs that cloud infrastructure fills and how to take full advantage of it to get the most value, performance, and stability out of your infrastructure.
This is the first hands-on portion of the book. First, we’ll go over the tools we’ll be using, how they fit together, and how they can be beneficial to you as you begin to create and manage your infrastructure on DigitalOcean. Then, we’ll set up a single Droplet which we’ll use as as a controller to run and use the rest of our tool belt.
It doesn’t matter if you’re running a small blog, a large application, or an API; you never want it to be offline. A single point of failure is any part of your infrastructure that will cause downtime if it fails. A highly available infrastructure has no single point of failure. A highly available configuration is not only important for redundancy. It will also be faster and more cost effective to scale your infrastructure as well.
The previous chapter demonstrated how to reduce downtime by adding redundancy at the web frontend layer of your infrastructure. If your service works with files and data, you’ll also need a centralized backend — which should be similarly redundant to avoid being a single point of failure.
The previous section used Terraform and Ansible to provision resources (Droplets, Load Balancers, and Floating IPs) and deploy your WordPress application. In this supplemental section, we discuss some ways to simplify this configuration using Terraform modules and separate infrastructure environments. There’s no code to execute and no changes to make in this section, but the concepts are important when building a real-world setup.