Solving Caesar Cipher​

In this post I will share my experience solving the first Google FooBar Challenge.

While doing some search on Google, I received an invitation to participate in a code challenge by Google. I had no previous idea about it, frankly never heard of it. I accepted the invitation and I was redirected to FooBar. After log in, a CLI with the instructions about the challenge and how to request a challenge was provided. The challenge had to be solved within 2 days.

The Challenge​

Decrypt a code where every lowercase letter [a..z] is replaced with the corresponding one in [z..a], while every other character (including uppercase letters and punctuation) is left untouched. That is, 'a' becomes 'z', 'b' becomes 'y', 'c' becomes 'x', etc. For instance, the word "vmxibkgrlm", when decoded, would become "encryption".

Constraints for the solution:

• Java 8
• Limited execution time
• Prohibit usage of third-party libraries
• Parallel processing disabled
• Character limit to around 3000 (I don’t remember exactly)

The storage management system​

Review previous parts of this series for better understanding:

• Kuberenetes Overview
• Kubernetes Objects
• Kubernetes Components
• Kubernetes Service
• Kubernetes Controller

This is the sixth part of the Kubernetes series. In this part I will try to add more insights into Kubernetes Volume

Volume

Volumeis simply an abstraction of data in the form of file and directory within a Pod. It exists as long as its Pod exists.

The lifecycle of a Volume is tied to the lifecycle of the Pod, but not to that of a Container. If a container within a Pod dies, the Volume persists and the newly launched container will be able to mount the same Volume and access its data. When a Pod gets restarted or dies, so do its Volumes, although if the Volumes consist of cloud block storage, they will simply be unmounted with data still accessible by future Pods.

The brain of the system that keeps track of all the other parts.​

Review previous parts of this series for better understanding:

• Kuberenetes Overview
• Kubernetes Objects
• Kubernetes Components
• Kubernetes Service

This is fifth part of the Kubernetes series. In this part I will try to add more insights into Kubernetes Controller.

What is a Controller in Kubernetes?

A Controller is a non-terminating loop that regulates the state of a system. It watches the state of the cluster, then make or request changes where needed. Each controller tries to move the current cluster state closer to the desired state. There are different types of controllers for specific purposes.

Kubernetes Control Plane

Kubernetes Control Plane is a collection of the Controllers. kube-apiserver, kube-controller-manager and kube-scheduler are the three critical processes that makes up the control plane. Nodes that runs these processes are called Master Node which are replicated for availability and redundancy.

An important component that manages routes and containers.​

Review previous parts of this series for better understanding:

• Kuberenetes Overview
• Kubernetes Objects
• Kubernetes Components

This is fourth part of the Kubernetes series. In this part I will try to add more insights into Kubernetes Service.

What is a Service in Kubernetes?

A Service groups Pods together that perform the same function as a single entity. It keeps track of containers in the Pods and routes to the containers for internal and external access. A Service’s IP address remains stable regardless of changes to the Pods it routes to, which makes it easy to gain discoverability and can simplify containers designs. By default, Services are only available using an internally routable IP address, they can be made available outside of the Cluster by choosing one of several strategies.

Types Of Services

There are 4 types of Services, specified by the type field in the Service Configuration File:

A quick look at the building blocks in simple terms for quick understanding.​

Review previous parts of this series for better understanding:

• Kuberenetes Overview
• Kubernetes Objects

This is third part of the Kubernetes series. In this part I will try to add more insights into the essential parts of Kubernetes. I will add more details on the topics in later in the series or there will separate posts as the topics needs.

Container

Container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. The container runtime is responsible for starting and managing containers.

Kubernetes

Kubernetes is a powerful container orchestration system that can manage the deployment and operation of containerized applications across clusters of servers. In addition to coordinating container workloads, Kubernetes provides the infrastructure and tools necessary to maintain reliable network connectivity between your applications and services.

Node

A Node is physical or virtual machine. Every cluster must have at least one Master Node which controls cluster, and one or many Worker Node that hosts Pod.

Essential building blocks of the complicated system.​

Review Kuberenetes Overview

This is the second part of the Kubernetes series. In this part I will try to add more insights into Kubenetes Objects.

Kubernetes Objects

Kubernetes Objects are persistent entities in Kubernetes. All objects have unique names that allows idempotent creation and retrieval. These objects are stored in etcddatabase as a key-value pair. Objects can categorized as the Basic Objects which determines the deployed containerized application's workloads, their associated network and disk resources, and Higher Level Objects which are build upon the basic objects to provide additional functionality and convenience features to manage the workloads. Higher level objects have a long-running service-like lifecycle, except Jobs.

• Basic Objects: Pod, Service, Volume and Namespace
• Higher Level Objects: Replication Controllers, Replication Sets, Deployments, Stateful Sets, Daemon Sets Jobs and Cron Jobs

Every Kubernetes Object definition is a YAML file that contains at least the following items:

• apiVersion: The version of the Kubernetes API that the definition belongs to.
• kind: The Kubernetes object this file represents. For example, a pod or service.
• metadata: This contains the name of the object along with any labels that you may wish to apply to it.
• spec: This contains a specific configuration depending on the kind of object you are creating, such as the container image or the ports on which the container will be accessible from.

The easiest way to visualize components and how they work.​

This is the first part of the Kubernetes series. In this part I will surficially touch things realted to Kubenetes quickly.

Evolution Of Hosting

Traditionally, applications used to run on one or more Physical Servers. The main drawback was that they did not scale well as resources were not utilized to the maximum. Virtual Machines solved the problem and enhanced security of applications by providing isolated environments which enabled adoption of distributed systems tremendously. Then, with the large number of applications running in the Virtual Machines, maintenance started to become cumbersome. Now there are Containerization technologies which solved the problems of Virtual Machines by abstracting and enhancing their entire functionalities. Kubernetes has made it extremely easy to manage the Containerized Applications.

Kubernetes Architecture

Building a static website with GatsbyJS.​

The recent trends of static websites built with JAMStack is on the rise. Free hosting providers such as Github and Netlify has made JAMStack more attractive.

I have choosen GatsbyJS to develop this website.

Why Gatsby?​

Gatsby is open-sourced blazing fast modern site generator with a great community. It is build on top of ReactJS with GraphQL as the data provider and uses Webpack to build Progressive Web App easily.