DEV Community: Yusuf Giwa

The engine, then the Pilot

Yusuf Giwa — Thu, 07 Jul 2022 22:59:24 +0000

In a monolithic architecture, all the layers of our applications are built into one single artifact. In this case, each service offered by the application is essentially a function call away from another service. This facilitates the networking and communications between the layers of the applications. However, things can get rocky when it comes scaling a part of the application, it is essentially the same cost as scaling the whole application. It becomes difficult to upgrade a layer of the application without causing failure in another unrelated layer.
Micro-service gives us the ability to re-architect our applications into different services such that they can be built, deployed and scaled independently. The services can communicate using an Application Programming Interface, API.

To achieve a micro-service architecture, we can use container images as our artifact.
Container images are convenient artifacts for software development. We specify the all the dependencies needed to execute code inside a container in a YAML file called Docker file, we can build this file to create our Docker image. The Docker image is a largely static file that can be deployed on any host without any changes.
Container images readily serve as the engine driving each services and they accelerate our ability to build applications.

Finally, we need a way to deploy, scale and update these containers. This is where kubernetes comes in.

Kubernetes is an orchestration system for containers. We can create a kubernetes cluster to run our containers, deploy an existing app to the cluster, expose application ports, scale applications and update applications.
Kubernetes helps us get our applications in front of our customers with maximum up-time using declarative configuration and automation. All we need to do is describe the desired state of the system using objects like pods and services in a YAML file. A kubernetes controller observe the current state of the cluster and brings the system to the specified state. We can do all this from the terminal using kubectl, kubernetes command line tool.
Kubernetes is like a pilot for our workload, while we set the destination.

Now that we are convinced about containers and container orchestration, the next step is to have fun building docker images and managing container orchestration with services like Amazon Elastic Container Service (Amazon ECS) and Amazon Elastic Kubernetes Service (EKS). We can also venture into extending kubectl binary with plugins for authentication. Finally we can establish fine-grained access on our clusters by using self-manged options like Kops and Kubeadm.
If all of these excites you, you should read this googles' article om different generations of containers here. You might want to check this out, I tried to explain some technical terms from the google article.

In our micro-service architecture, the container image can serve as our engine, whilst kubernetes is the Pilot. Happy learning!

I explained googles lesson on their container management systems so you can have fun reading - 1

Yusuf Giwa — Thu, 30 Jun 2022 22:55:57 +0000

Disclaimer : These are majorly notes and summaries i made while reading this article - "Borg, Omega, and Kubernetes: Lessons learned from three container-management systems over a decade".

I strongly recommend everyone using container systems should have a read.

Free BSD(Berkely Software distribution) mechanism is an implementation of OS Level virtualisation which allows us to partition Free BSD derived computer into independent mini systems sharing the same kernel with little overhead.

DRAM(Dynamic Random Access Memory) is a type of semi conductor memory that is used for program code or data needed by the computer to function. DRAM is used to access large amount of info needed by the computer quickly.

L3 memory cache is developed to increase the performance of L1 and L2 cache. In multi-core processors L3 cache are usually shared among cores while L1 and L2 are dedicated.

Containerization started with chroot (an os level virtualisation on the kernel) —> Then, FSB jails extended the contexts to namespace like process ID. —> Then, Solaris enhanced these features which are now used in Linux control groups today.

0) The resource isolation by google improved utilization.

Borg uses containers to co-locate latency sensitive, user facing batch jobs on the same VM’s. Because user facing jobs reserve more memory than needed so when there’s a spike and fail-over they can use that extra memory.

This isolation is not perfect since the containers cannot prevent interference in the resources that the OS kernel doesn’t manage such as L3 cache and memory bandwidth. Containers also need an additional layer of security in the cloud.

Containers are now more than isolation, it includes an image which is the make up of the apps in the container. Midas Package Manager MPM is used by google to build and deploy images. The relationship between the isolation mechanism and MPM can be seen in Docker Daemon and Container registry.

1) A container is essentially the runtime isolation and the image.

Containerization transforms the data center from being Machine Oriented to Application oriented. It abstracts details of the machine and OS from the app developer and deployment infrastructure.

The shift of management API from machine oriented to application oriented improves introspection and deployment.

Decoupling of image and OS makes it possible to provide similar environment in production and development environments.

2) To make this abstraction we’ll have a container image that can encapsulate all app dependency into a package that can be deployed into the container. This way only local external dependency will be on the Linux kernel system interface call.

The Linux kernal system is the core interface between the computer hardware and the processes. So the interface calls are how the a program enters the kernel to perform a call.

Combining 1 and 2 we can say Chroot, Chgrp and namespace prevents data leak in the VM and improves resource utilization while the container images isolates the app from the OS.

3) This isolation is not perfect. Applications can still be exposed to churn in the OS via socket options, arguments to ioctl calls and /proc.

A socket is one endpoint of a two way communication link between two programs running on the network. A socket is bound to a port number so that the TCP layer can identify the application that data is destined to be sent.

Endpoint = IP address + Port number.

A server runs on a specific computer and has a socket bound to a port number. The server waits listening to the socket for a client to make a request.
The client tries to rendezvous with the server on the machine and port. It also tries to identify itself to the server so it binds to a local port number assigned by the system that it will use during this connection. After acceptance, the server gets a new socket bound to the same local port and also has its remote endpoint set to the address and port of the client. The new socket is to listen to request of the connected client. The client also creates a socket to communicate with the server. The clients can communicate by writing and reading from their sockets.
read on sockets.
Docker Daemon can listen to Docker engine API request via three sockets types: Linux, tcp and fd.

Input and output control ioctl() system calls manipulate many underlying devices parameters of special files. e.g the terminal. IOCTL recieves the following arguments:

fd must be an open file descriptor.
arg2 is a device dependent request code.
arg3 is an untyped memory pointer.

/proc is a virtual file-system created on the fly when system boots and it is dissolved ant shut down.
If you run: stat /proc
you will see it doesn’t have any size.

Same for all its sub directories obviously.

Despite the flaws mentioned in 3, the isolation and dependency reduction has been effective for google and they only run containers which consequently means they have a small number of OS version and only require small staff to maintain them.

There are many ways to achieve these images. In Borg, program binaries are statically linked at build to known libraries available company-wide. This is still bad because upgrades on the base image can affect running applications as the image are only installed once and shared by multiple programs.

Binaries are compiled code: They allow programs to be installed without having to installed without having to compile the source code.

Libraries are a collection of standard programs and subroutines(think macro?) that are available for use.

Modern containers require explicit user commands to share image data between containers trying to the issue of dependencies.

Remote Procedure Call (RPC) is a software communication protocol that one program can use to request a service from a program located in another computer on a network without having to understand the network detail. i.e It lets a program execute a procedure in a different address space without having to explicitly code details of remote interaction.

Borg Naming System BNS name for each task includes cell name task number and job name. This is written in a highly available file in chubby. which is the used by the RPC system to find task endpoints.

Chubby is a highly available and persistent distributed lock service and file-system. It manages locks for resources and stores configuration information for various distributed services in google cluster environments.

Chubby Distributed lock is a filesystem that provides reliable storage for loosely coupled system. It provides a coarse grained mechanism using locking service, Library storage, and high throughput rate.

Chubby cell contains a 5 servers called replicas. The elected master are elected by a distributed protocol like round-robin or berkeley’s algorithm.

Master duration is the duration in which no other master would be elected by replicas that have once voted for a master.

Files and directories are known as nodes. contained in the chubby namespace. Every node has a distinct meta data.

Handle specifies include check digits, handle seq no and mode info. They are file descriptors for opened nodes.

It implements is reader writer locks.

Distributed locks is complex thereby making is costly since it permits only using lock interactions. They also have status which are described as strings called sequencies.

Roundrobin is an arrangement of choosing all elements in a group equally. i.e. They take turns in a logical order like top to bottom.

Berkeley’s algorithm or clock synchronization is a method of synchronizing clock values in a distributed system by using external reference clock. It assumes that each node doesn;t have a accurate time source.

Happy Learning, I hope you have fun reading the paper.

Ansible - Cool

Yusuf Giwa — Tue, 21 Jun 2022 21:44:46 +0000

We have decided that automating repetitive task is important in having consistent delivery of services. Configuring our newly provisioned servers is one of such tasks. However there are not much human-readable configuration solutions out there.

In simple terms, Ansible is an open source configuration tool for configuring servers after deployment. It completes automation tasks with a blue print known as "ansible-playbook". Ansible playbook is a "yml" file(e.g ansible-main.yml") that can execute tasks on specified machines. The tasks are split into a separate folder named roles with sub-folders that has the role name as title and "main.yml" file. It also has an inventory.txt file that has the address of each server that the script will run.

This is what a typical ansible directory looks like:

We can run an ansible playbook with the command:
ansible-playbook main.yml

This is the result of running a simple ansible playbookon on a local machine.
The code can be found on github here:.

Ansible is declarative such that ansible tasks describes the state of the computer and ensure the tasks end up in the state that was specified. However, It allows us run tasks in a specific order making it imperative. Safe to say it has a mixture of both.
During setup, ansible runner gathers facts about the target node, so it knows the current state of files(everything in Unix is file :)) so that while it runs, it knows whether a specific file exists on the computer and if it is already in the final state. This makes ansible idempotent.

Ansible execute tasks using its modules.
Package management:
Ansible has modules for different package managers to install, remove and upgrade packages on the target node modules. Some of the modules are apt, yum, dnf, and zypper. The modules name are similar to their corresponding generic name.
For example, we can use the apt module to install nodejs and npm on our machine.

Here we used the apt package to install the latest version of nodejs and npm. The runner will need admin privileges on the target node to perform the operations. The syntax “become: yes” helps us use an elevated privilege to perform such tasks.

Other popular modules on ansible are:

Copy: The copy module copies a file from the local or remote machine to a location on the target remote machine.
Shell: It is used to execute shell commands in nodes.
File: It is used to set attributes of files in a module.
git: Deploy software (or files) from git checkouts Here is a list of core ansible modules.

Ansible has all these cool features and can be used to configure more than just servers, It can configure any machine with ssh interface or a callable API such as load-balancers and other networking tools. Personally, i like to include my ansible-playbook as a job in a Circleci pipeline to configure the infrastructures i have just deployed. Doing this will ensure i get consistent configurations in as much servers as i want.

I found this well written article Ansible Tutorial for Beginners: Ultimate Playbook & Examples. You should definitely give it a read for more in-depth examples on Ansible.

The idea is to automate as much as we can, till we can boast of a perfect deployment pipeline. Happy Learning!

Overview of continuous Delivery

Yusuf Giwa — Tue, 14 Jun 2022 22:39:42 +0000

In a bid to deliver software solutions to costumers efficiently, companies are looking to inculcate techniques and practices that will improve the quality of their code and optimize the time and resources required for deployment. A popular approach these days is continuous delivery.

Continuous delivery is an approach where value is delivered frequently through automated deployments. It is often seen as a philosophy that facilitates the use of techniques that lets organizations build, test, and prepare code changes for release to production rapidly and efficiently. These techniques can be split in Continuous integration and continuous deployment. Continuous delivery practices can be directly translated to economic terms or metrics.

Continuous Integration is a practice where developers merge working copies to a shared mainline several times a day. This includes operations such as building artifacts, running tests and code analysis.
Continuous deployment is a practice where teams produce and release values a short time. This includes operations such as deployment, verification and promotion to production.

These are some good practices to build a continuous delivery pipeline:

Fail fast: This means the quicker we get to the error the less resources are wasted.
Measure code quality: There should be metrics to measure the quality of code in our pipeline such as Lead time to production, and roll back rate.
Only one road leads to production: All potential loopholes should be eliminated in order to utilize the pipeline.
Maximum automation: We should automate tasks as much as possible to reduce human error and increase speed of delivery.

It should be noted that these continuous delivery practices should not be seen as an absolute pedestal but as true North that will help the organisation reach steady improvement.
CI/CD can be achieved with configuration tools like Ansible or chef and pipelines like CircleCI or Jenkins as well as version control tools like git.
Happy learning!

Cloud Formation good practices

Yusuf Giwa — Tue, 07 Jun 2022 22:11:57 +0000

Using AWS Cloud formation templates to deploy our infrastructure such that it can be easily reproduced consistently and it can also be incorporated in an automation scripts is increasingly becoming the default. There are lots of positives to Infrastructure as a code. However, when deploying huge infrastructures, the templates can become unreadable or even lead to security leaks. In these article we will be looking at some practices we can incorporate in our templates to help us mitigate these issues and facilitate readability.

Using Parameters:
This means we will not be hard-coding values in the templates. Declaration of Parameters facilitates re-usability of our template.
Parameters are declared at the beginning of the template under the "Parameters" section to be referenced in the "Resources" section. They are stored in a parameter file usually in a JSON format where there are called during the creation or update of our infrastructures.
Parameters can also be grouped based on resource types i.e server-group, network-group e.t.c which aids readability.

Using Dynamic Reference:
It is usually a good practice to store values in external services for reasons such as version control, security, etc.
We can reference external values that are stored in services like secrets in AWS Secrets Manager or plain-text values from AWS Parameter store with dynamic reference. A maximum of 60 dynamic references can be used in each templates. Dynamic reference are used with the following pattern:
{{resolve:service-name:reference-key}}
Where service names are ssm, ssm-secure and secretsmanager.
Note that it is not advisable not to use dynamic referencing for values that are part of the resource primary identifier as this would lead to secret leak when the resource is refernced.
You can read more on dynamic reference in the AWS documentation.

Using Mappings and Conditions:
There are several region dependent values or pipeline-stage dependent resource properties, it can be a hassle trying to get the right value for the different regions the templates will be used or the different deployment stage such as development or production stage. The Mappings section of the template consists of key-value pairs declarations such that values can be called by referencing the key.

The conditions section of the template contains statements that defines entity configuration or creation. The statements are then attached to the concerned resources with the use of the optional "Condition" property.

Mappings and Conditions can also be combined such that if a condition is satisfied we might configure the resource by referencing a value based on a key from the satisfied condition. This one condition can be used to influence more resources in the template since we can have the same key name in different mapping declaration.

Cross-stack Referencing
We might decide to create different templates for different resource groups or different resource level. These resource will somehow still need to refer to each other. i.e we will need to reference the VpcId created in our network-stack when we are creating the security group of a server. This is where cross stack reference comes to play. We are able to reference the resource created in a stack in another stack.
We can export these values in the Outputs section of our template. These values can then be referenced using the intrinsic ImportValue fucntion.

We have now discussed several Cloud formation tricks and practices. These can only be useful when they are used in the right contexts else we would have a lot of redundant parts in our template which will not produce the desired result.
I attempted to incorporate some of these practices here.

Happy learning and building.🛠️