Category: Server

97 Things every Cloud Engineer should Know – Summarised Notes

As with the other post on 97 things every developer should know, this is not a hard and fast list.

It is a bit of interesting info from people in the industry that may or may not have the required experience and may be in a specific part of the business not relevant to you.

It is however always useful to read, learn and here is a summary of the book

What is the Cloud?

On-demand Compute and storage resources - a datacenter accesible over the internet

Essential characteristics of the cloud model:

  • On-demand self-service - no need to call, open a ticket or send email for something to be provisioned
  • Broad network accessible - accessible from a multitude of devices on different networks
  • Resource pooling - making a pool of resources available to multiple customers - not knowing where the physical machine is. An abstraction.
  • Rapid elasticity - resources should scale up and down based on customer requirement - an engineer need not worry about adding and removing capacity
  • Measurred service - pay for what you use for a given unit of time

Why the cloud?

Procuring new hardware, installing and maintaining takes a long time - taking away from the key to company revenues - the application

Technology can be a cost saver and an enabler...

Three keys to making the right multicloud decision

  • visibility - having information where it matters a trusted source of truth
  • efficiency - best use of resources
  • governance - security, quality and policy enforcement allows for improved innovation and speed of delivery

Use Managed Service - Please

Operations at scale are a hard problem - failure is rampant

Automation and standardisation is crucial

Managed services like Amazon Relational DB (RDS), google cloud SQL or Microsoft Azure SQL.

They have the experience and have been through the trouble. Unfortunately these are proprietary things and limit your freedom - so there is a tradeoff between using standard MySQL or Postgres and the big cloud version of the service.


  • File storage
  • Object cache
  • Message Queues
  • Stream processing
  • ETL (Extract, Transform, Load)


  • They have experience
  • Cheaper
  • Faster for development

Why not?:

  • You cannot tweak anything
  • Lock-in

A Cloud Computing Vocabulary

  • Availability - Ampunt of time (as a percentage) of a service being live and functional
  • Durability - Chance that data will be lost or corrupted
  • Consistency - when writing to a datastore the data read is the same value immediately
  • Elasticity - Dynamically matching resource requirements based on the load
  • Scalability - how elasticity is achieved...vertical (bigger hammer) or horizontally (more hammers)
  • Serverless - Running application code without managing infrastructure also known as faas function as a service
  • Fully managed - cloud resources extracted away so the cloud provider takes all responsibility from the software developer

Every Engineer Should be a Cloud Engineer

If you are lazy and don't want to re-invent the wheel.
Describe your problem and their will be a cloud service for it - the trick is making it fit together.


  • Turn on billing alerts
  • Make use of free-tier
  • Use external documentation
  • Change one setting at a time
  • Few people understand IAM (Identity and Access Management)

Manage Up: Engage with Executives in the Cloud

  • Understand what executives need
  • Tell them how your proposal meets their needs in their language
  • Be trusted in a world of marketing buzzwords and high expectations
  • KNow the numbers
  • Know how executive performance in measured


Whats Next for Containers?

Combining the best of Containers and VMs: MicroVMs and UniKernels

MicroVM's: VM's for specific use cases, can boot in milliseconds.
MicroVM runtimes launch the vm then launch the container in it.

Unikernels: lightweight, immutable OS - application is combined with OS drivers and libraries. Example: MirageOS

Performance and security benefits.
Downside is they are completely different from containers.

Containers aren't Magic

The OCI (Open Container Initiative) is a definition of a seperate place for applications to live.

Your CIO wants to Replatform only Once

Pitch why new infrastructure will increase velocity, security, reliability, future proofing and scalability.

Must be cloud agnostic.

Kubernetes is the ultimate PaaS builder.

Practical Application: Implementing SSH security with TLS certificates

In any organisation of a large size managing access to servers and cloud resources is difficult.
There is often a tradeoff between convenience and security.
Changing these settings is also a bit scary in production as you can be locked out of your servers...

One solution mentioned by facebook engineering and smallstep is to make use of certificates to authenticate and authorise SSH users.

In this post we will look at what we need to achieve better SSH security and how to implement it...

What we need to know

The topics we should read up on are:

  • TLS certificates and public key cryptography
  • OpenSSL
  • Public Key Infrastructure (PKI)
  • SSH
  • Hashicorp Vault

Some books might be:

That is alot of reading.


Generate a letencrypt ssl certificate for kong api gateway

So you have installed kong and you are ready for it to go into production. Whoops, nossl certificate yet? It is important that you add it as credentials will be moving between your gateway and credentials could be acquired by any party in between the client and your server.

But the standalone nginx plugin for cerbot does not work from my testing. As it is built on nginx, kong is not nginx.

Easiest Way is to Install Nginx

If Kong is running on port 80 then stop it: sudo systemctl stop kong

Install Nginx:

sudo apt install nginx

Install Certbot for nginx on your operating system

Get your certificates with the cert-only option:

sudo certbot --nginx certonly

When that completes it will tell you where your certificates and keyfile are:

Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/
Your key file has been saved at: /etc/letsencrypt/live/

Add these locations to ssl_cert and ssl_cert_key respectively.
Also make sure ssl = on

Stop Nginx:

sudo systemctl stop nginx
sudo systemctl start kong

Remove nginx:

sudo apt remove nginx