DEV Community: Piyush Mattoo

Ways to test SSL Certificates

Piyush Mattoo — Thu, 14 Jul 2022 15:34:53 +0000

For Externally accessible websites only – Only works with a hostname, can’t use IP address https://www.ssllabs.com/ssltest/analyze.html

For Internally and Externally accessible websites – Can use hostname or IP address Sslyze command line tool - https://github.com/nabla-c0d3/sslyze/releases - current version is 4.1.0

Download sslyze-4.1.1-exe.zip and extract sslyze-4.1.0 folder to local drive
Open command prompt and change to the folder where sslyze-3.0.8 was extracted:
o sslyze.exe --regular [hostname or IP address]
o sslyze.exe --regular ep.firstam.com
o sslyze.exe --regular 172.17.22.117

Running Lambda powered by Arm Graviton2 processor

Piyush Mattoo — Fri, 10 Jun 2022 03:52:19 +0000

Running Lambda powered by Arm/Graviton2 vs x86_64
AWS Lambda Functions Powered by AWS Graviton2 Processor – Run Your Functions on Arm and Get Up to 34% Better Price Performance

Test case flow
The following test case will be using a lambda to call a dynamoDb table

The following test cases with different runtime environments
For the warm state, it will be sending multiple requests for each lambda one by one (lambda concurrency is 1, all request go to the same lambda instance). And on the slides, you can see the duration of the last request.

NodeJS: ARM is a bit fast

DotNet: ARM is fast

Python: ARM is faster

TeamConnect test case
It is under the TeamConnect account utilizing Lambda, DynamoDB, and EventBridge resources.
Also, it is versioning to be able to use multiple architecture in this case x86 and arm64

Arm64

x86

Cost

Takeaway
Arm-based systems and instances are available in public clouds such as AWS.
The computational performance of AWS’s Arm EC2 instances is similar to that of the x86_64 instances.
Considering that Arm instances are significantly cheaper, the cost effectiveness of Arm instances are better than x86_64 instances.
Arm instances perform better with “close to metal” applications. We hypothesize that the operating systems have received more engineering efforts to optimize for Arm than high level application frameworks.

FaaS vs Containerization model

Piyush Mattoo — Tue, 11 May 2021 03:02:43 +0000

Fargate gives us best of both the worlds (serverless as well as container) and it won’t restrict us as Lambda might. Lambda works well when run in asynchronous manner (event driven) say object was uploaded to S3 and some Lambda got triggered as a result. API Gateway integrated with Lambda for request/response model especially for runtime like dot-net (for cold-start) can be problematic for synchronous traffic like web APIs in case milliseconds matter.
Lambda is not multi-threaded so say if Lambda service receives 10 requests then Lambda service will launch 10 Lambdas running our code (ASP.NET entry point), some of those instances might not be warmed up or ready. That’s where (web traffic, request/response synchronous) Fargate shines as its serverless and it takes those 10 requests and run them on the same container so there is no overhead of launching the lambda container impacting performance.

We do need to keep in mind that there is a learning curve for containers, perhaps ECS is less of a learning curve than EKS but operationally we need a team which knows Kubernetes well. When we run Kubernetes in EKS we are still talking about authentication with IAM and AWS's ELB, VPC and perhaps we integrate with S3, DynamoDB and at that point we are already committed to AWS. Hybrid cloud is good if we are running different applications on different cloud providers but not the same application such that at any given moment we can pick it up and drop it in Azure, Openshift OnPrem, GCP unless we build the application to the lowest common denominator of all the cloud providers and don’t take any advantage of any of the good things cloud providers have to provide. In other words if we just use block storage, http APIs and we ran our own databases on VMs we are fine but then we are not taking advantage of the cloud native features that any cloud provider might provide you. That’s typically not the case.
Other consideration is Kubernetes operates in quarterly fashion for releases, only supports n-2 i.e. two revisions behind current version. For larger companies that doesn’t adapt to changes very well, we need to keep this in mind as there will be breaking changes as Kubernetes gains more maturity.
Another consideration especially for bigger workloads (and enterprises who are frugal wrt IP's like FA) is the IP availability and the networking security model.
Lambda can reuse the ENI for a given combination of security group +subnet and if we are looking to adhere to the principle of least privilege 100's of Lambdas could be reusing a security group which will make the security group become more permissive. Same thing for ECS in Fargate mode with one IP address per task. So for a workload needing 200 IP's per AZ that equates to 400 IP's per environment.
EKS and ECS (with EC2 mode) is more streamlined in this regard as depending upon the networking model (say Calico, Kube-router, Romana, Weave-net for EKS) the pods are running with fake IPs which get NAT'ed back to fewer IP's on our network and we are relying on network policies based on matching pod labels to dictate inter-pod communication as opposed to security group(s)

AWS Database Migration Service: Limitations

Piyush Mattoo — Sun, 11 Apr 2021 07:01:12 +0000

DMS, if used with SQL Server in a self-managed context (EC2 or on-prem), supports one-time and ongoing replication in two modes: via MS-Replication & MS-CDC. However if DMS is used in the context of RDS as a source, only MS-CDC is supported. DMS offers a range of Source/Targets and supports heterogeneous database engines and offers a fine-grained control on the replication process. The Schema Conversion Tool (SCT) can be utilized along with DMS for heterogeneous configuration setup, that helps with schema level changes with an in-built code editor and also produces various reports for migration readiness & planning.
Source/Targets need to be added as end points in DMS and it uses logical replication process under the hood using either MS-Replication or MS-CDC. In a Hybrid setup or within AWS, DMS can be configured between on-prem and AWS with an on-going replication configuration using CDC and during the cutover, the DMS migration task can be stopped and the application will be able to connect to the database that is already in sync with the on-prem database avoiding typical delays of restoring Differential backups to bring the target database online etc.

Below are some of the associated limitations when using SQL Server databases as the source for DMS:

How large are our databases?
How many tables do we have in each database?
Do we have primary keys on all the existing tables? (This is highly recommended for DMS)
Do we have any identity columns?
Do we use truncate tables? How frequently?
Do we have temporal tables?
Do we have any column level encryption today?
How often are DDL's executed?
SELECT * INTO new_table FROM existing_table is not supported. Do we do that frequently?