DEV Community: Ileriayo Adebiyi

Debugging an AWS CodeBuild Failure

Ileriayo Adebiyi — Wed, 27 Aug 2025 12:53:25 +0000

My introduction to AWS CodeBuild was an error log sent to me by a software engineer. I saw in the logs a NestJS application, as indicated by the nest start command in it.

I immediately recognized from the name of the AWS service (CodeBuild) and from the logs that this had to be a build system, similar to what you could achieve in GitHub Actions.

Well, a nest build command was failing; however, it seemed to run successfully on the engineer's computer.

I needed to understand how CodeBuild was being triggered, and like most build systems, there ought to be a build config. I didn't find anything useful while browsing the AWS Console, so I looked at the root of the repo and found a buildspec.yml. This had to be it.

Looking in the file, I found something that made sense:

version: 0.2

phases:
  install:
    commands:
      - npm install
      - npm install typescript
  pre_build:
    commands:
      ...
  build:
    commands:
      ...
  post_build:
    commands:
      ...
artifacts:
  files:
    - '**/*'

There must be some way to run this locally in a container, I thought, and true to that, I found that I could.

First, I pulled the Amazon Linux 2 image:

docker pull public.ecr.aws/codebuild/amazonlinux-x86_64-standard:4.0

Next, I pulled the agent (x86_64 version)

docker pull public.ecr.aws/codebuild/local-builds:latest

Afterwards, I downloaded a bash script into the root of the repository and made it executable:

$ curl -O  https://raw.githubusercontent.com/aws/aws-codebuild-docker-images/master/local_builds/codebuild_build.sh

$ chmod +x codebuild_build.sh

Finally, I ran the script with the

./codebuild_build.sh -i public.ecr.aws/codebuild/amazonlinux-x86_64-standard:4.0 -a <output directory>

And then the logs came out just like I saw on the AWS Console.

After examing the logs and the application code, it was the typescript version that needed a change.

version: 0.2

phases:
  install:
    commands:
      - npm install
      - npm install typescript@5.5.4
...

Running the script one more time with this new buildspec.yml, there was no failure.

I made a PR, and that problem was fixed.

Pros of Debugging locally:

Cost: AWS charges you for every build on AWS CodeBuild. Rerunning the CodeBuild with costs low.
Velocity: You can make changes locally and test all within an IDE, skipping the need for commits, PR reviews, etc.

Cons of Debuigging locally:

The Amazon Linux Image may be large and might pose a challenge in a low internet environment.

Something You Didn't Know About AWS Availability Zones

Ileriayo Adebiyi — Wed, 15 Jan 2025 13:57:06 +0000

DataCenters

An AWS region e.g. us-east-1 has physical data centers where the actual infrastructure lives, e.g. us-east-1a, us-east-1b, etc.

But there's something you may not have known:

Availability Zones (AZs) in an AWS account may not always refer to the same data center(s) in a different AWS account.

In other words, for a region us-east-1, the AZ us-east-1a in one person's account (Account A) may not be in the same data center as the AZ us-east-1a in another person's account (Account B).

To ensure that resources provisioned in different AWS Accounts are placed in the same physical location, using the AZ name is not a reliable option.

Why Should You Care?

Latency: In a multi-account environment, where you have different AWS accounts for different purposes, you may require a service in one account to connect with another service in a different account. By placing those services in the same physical data center, the number of hops is reduced.
Compliance: In other to comply with company or national policies, some services may be required to stay in a particular location. Placing those services in the same region is a great way to ensure compliance, and you can go further to ensure that they are in the same physical data center.

If you care, then there is a solution -- Zone IDs!

Availability Zone ID

An Availability Zone ID is an ID that is consistent across all AWS accounts. An AZ Zone ID in Account A is the same physical data center for the same Zone ID in Account B.

AZ Zone Name is not necessarily the same physical location in different AWS Accounts
AZ Zone ID is the same physical location in different AWS Accounts

To get the availability zone ID, you can use the following command:

aws ec2 describe-availability-zones --region us-east-1

You can now proceed to use the Zone ID reliably.

Cheers!

If you liked this, let me know by reacting to this post or leaving a comment.

You can also Follow me on:

X/Twitter: https://x.com/ileriayooo
LinkedIn: https://linkedin.com/in/ileriayoadebiyi

Learning GCP, Pragmatic GKE

Ileriayo Adebiyi — Sat, 19 Aug 2023 08:54:40 +0000

I'm currently working on a project in GCP, even though I started with very little (stale) knowledge, I think I'm progressing well.

What's working for me:

1. Concept/Fundamentals

Before getting on the project, I did some Udemy videos to get familiar with the terminology, especially for IAM. I often had the videos on 1.5x or 2x, as the concepts were similar to other public clouds that I was familiar with.

My reason for videos was to have a picture of things. The GCP Console, where to find things, etc.

No depth at this point.

2. Drill Into

I already knew I was going to be working primarily with Google Kubernetes Engine, and by the time I got on the project, I needed specifics.

I was on the GKE Docs MOST of the time, learning how things fit together.

Now, I already had some good knowledge of Kubernetes which I had gotten from previous experiences and also from being certified.

My task was pretty simple though:

Deploy and expose a K8s Operator

Meanwhile, check out this thread on why I think you should take the Kubernetes Certification(s). https://twitter.com/Ileriayooo/status/1610323839992430593

As simple as that may sound, it took about 3 days of reading the Docs to understand things properly.

3. Practice

All this would not make sense without getting hands-on. You learn by doing.

Deploying the operator was the simplest part. A helm release in Terraform with the appropriate attributes and then a "terraform apply" gets the job done.

Exposing the operator was the sweetest!

Ingress, off course!! But that was just the beginning.

(a) Performance

This deployment needed to use Container Native Load Balancing. What does this mean?

Typically, Load Balancers are not "container aware", i.e., rather than route traffic to containers, traffic is routed to the k8s nodes (or VMs) that host the pods(containers).

After routing to the nodes, Iptable rules ensure that the traffic gets to the right pod. This pod may be on a different node, which means that the traffic has to leave that initial node in order to get to the destined pod.

With CNLB, the LoadBalancer is aware of the pods and can route traffic directly, skipping the extra hops.

This performance gain could not be overlooked!

Further into the docs, I discovered that by default, CNLB is enabled on GKE clusters if they are:

i) GKE clusters 1.17.6-gke.7 and up

ii) using VPC-native clusters

iii) not using a Shared VPC

iv) not using GKE Network Policy

Otherwise, in order to enable that feature, one will have to explicitly annotate the K8s Service object with the following:

cloud.google.com/neg: '{"ingress": true}'

(b) Security

Exposing this publicly was not the intention. Only a few private networks and IPs were to be able to access this web service.

With Cloud Armor, a Security Policy was configured to allow only specific actors. This is also a good way to prevent Distributed Denial of Service (DDoS) attacks from the internet.

And of course, TLS!!

Google Managed Certificates are easy to get. This also means setting up Google Cloud DNS.

Challenges faced:

Andela made us realize that Technology is usually the easiest to learn - Docs, Udemy, etc.

Working solo, things look like a breeze!

However, you'd soon realize that you need a different set of skills to work in a distributed team:

a) Collaboration/Communication:

Every attempt to run a "terraform apply" kept failing. Terraform Statefiles were centralized and stored in a different GCP Project.

There is always the temptation to go try things out in a different environment.

But, time is not on my side!

To whom do I go?

i) After several days, Slack messages, and email requests, I now have just the right amount of privilege to administer the cloud resources.

ii) Git - rebase, merge, conflicts, PRs, approvals, etc. I need not say more about this.

iii) TODO: insert others

TLDR - Summary

Get familiar with the fundamentals - take a beginner course
Move from the generic, go on to the specific, and drill down.
Practice - you learn by doing, not just knowing.
There will always be challenges - how else will you measure progress?

Follow me on LinkedIn and Twitter where I talk about Cloud & DevOps.

100% Off On The Kubernetes Certifications - CKAD, CKA & CKS

Ileriayo Adebiyi — Sun, 30 Jul 2023 06:06:16 +0000

Free Kubernetes Certifications!!!

Combined, the Kubernetes certifications will cost you about $1400. What if I told you that you can take the exams for free? 100%! (and no, it's not Black Friday)

I'll show you 3 ways 🧵

1. Linux Foundation Scholarship

I found out in 2021 after bagging the Cloud Captain Scholarship, that scholarship recipients get access to both a training course and a certification.

The LiFT Scholarship, also called The Shubhra Kar Scholarship has awarded over 2,100 scholarships for millions of dollars worth of specialized, technical training to those who may not have the ability to afford this opportunity otherwise.

Getting the scholarship means getting one of the Kubernetes certifications for free.

2. The CNCF Ambassador Program

I decided to join the Ambassador program this year, helping the CNCF on its mission to make Cloud Native ubiquitous.

One of the numerous benefits of becoming an Ambassador is the waived cost of certification and training.

This is huge, get on it!

3. Convince your boss

The Linux Foundation has a nifty tool that generates a letter and a quote that you can use to convince your manager.

Check it out here https://training.linuxfoundation.org/training/convince-your-boss/

If this post was great, like, share, and follow.

This post was first shared on Twitter. Follow me there to get latest opportunities in Cloud Engineering & DevOps, as I usually tweet them first --> @Ileriayooo.

Unsure whthere to take the Kubernetes Certifications? Check this thread https://twitter.com/Ileriayooo/status/1610323839992430593

Up and Running with AWS Elastic Container Service (ECS) - Part 1

Ileriayo Adebiyi — Fri, 14 Jul 2023 00:37:20 +0000

This post assumes at least a familiarity with building and running containers using Docker

What is ECS

Containerization is a computing model that allows you to package your application and it's dependencies into a runnable Image. This image can be put on any environment that has what is called a Container Runtime. Simply put, Container Runtimes allow you to run your containerized applications.

Docker has become the defacto CR in the industry, and with it, you can package your application into an image, and run it as a container(s).

On the Amazon Cloud (AWS), the Elastic Container Service (ECS) provides a runtime for your Image. You can deploy, manage and scale containerized applications on AWS using ECS.

Basics of ECS ?

Under the hood, the infrastructure where your ECS container runs can be any of the following:

EC2 Instances
Serverless (AWS Fargate)
On-premises virtual machines (VM) or servers This infrastructure is otherwise known as Capacity

Once you have built a (Docker) Image, and stored it in an Image registry such as AWS Elastic Container Registry (ECR) or DockerHub, you can use ECS.

First, ECS needs to know what image you want to run, the operating system of the underlying infrastructure (remember Capacity?), which ports to open for your application and what volumes to use. You must define this so that ECS knows the task that it must do. AWS calls this a Task Definition.

A Task Definition can be created directly from the AWS Console, but in reality, it is a text file in JSON format containing the parameters mentioned above. With this task definition in place, ECS can now execute the "task".

Thus, we can say that a Task is a Task Definition that has been executed, or better put, it is an instance of a Task Definition.

If you're familiar with (Docker) containers, you will know that they are (ought to be) ephemeral. Ephemeral here implies that the container can be stopped and destroyed for whatever reason. If this happens, then the Task that you created will be destroyed, and you have to recreate it manually. In order to automate the creation of tasks, we can use something called a "Service".

An ECS Service can automatically restart your Task, for instance, if a health check fails. It can also be used to run and maintain your desired number of Tasks simultaneously (or call this scaling your application) based on your Task Definition.

All of this comes together under a Cluster. A cluster is a logical grouping of Tasks or Services that runs on the Capacity infrastructure that is registered to that cluster.

Lastly, in each container instance found on ECS, there is a Container Agent that sends information about the current running tasks and resource utilization of your containers to Amazon ECS. This agent is responsible for starting and stoping tasks whenever it receives a request from Amazon ECS.

Summary

Capacity: The underlying infrastructure for ECS e.g., EC2 servers or Serverless (fargate).
Task Definition: container information about a task such as the image to run.
Task: A running instance of the task definition.
Service: A collection of tasks, that automates things like restarting a container task.
Cluster: Everything is in a cluster, this is a logical grouping of tasks and serivices. For example, you can have a cluster for a Banking app, and another for the HR app.
Container Agent: Responsible for starting and stopping container tasks, and sending resource utilization to ECS

Adding Free SSL/TLS on Kubernetes (using CertManager and LetsEncrypt)

Ileriayo Adebiyi — Wed, 14 Jun 2023 11:37:34 +0000

You have a shiny new Kubernetes cluster. You deploy your hello-world app and can now reach it via a NodePort service at http://:30000.

As the workload begins to increase, you decide to use a Loadbalancer Service instead. But then it occurs to you - using a Loadbalancer service for each workload can become so expensive.

Ingress to the rescue!

You write a simple ingress manifest and kubectl apply! Boom 💥

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  labels:
    app: hello-world
  name: example.com
spec:
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          service:
            name: hello-world
            port:
              number: 80
        path: /
        pathType: Prefix

But without an ingress controller, your ingress resource has zero effect. You remember that some guy on YouTube had mentioned one Ingress-Nginx controller and you think let's check that out.

Dang! After 2 hours, you find on StackOverflow that your k3s cluster came bundled with the Traefik Ingress Controller 😡

You create an A record to configure your domain to point to the public IP Address of the (single) node in your cluster. With a big smile, you open a new tab on your browser, head to the URL bar and navigate to your domain (example.com). You get a response, "your connection is not secure".

What do you do now?

In the following secion, I'll show you how to add TLS to your Kubernetes cluster using cert-manager to automate certificate management operations such as issuance and renewal.

Cert-manager + LetsEncrypt

Cert-manager is a native Kubernetes certificate management controller. It can help with issuing certificates from a variety of sources, such as Let's Encrypt, HashiCorp Vault, Venafi, a simple signing key pair, or self signed.

Let's Encrypt is a nonprofit Certificate Authority that provides TLS certificates to 300 million websites.

Steps

Install Cert-manager onto your cluster
Add LetsEncrypt as an Issuer (or ClusterIssuer)
Update ingress to use certificate

Install Cert-manager

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.1.1/cert-manager.yaml

Verify installation of cert-manager by checking the cert-manager namespace for running pods

$ kubectl get pods --namespace cert-manager

NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-5c6866597-zw7kh               1/1     Running   0          2m
cert-manager-cainjector-577f6d9fd7-tr77l   1/1     Running   0          2m
cert-manager-webhook-787858fcdb-nlzsq      1/1     Running   0          2m

All good! Proceed

Issuer (or ClusterIssuer) - Let's Enncrypt

a. Create either a clusterissuer.yaml manifest

apiVersion: cert-manager.io/v1
kind: ClusterIssuer # I'm using ClusterIssuer here
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <your-email-address>
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: traefik

b. Apply the manifest

kubectl apply -f clusterissuer.yaml

Create (or Update) Ingress

The following manifest is an example ingress resource:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  labels:
    app: hello-world
  name: 
  namespace: <namespace> # if non-default namespace
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  rules:
  - host: example.com # your domain
    http:
      paths:
      - backend:
          service:
            name: <your-service>
            port:
              number: 80 # use appropriate port
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - example.com # your domain 
    secretName: letsencrypt-prod # secret name, same as the privateKeySecretRef in the (Cluster)Issuer

Apply the manifest!

You can verify that a certificate has been issued

$ kubectl -n <namespace> describe certificate letsencrypt-prod
Spec:
  Dns Names:
    example.com
  Issuer Ref:
    Group:      cert-manager.io
    Kind:       ClusterIssuer
    Name:       letsencrypt-prod
  Secret Name:  letsencrypt-prod
  Usages:
    digital signature
    key encipherment
Status:
  Conditions:
    Last Transition Time:  2023-06-14T03:24:49Z
    Message:               Certificate is up to date and has not expired
    Observed Generation:   1
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Not After:               2023-09-12T02:10:00Z
  Not Before:              2023-06-14T02:10:01Z
  Renewal Time:            2023-08-13T02:10:00Z
Events:                    <none>

You should now have TLS configured!

Leave your feedback, comments and questions below, and I'll be happy to res you.

If you liked this, you can follow me on Twitter (@ileriayooo) where I share lot's of info on Kubernetes, Cloud Native and DevOps.

Be Kubectl Kompatible (1)

Ileriayo Adebiyi — Mon, 12 Jun 2023 16:51:24 +0000

Did you know that “You must use a kubectl version that is within one minor version difference of your cluster”?

What does this mean?

Kubernetes uses Semantic Versioning, expressed as vX.Y.Z
X = major version
Y = minor version
Z = patch version

Hence, it means that for a cluster of v1.26 (major version = 1, minor version = 26), the valid versions of kubectl that you should use while interacting with the cluster should be between v1.25 and v1.27.

You can check the version of kubectl using the command:
kubectl version.

From the output of that command, you can tell whether you’re compatible or not. I have used the --output=yaml flag to present the information a lot nicer.

Under the clientVersion, you can see the version of the kubectl client installed, while the version of the Kubernetes cluster is found under serverVersion.

If you’re not compatible, you can simply downgrade or upgrade kubectl, or better still, you can stay tuned for the part two of this series to learn an easier and better way to handle this.

Becoming a Cloud Engineer in 2023 (A Roadmap)

Ileriayo Adebiyi — Mon, 16 Jan 2023 13:38:44 +0000

Here is Simon Holdorf’s recommendation for becoming a Cloud Engineer in 2023.

Step 1: The Role

On a high level, a cloud engineer is responsible for designing, building, and maintaining an organization's cloud computing infrastructure and systems.

Step 2: The Fundamentals

Don't skip the Fundamentals!

Learn:

General Cloud Computing
Networking
Operating systems
Virtualization
Security

Step 3: Selecting a Cloud Provider

It is beneficial to have experience with multiple cloud providers as a cloud engineer.

If you are starting, I would highly recommend concentrating on one cloud provider first: AWS, Azure, or GCP.

Step 4: Acquiring programming knowledge

As a cloud engineer, it is important to understand at least one programming or scripting language, especially for automating tasks and provision resources in the cloud.

Know your way around Git and a product like GitHub or Gitlab.

Step 5: Learning DevOps principles & tools

DevOps is a set of practices that aims to improve collaboration between development and operations teams and increase software delivery speed and reliability.

Know:

CI/CD
IaC
Monitoring & Logging
Collaboration & Communication

Step 6: Gaining Hands-On experience

Seeking opportunities to gain practical, hands-on experience with cloud technologies is essential to becoming a successful cloud engineer.

The first step is to create an account with one of the big cloud providers, AWS, Azure, or GCP.

Step: 7 Earning Certifications

Obtaining a certification can be beneficial for several reasons:

Validation of skills
Improved job prospects
Professional development
Increased earning potential
Fun challenge

To become a successful Cloud Engineer, you need to have a mindset focused on delivering scalable, reliable, and secure solutions.

Check out Simon's video https://www.youtube.com/watch?v=6Yi3c259RE0

Follow Ileriayo Adebiyi on LinkedIn & Twitter for more on Cloud & DevOps.
LinkedIn: https://www.linkedin.com/in/ileriayoadebiyi
Twitter: https://twitter.com/ileriayooo

Managing Multiple Environments With Terraform

Ileriayo Adebiyi — Mon, 16 Jan 2023 13:14:12 +0000

Managing Multiple Environments With Terraform

If you want to manage multiple environments with Terraform e.g., Dev, Stage, and Prod, you can use either:

workspaces or
git branches (dev, stage, prod)

But there's a third. Just before that:

Workspaces seem good at first:
native to terraform, no new tool to learn; simply create and switch workspaces on the same terraform config codebase: > terraform workspace new > terraform workspace list > terraform workspace select

this means code maintenance is a breeze, with no code duplication

However, when it comes to using a remote backend. It might be a mess. With older versions of terraform, you could only use a single backend for all workspaces. Not exactly sure if this is the case for the latest terraform version.

Also, code (terraform module) versioning could pose a challenge. How do you promote module versions from dev to staging to prod workspace without breaking prod (since it's just one codebase right?). Variables you may say, unfortunately, variables cannot be used everywhere. Scary!

Using git branches solves the problem of versioning, since you can have a version in the dev branch, another in the staging branch, and another in the prod (main) branch.

However, as the codebase grows, maintenance becomes a nightmare. Too error-prone and bug-welcoming

The third option is Terragrunt, which captures the best of both worlds and adds a bonus of concurrency: terraform apply on multiple environments at the same time.

This lovely blog post series from Yevgeniy Brikman was a delightful and thought-provoking one for me. https://blog.gruntwork.io/how-to-manage-multiple-environments-with-terraform-32c7bc5d692

Have you worked with Terraform environments before? What are your thoughts?

Read the thoughts of others on the original LinkedIn and Twitter posts:

LinkedIn: https://www.linkedin.com/posts/ileriayoadebiyi_how-to-manage-multiple-environments-with-activity-7019665054975287296-4ORD
Twitter: https://twitter.com/Ileriayooo/status/1613901213744914432

Cheers!

SOME THOUGHTS ON TRAINING (An ingredient for effectiveness)

Ileriayo Adebiyi — Mon, 31 Oct 2022 09:48:27 +0000

During a warming visit at my Pastor's, I volunteered to install the baby hanger. We laughed off the inexpertise - I had no prior experience sufficient to guide me through the task, and thus my first thought was: "a manual should suffice".

The manual would be a guide, its purpose would be to show the how-to. As I stared at the different screw sizes, plastic clips, and metallic rods - and with no manual in sight, I thought to myself: "intuitive, this should fit into this, and that should fit into that".

As I gave some more thought to it, I figured that I needed more than a cursory glance. I didn't know what the hanger should look like at the end. "What would success look like, what is the big picture?".

Back in the university, someone asked why computer scientists are so bothered about algorithms, and the visiting US lecturer at the symposium mentioned that algorithms are the essence of computer science. An algorithm is a step by step process to solving a problem. One of the things computer science teaches is how to solve problems.

Trying to figure out the end goal, my computer science background (together with other experiences developing software to solve problems) kicked in and so I took to Google and YouTube, researching until I found the exact type of hanger and how to go about installing it. Not long after, I found the big picture, I knew exactly what needed to be done. I knew how to define success.

When there is a vision, when you see the big picture, then there ought to be training.

Training is the distance between where you are and where you want (need) to be.

"Where am I?"
"Where do I want to be?"
"What do I need to do to get to where I want to be?"

These are some questions I ask myself in life and in ministry.

In very recent times, I have been learning to see the importance of training. My Pastor (Martins Awe) often says that "a person's training is the greatest prophecy of what they will become". For example, we will say that a person will become a doctor if they are being trained in a medical school, or they will become Pilots because of their training at the aviation school.

Like a soldier being trained for battle, training is not necessarily joyous - yet it ought to be regular (space) and consistent (time) in order for mastery to be formed.

The hanger was set, and I enjoyed the chocolate, drinks, and basmati.

Cheers for now,
Ileri 😀

Follow @ileriayooo on Twitter, where he tweets tech, growth, cloud and computer science.

Free Cloud & DevOps Courses In 2022

Ileriayo Adebiyi — Fri, 28 Oct 2022 08:27:59 +0000

Introduction to Cloud Computing
https://www.coursera.org/learn/introduction-to-cloud
Intro to DevOps
https://www.udacity.com/course/intro-to-devops--ud611
Cloud Native Fundamentals
https://www.udacity.com/course/cloud-native-fundamentals--ud064
DevOps Culture and Mindset
https://www.coursera.org/learn/devops-culture-and-mindset
Introduction to DevSecOps
https://www.coursera.org/learn/introduction-to-devsecops
Developing Cloud Native Applications
https://www.edx.org/course/developing-cloud-native-applications
Continuous Delivery & DevOps
https://www.coursera.org/learn/uva-darden-continous-delivery-devops
Introduction to DevOps and Site Reliability Engineering
https://www.edx.org/course/introduction-to-devops-and-site-reliability-engineering
Developing Cloud Application with Node.js and React
https://www.edx.org/course/developing-cloud-applications-with-nodejs-and-react
Continuous Integration
https://www.coursera.org/learn/continuous-integration
Docker for Beginners
https://www.eduonix.com/courses/Software-Development/docker-for-beginners
Introduction to Kubernetes
https://www.edx.org/course/introduction-to-kubernetes
Introduction to Cloud Infrastructure Technologies
https://www.edx.org/course/introduction-to-cloud-infrastructure-technologies
DevOps basics for everyone
https://www.edx.org/course/devops-basics-for-everyone
Continuous Integration and Continuous Delivery (CI/CD)
https://www.coursera.org/learn/continuous-integration-and-continuous-delivery-ci-cd

Follow @ileriayooo on Twitter for more on Cloud and DevOps

My First Introduction To The Cloud

Ileriayo Adebiyi — Mon, 13 Jun 2022 08:50:36 +0000

While reading the book “Cloud Native Infrastructure”, and on getting to page 34-35, I read the words “In July of 2014 an open source tool that embraced the idea of a higher level abstraction for infrastructure as code was released. The tool, called Terraform, has been fantastically successful. It was released at the perfect time, when configuration management was well established and public cloud adoption was on the rise. Users began to see the limitations of the tools for the new environment, and Terraform was ready to address their needs.”

This made me pause to think, when did I first hear about the cloud? In retrospect, I was surprised to recall that sometime in 2013/14 there was a talk around Microsoft Azure back in FUNAAB.

I can’t accurately remember the hall we used for the event, but oh, I remember there were Azure stickers.

(Somebody spoke about building a news app by consuming APIs. This must have been a tech conference, no idea)

There was this thing about free Azure credits for students, however, the cloud was vague for a lot of us at the time. Folks just wanted to learn to write code and build apps. There was no immediate benefits for these young undergrads who at the time were more in need of internet data to download C++ and PHP tutorials. To us, the cloud was way ahead of it’s time.