Benyamin's playground

While I don't claim to be as prescient as  Nostradamus , I've had an idea about a major change in cloud service provider offerings for the past two years. Recently, I came across news of a collaboration between Microsoft Azure and Oracle Cloud, which gave me a sense of déjà vu.  Hybrid-cloud and multi-cloud are gaining popularity, and companies like  aviatrix  are offering services and products to facilitate these options. However, multi-cloud also presents challenges, such as the complexity of enabling private communication between workloads across different providers and the additional cost of networking ingress and egress.  I predict that major CSPs, such as Amazon and Microsoft, will recognize the demand for other providers' services and offer multi-cloud capabilities as a native feature, without the need for extensive manual configuration or third-party tools.  I envision a future where an AWS VPC can connect to an Azure VNET in a specific subscriptio...

A common and on-going challenge for teams is how to manage their sensitive credentials like DB connection strings, Storage Keys and etc... And the market is not in short of tools that can help to store and retrieve these secrets. tools like AWS Secret Manager, HashiCorp KeyVault, Azure Key Vault. But even with this nice tools governing these systems and putting best practices around how developers and app retrieve these credentials and rotating them on a regular basis is a challenge that has no silver bullet for it. Managed Identity comes handy to eliminate the needs for developers to manage/rotate credentials any longer.      The current situation at my client: In the current team I am working the application relies heavily on SQL Server that is hosted in Azure SQ. Both Developers in their local environment as well as the App running in Azure AKS are accessing SQL DB via the conventional Connection String that consist of Username and Password. we have created a new SQ...

I am lucky enough to work both with Azure AKS, and AWS EKS(EC2), and I decided to dedicate a post on my blog about the two. I have also to admit that this is the most opinionated post I have written so far. I tried to put more emphasises on their differences than to write about their similarities. Here are the three areas I comparing them:  AKS vs EKS from Cluster Management Standpoint,  AKS vs EKS from Networking Standpoint,  AKS vs EKS from Scalability Standpoint AKS vs EKS from Cluster Management Standpoint  Both AKS and EKS mange the master node (AKA Data plane) for you completely, and there isn't much difference I notice in that area between the two. However, Azure does not charge you anything for the Master node it manage and you only pay for the worker nodes, however, EKS charge you a fix price monthly for that Master node (around USD 70 dollar depending on the region) One feature I like in EKS is called Managed Node Groups . This feature automate and off...

if you have ever deployed an AKS cluster, either through the Azure Portal or CLI, there is parameter that needs to be configured related to the networking part of AKS and that is to choose the networking model between  Azure CNI and  Kubenet. ( by default it's Kubenet as of writing this post) So what's this all about? in a nutshell this parameter is related to how Nodes and Pods gets their IP addresses assigned. It\s important to understand their difference before creating the cluster since you can\t change the networking model of your cluster once it\s deployed, and you defiantly don't want to re-create and re-configure your cluster again just because of this option. Overview of Kubenet and a few things to keep in mind This is the default options if you don't explicitly change it. With this option the cluster nodes gets their IP addresses from the VNET which your AKS is deployed to. This is not a big deal since the same thing happens if you go with the second option, ...

Over the past 6 weeks, I have been working tirelessly on pre-study program together with two other colleagues for a client who is a large enterprise that has presence in over 100 countries. (I can't share more details about what they do) The client is facing challenges related to their massive amount of  DATA.  They have different enterprise systems such as ERP, CRM, Product Management, Order Management, and etc in different regions and none of them is connected to the other, and there are little to no governance around them. This has resulted issues that they have no clue how to overcome, not only millions of dollars are being wasted every year, but also they are unable to make any sense from their data unless with manual intervention and help of excel and some other tools. Another issue is the duplication of data, for instance their customer data is stored in CRM system, but then it has been manually copied over to the Order Management system for creating the Order with...

 I have been wanting to setup an A\B split with specific weight ratio between two services in my cluster, but had no clue how to achieve that. I am aware of the fact that if I were to use almost any Service mesh such as I stio, Linkerd, Consul , and etc... then this would be something that is supported out of the box, but how about when I don't have Service mesh? Well, I did a little bit of research and at the first sight I didn't find much clue on how this can be achieved. Take a look at below image to understand what I am trying to achieve here: As you can see, I have my Ingress Controller with two services, what I am trying to achieve is that when my nginx controller get the request is routes it 70% of the time to Service A, and 30% of the time to Service B. After digging a little further I found the answer lies in the nginx official document here . it's a annotation called Canary that enables routing between services using either of the following conditions: Header : yo...

Kubernetes can take care of many things, and can solve many problems except the ones it doesn't know about such as region failure and  human errors. In this post I want to compare and contrast the differences between Single Cluster setup spread across multi Availability Zones that is very common vs Multi Cluster Setup Spread across different Region . Hopefully by then end of this post you have some clue about when to use which setup no matter which cloud provider you are using; be it AWS, Azure, or GCP. Single Cluster Setup: In this Setup the Kubernetes nodes and their storages are distributed across multiple Availability Zones (AZ). This model ensures the nodes are physically separated from each other and the outage in one of the AZ will not cause the entire cluster to go out of service. At the same time the communication between each node is via private connection and does not route over internet no matter which cloud provider you use. I took the following image wh...