Cloud 1st – Page 2

These are principles rather than laws. They apply in every situation, but how they are applied will differ depending on circumstances. If you would like to know more about how they will apply to YOUR organization, just send me a message from the contact page.

(In no particular order)

Principle	Brief Description
1. Cloud First	Consider using a Cloud Solution before you look at other options. Why Cloud 1st?
2. Automate Everything	Everything you build should be both automated and repeatable Read why here
3. Build Everything using Code	Mouse Clicks on portals aren't automated. 🙂 Benefits of IaC
4. Security is Paramount	Security shouldn't be an after-thought but should be built into everything. Stay Safe
5. Measure Everything	Tag everything. Log everything centrally. Save money and future headaches
6. Create Scalable Microservices	Scale horizontally No monoliths
7. Prepare for Failure	Assume things will break. Build self-healing solutions. here's how
8. Optimize for Cost	Never over-provide!
9. Consider Portability	Will you need to use another Cloud Service Provider?
10. Follow Cloud Native Best Practices	All applications should be designed in line with best practices

Because all services offered through the major cloud providers are exposed via APIs then you can start to codify your infrastructure.

To explain this in more detail lets look at the different ways we can build a server in AWS. AWS servers are called “EC2 instances” (ECC stands for Elastic Compute Cloud). Once you have an account you can use your browser to visit a console where you can click on a button to build your server. The form will ask you a bunch of questions and then Amazon will build the virtual server for you.

However Amazon also allow you to build your server from the command line. You can download the AWS SDK or you can use the CLI. These tools will allow us to write code that can be executed to build whatever we need. There are other tools (such as Ansible and Terraform) that can add a level of abstraction and simplification to this process.

Once all of your infrastructure is built as code things start to change in the way the infrastructure is managed. We can start to introduce all the good practices that developers have been using for years to manage code. Simple things such as versioning, keeping backups of previous versions, extensive in-line commenting to name but a few.

Our code can tell our Cloud Service Provider (CSP) what to build but also tell us what we have built removing the need to continually update a database that references our complex environments. Infrastructure change becomes easier to manage as we can roll back to a previous version in minutes.

But our code can do even more than this. Our code can include references that allow automatic scaling of services. However that demands an understanding of the subject of elasticity and at this point its probably worth reviewing the 10 principles of a good Cloud strategy.

Contact Page