DEV Community: Omer Sayem

Infrastructure as code: part-1 (Terraform to emancipate?)

Omer Sayem — Sat, 22 May 2021 19:28:50 +0000

Lately, I have been working on a project, which is based on cloud-native architecture (AWS) and I was in a dilemma about the perfect IaC solution. Despite going into detailed project requirements,simply added the draft diagram below.

Now, from the above diagram, it is quite conspicuous that this system is based on some AWS components and it's a messaging system. Firstly, it maybe seems overkill to think about the IaC solution deeply. However, In the long run, it can save a ton of deployment time. Thus, I decided to leverage the IasC solutions, which codifies the entire architecture. There are several tools for managing serverless applications, such as AWS SAM, serverless framework, and terraform. However, for the sake of minimality, I will decide between SAM and serverless framework in this part.

On the one hand, the serverless framework is a provider-agnostic solution. Thus, its possible to deploy FaaS functions into multiple serverless vendors. Interestingly, the Deployment process is magical (Creates s3 buckets to store artifacts automatically) in SF, and indeed, it's easy. Offline testing needs to install an extra package(serverless offline) and does not need a docker.

On the other hand, as SAM is an abstract layer of AWS cloud formation, it is easy for running AWS users. Moreover, it consists of fewer boilerplate.SAM Local creates the same environment as Lambda, which spins up local API gateway and then runs function in docker. Finally, it has deep integration of AWS tools for debugging, testing, and development such as AWS Serverless Application Repository, AWS Toolkit for Visual Studio Code, AWS Cloud9 IDE, Jenkins plugin.

Considering the above options with my solution, I decided to stick with SAM:

Owing to this solution is utterly based on AWS, it will be overkill to use a multi-cloud solution tool.
Development and testing with the more AWS-like tools with SAM may ease the process.
Local development will be more likely to AWS Lambda.

So, until now, AWS sam looks like the perfect solution. Is it really? What about if the business wants to scale it beyond serverless applications? Also, for a big project Cloudformation template is manageable? ( I will give my opinion on part 2, till share your experience )

P.S. Just to ensure, I might provide the entire solution on Github once it is completed.

My First three month as a Machine Learning Engineer

Omer Sayem — Mon, 09 Nov 2020 17:12:21 +0000

It's been about three months since I'm working as an MLE. The most frequent question I've been asked is that I don't have any ML research, how I am working! This is true that I've been working as an SWE since early 2019 and I have research in a distributed system for the automotive industry and yet not published! What I experienced in these three months is there is a good borderline between MLE and ML researchers. and obviously MLE vs SWE.

Firstly in SWE, everything is practical, you get immediate feedback on everything you do, It may be good or bad ! whereas MLE is extremely ambiguous. The problem might be in data cleaning, hyperparameters tuning, wrong models selection, or even wrong data for training, etc.

Secondly, ML researcher are smart people who can build interesting models, insights, predictions and also use some libraries on the other hand MLE can write maintainable, sustainable code, efficient way to store the data, and deploy the models so that it can be accessed from almost every machine and at the same time should understand the models, basic understanding of the maths behind the model.

These are my experience, correct me if I am wrong. One thing I mentioned first about academic research or advance higher degree. To some extent, I think it will be beneficial to do Msc in applied mathematics or specialization in ML if an experienced MLE wants to pursue more.

Ephemeral Diffie-Hellman Algorithm, Handshake you need even in pendamic!

Omer Sayem — Sun, 05 Jul 2020 17:33:00 +0000

Did you ever think that how your TCP/IP connection is secured? TCP/IP connection requires sync and acknowledgment sending data between server to the client also known as a handshake.

Communication between two computers in TCP/IP connection needs to be secured when it comes to sensitive private data. Only the sender and receiver should decipher the data with a shared key. So this is the kinda idea.

To secure the HTTP connection we came with the idea of an SSL/TLS connection. SSL/TLS connection uses encryption methods to secure the connection. So far we use two types of encryption, symmetric and asymmetric encryption. symmetric encryption uses a strong block cipher to encrypt and decrypt data. On the other hand, asymmetric encryption uses public and private key methods to secure connection. Sounds confusing right? if your key is public how can it ensure privacy!

Relax! Don't panic. A public key is essential by which you can cipher the message and broadcast it with a public key, you can decipher the message if you only have the private key and it kept secret. So it's like the two sides locked door. You may have the public key but can't open the door if it's locked inside with private key! Interesting right? more then 52% of websites today use public-key methods to secure connection. but whats the underlining maths or engineering behind it?

Suppose Alal and Dulal are brothers. they want to share there location information secrecy so their father can't find them. let's see whats they can do with Diffie-helmen,

Step 1: Alal, Dulal agrees to share a share public key pair (G,p), where G = 9, p = 23.

const power = 23;
const generator = 9;

step 2: Alal's Private key a = 4. And Dulal's private key b=3

const alals_private = 4;
const dulals_private = 3;

step 3: Alal and dulal compute public values using
alals_public =(9^4 mod 23) = (6561 mod 23) = 6
dulals_public = (9^3 mod 23) = (729 mod 23) = 16

const alals_shared_public = secretGenerator(generator,alals_private,power);
const dulals_shared_public = secretGenerator(generator,dulals_private,power);

step 4: Alal and Dulal exchange public numbers

step 5: Alal receives public key 16 and
Dulal receives public key 6

Step 6: Alal Dulal decipher the key with their private key
Alal: ka = 16^4 mod 23 = 65536 mod 23 = 9
Dulal: kb = 6^3 mod p = 216 mod 23 = 9

const shared_secret_of_alal = secretGenerator(dulals_shared_public,alals_private,power);
const shared_secret_of_dulal = secretGenerator(alals_shared_public,dulals_private,power);

finally, they got there shared secret 9!

completed code can be found here :

function secretGenerator(generator,power,mod_number){

  return power === 1 ? generator : Math.pow(generator,power)%mod_number ;

}

(function DH(){

const power = 23;
const generator = 9;

const alals_private = 4;
const dulals_private = 3;

const alals_shared_public = secretGenerator(generator,alals_private,power);
const dulals_shared_public = secretGenerator(generator,dulals_private,power);

const shared_secret_of_alal = secretGenerator(dulals_shared_public,alals_private,power);
const shared_secret_of_dulal = secretGenerator(alals_shared_public,dulals_private,power);

console.log(shared_secret_of_alal,shared_secret_of_dulal);

})();

So the final thought is if you have the public keys G and P and the shared public key's you can't decipher the secret because you don't have the private key a and b. And for a large number, this logarithmic calculation is computationally costly.

STUN,TURN and ICE servers - NAT traversal for WebRTC

Omer Sayem — Wed, 10 Jun 2020 15:10:45 +0000

Because of the absence of IP address space and the need to keep a hidden system's engineering obscure to outside clients, NATs are utilized. These decipher inside private IP delivers to outside open IP addresses.Approaching traffic into the private system is steered through an open location restricting that happens on the NAT gadget. This coupling is made when an inside machine with a private IP address attempts to get to an open IP address (through the NAT).

VoIP and WebRTC requires to pass media packets like video/audio into two peers which needs to pass external packets into internal networks.For these situation webRTC needs mechanisms like STUN , TURN and ICE server. Whats these do ! going forward.

We know webRTC is p2p connection. So in a private network connection between two client don't need any server.

But when a client A from private network need to connect to Client B who is in a public network , it gets block by NAT firewall and it doesn't know the public ip to connect. TO rescue first see how STUN server do.

Client query the STUN server for his public ip and STUN provides public IP.With this provided public IP Client A can connect to Client B .

SO, problem solved! Not yet ! STUN servers doesn't provide same public IP if the client call in different servers. so the bindings is not unique. Thats a problem ! another life-saving mechanism is TURN server.

TURN server actually don't provide any Public IP , its relays media . it takes media from client A and provide to client B , without looking the packet. Compare to STUN server it's very much operation expensive. To reduce cost both STUN and TURN can be use in case of STUN server failure .

These STUN and TURN servers has dawbacks.STUN is backend inexpensive but doesn't work always . TURN server is reliable but backend expensive .Finally ICE servers comes handy !

What ICE server do , its holds everything , its a collector . It collects local IP , STUN server's reflexive IP , TURN sever's relay media addess and stored in a remore peer via Session Description Protocol (SDP) . WebRTC client receives the ICE address of itself and the peers and send media through connectivity checking .

Thats all upto ICE server which is used in most of the WebRTC implimentation . Good news there more optimized WebRTC Natting named ICE Trickle . Maybe talks about it some other day . Happy learning !