Summary of Lean Code

May 14, 2020 Leave a comment

This is a summary of concepts explained in  the book by Mary Poppendieck  and talks given by Kevlin Henley

Lean programming (1)

 

Advertisement

Filed under better software engineering, betterideas Tagged with , ,

Root cause Analysis of Coronavirus and possible solutions from the mind of Information technology consultant perspective

March 21, 2020 Leave a comment

As an Information technology consultant, it is my day to day job try to find patterns in challenges faced by my team members.

I am analyzing the current scenario of the coronavirus in Italy, Spain, Germany, and Japan.

Coronavirus Impacts mainly Elders

as per research, it was highlighted that Corona will impact mainly on elders. due to the high standard of the living average lifespan of all of these countries is too high. but I was surprised to see the result of Japan.

Country population in million number of cases till now deaths cases per million average life expectancy
Spain 46.66 24980 1347 535.3621946 82.83
Italy 60 47000 4000 783.3333333 82.54
Japan 126 1007 35 7.992063492 84

but Japan is an outlier in it. So one can say the Impact of Corona to an elder is one of the factors but not the only factor. what is something special in Japan not present in these European countries

Corona was spread when an infected person is in contact with other healthy people

This virus spread during Chrismas season when a lot of international travelers spend vacations specifically Italy, Spain, France and yes China is in top five (Refer)

a1

but Japan has banned entry from china from 1st Feb onwards [Refer]

a2

Past history of disaster management

Japan comes from the background of disaster almost every year due to earthquakes. luckily Europe is paradise on earth hence found relatively fewer disasters. it is one of the reasons for effective incident management don’t you think so?

Cultural Habits

Japanese people like to bow when they meet each other instead of handshakes. it reduces the problem of this virus

Summary

  • try to solve problems at the early stage instead of  things are almost spread
  • practice habits such as avoid contact with people
  • better disaster recovery

 

#spreadpositivity #betterlife

 

 

 

 

Filed under Ideas for better life

Ideas for better Infrastructure as a Code (IaaC)- Terraform

March 6, 2020 Leave a comment

Learning  syntax of any programming language is easy but semantics is not that much easy

Purpose

how to manage tags effectively with fewer errors when designing the Terraform module.it will provide a lot of benefits for tracking resources for cost, monitoring

Thought process

Currently, we can find a huge amount of terraform modules on various version control systems like Github, bitbucket…..

as per my understanding, IaaC tools like terraform provide a lot of benefits in terms of automation but if not designed properly it creates a lot of challenges for monitoring, cost tracking and security. care must be taken from the beginning otherwise it is challenging once it goes in production I tried my best to avoid various anti-patterns when we design any terraform module.

I had started contributing to avoid these anti-patterns by publishing my terraform modules on terraform registry. although these modules are for AWS same thought process can be applied to designing modules for other cloud providers.

the main motivation for designing these modules is to make the life of any Cloud Engineer easy and productive. instead of working on some useless tasks like finding resources that are not tagged, removing Ec2 in the public subnet.

Please refer to the mindmap which mainly highlights common mistakes we make while tagging or naming resources.

MindMap for designing better terraform module

https://registry.terraform.io/search?q=polganesh

 

Filed under better software engineering, Cloud Tagged with , , , ,

AWS Certified Solution Architect Professional Mind Maps

March 2, 2020 Leave a comment

Domain 1: Design for Organizational Complexity 12.5%
Domain 2: Design for New Solutions 31%
Domain 3: Migration Planning 15%
Domain 4: Cost Control 12.5%
Domain 5: Continuous Improvement for Existing Solutions 29%

{Please note it is still in draft phase. I am planning to add more content to this page in future}

  1. Design for New Solutions
    1. Security
      1. DDOS
      2. CloudHSM
      3. AWS Shield
      4. AWS Key Management
      5. VPC Peering
      6. NACL
      7. VPN , Direct Connect
    2. Maintainance
    1.  Performance
      1. Elastic Network Interface
      2. Enhance Networking
      3. Placement Group
    2. Providing more than one benefits
      1. VPC End Point (improve security, performance, cost-saving as well)
    3.  Miscellaneous
      1. Load Balancer
      2. API Gateway
      3. Kinesis
      4. Route 53
      5. NAT Gateway
      6. RDS
      7. ECS
      8. EFS
      9. SQS
      10. Autoscaling
      11. NoSQL
        1. DynamoDb
  2. Continuous Improvement for Existing systems
    1. Lambda
    2. API Gateway
    3. S3
  3. Design for Organizational Complexity
    1. Maintaiance
      1. Logging
        1. CloudWatch Logs
        2. CloudTrail
        3. VPCFlow Logs
        4. AWS Config

Filed under Amazon web services Tagged with , , , ,

AWS API Gateway

February 16, 2020 Leave a comment


Read more of this post

Filed under Javascript

Compare AWS with Azure networking

October 20, 2018 Leave a comment

AWS Azure Important Notes
1 Virtual private cloud (VPC) Virtual Network
2 Subnet Virtual subnet In AWS subnet is specific to Availability zone i.e. one to one relationship between AZ and subnet

but in Azure we can have subnet span across multiple Availability zone i.e. One subnet can be mapped to multiple to AZ.
Access control      
3 Network access control list (NACL) NACL is stateless in AWS.

Azure don’t have any substitute for it.
4 Security group Network security group
  • Both are stateful.
  • Network security group can be applied to VM or subnet.
  • When applied to a subnet it is still enforced at the vmNIC. It is not edge device.
  • Lowest priority means higher in priority.
Load Balancer      
5 AWS Elastic load balancer Azure load Balancer
  • App gateway also has optional web application firewall components.
  • Both load balancers have health check mechanism to avoid sending traffic if any VM is not up.
  • Elastic load balancer and azure load balaner both are type 4 load balancer
  • AWS application load balancer and Azure APP Gateway both are type 7 load balancer.
6 AWS Application load balancer Azure APP Gateway
connect other networks on premises or in cloud      
7 VPC Peering Virtual network peering
8 VPN VPN
9 Direct Connect Express route (Dedicated Connection)
DNS      
10 Route53 Azure DNS
  1. In AWS Route 53 provide both
  2. DNS hosting services
  3. Endpoint balancing.
  4. Azure DNS Provide DNS zone hosting service.
  5. Azure traffic manager Provide DNS based service balancing.
  6. It can load balance based on (Requesting user (based on latency , Round robin ,Failover Geography)
  7. Targets can be VM in azure, PaaS Service, Other Traffic manager instances, On Premises services.
11 Azure Traffic Manager

Filed under Amazon web services, Azure, Cloud Tagged with

Cheat Sheet-Amazon Web Services – Networking -Route 53

April 24, 2018 Leave a comment

Introduction

  • Route 53 is AWS’s proprietary DNS service.
  • AWS written Route 53 from scratch i.e. do not use any code base, service for implementation.
  • What is DNS?
  • It can be consider as Domain names to IP mapping.
  • It is helpful for converting human friendly domain names into IP addresses by machines.
  • Why Route 53 name for AWS DNS?

By default DNS use default port 53 for TCP or UDP for communication.

  • Route 53 is global service not specific to any AWS Region.
  • It has API which help us to programmatically perform various operations.

Important Concepts for DNS

IP address types

  • IPv4
  • Represent 32 bit i.e. nearly 4 billion IPv4 addresses
  • IPv6
  • Represent 128 bit
  • Need: – every time when we add new device on internet we need to represent it with some unique identifier. As more and more devices available on internet and due to IOT devices we ran out of IPv4 addresses. IPv6 help us to resolve this IP scarcity issue.
  • Till Dec 2016 AWS don’t support IPv6

Domain registrar

  • Domain registrar is authority which ensure uniqueness of domain names to avoid duplication
  • Domains are registered with InterNIC and WhoIs database
  • Example of domain registrar
    • GoDaddy
    • Recently Amazon became domain registrar hence become bit easier to work with DNS

TTL

  • Indicates Time to live
  • It indicates amount of time DNS record cached on resolving server or user’s own PC.
  • It represented in seconds
  • Example :- whenever we request any specific domain name then our PC will check if it has address associated with this domain or not. If not then it will fetch it from resolving server. As soon as our PC receive IP associated with domain name it will cache that specific IP for time period of TTL. For next request our local PC will request it from cache and not from resolving server.
  • Caveat for DNS migration :- if we are adding additional
  • A record or
  • additional service to our production website
  • or moving application to AWS
  • Then many websites reduce TTL record to 300 seconds so that changes replicated across all client machines and then wait for previous TTL period.
  • If we don’t do this then few of our client request will go to old site while other go to new site.
  • Many applications have TTL by default for 2 days.

Caveat

  • We cannot use Route 53 to configure instances on premises.
  • We can support on premises DNS to support Amazon VPC.

DNS Records supported by Route 53

Type
A Address Record

§ Used by machine to translate the name of domain to IP addresses

§  Usually one domain name mapped to multiple IP addresses.
AAAA IPv6 Address Record.
PTR Pointer Record

It is exact opposite of A record i.e. it will provide domain name when IP address is provided.

A-AAAA

Reverse lookup i.e. fetching domain from IP
Example for YAHOO IP address

ptr

Type
NS Name Server Record

It is used by top level domain servers to direct traffic to the content DNS server.
SOA Start of authority record.

§   It is very first Name server for our domain name.

§   It gives majority of information for our domain

 

Type
CNAME Canonical Record Name

§   It is used to resolve one domain name to another domain.

§   A record points to IP address but CName points to another domain.

§   E.g. m.amazon.com and mobile.amazon.com both point to same application.

 
Alias ·         This term is specific to AWS

 

  • Need for Alias
  • The problem is with a cname you cannot use the cname in the “apex” of a domain. Meaning mydomain.com cannot point to a cname. But http://www.mydomain.com can.
  • Difference between CNAME and Alias
  • Both Alias and CNAME points to different DNS record.
  • CNAME cannot be used for Zone Apex record (naked domain names)
  • They differ from a CNAME record in that they are not visible to resolvers. Resolvers only see the A record and the resulting IP address of the target record.
What is mean by Naked domain name?
Internet domain name without www or subdomain is known as Naked domain name.

http://computerlanguage.com/ is naked domain

but http://www.computerlanguage.com/ is not naked domain.

Other record types

  • CAA (certification authority authorization)
  • MX (mail exchange record)
  • NAPTR (name authority pointer record)
  • SPF (sender policy framework)
  • SRV (service locator)
  • TXT (text record)

Routing Policies

Simple

  • It is default routing policy
  • We can associate A record with multiple IP addresses
  • Requests are handled in round robin fashion
  • Does not perform health check hence if any issue occurred with instance then user will get error message.

Weighted

  • Similar to Simple routing policy with following difference
  • Use to route traffic to multiple resources in proportions that you specify. E.g. if we have three servers then we can set policy to route 50% traffic to first server, 40 % to second server and remaining 10% to third server.
  • Use cases
  • We are having servers of different capacity in that case we can use this policy i.e. routing most of the traffic to server with higher capacity.
  • In few scenarios we might need to get early feedback from customer for newly developed UI. In that scenario we can use this strategy.

 

Latency

  • When our system used from multiple geographic location and our system is also present in multiple AWS regions then this strategy used.
  • Route traffic to the resource that provides the best latency.

Failover

  • Use when you want to configure active-passive failover.
  • Route 53 will perform health check. If health check fails for primary site then it will route traffic to secondary site.

Geolocation

  • Use when we are having application catering to customers all over the world.
  • Consider we are having AWS environment in Europe and Asia and If we set this routing policy then users from Netherlands can route requests to Application customized for Dutch. If someone is coming from India then AWS will route request for application customized for India based users.

 

 

Filed under Amazon web services, Cloud

Amazon Web Services – Storage

March 19, 2018 Leave a comment

This mind map highlight various storage types and supported services in AWS

AWS_storage

 

Mind map for simple storage service(S3)

simple_storage_service (1)

 

Mind map for cloud front

Cloud_front

 

Mind map for block storage supported by AWS

Block_storage

 

Filed under Amazon web services, Cloud

Spring Boot, Spring Cloud Lectures

August 30, 2017 Leave a comment

  1. Spring Boot, Cloud Micro Services Introduction
    1. Monolithic Applications Advantages Drawbacks
    2. Reactive Application

Filed under JAVA Tagged with ,

Performance Tip :- Avoid Catching Exceptions

August 7, 2015 Leave a comment

Introduction

In this post we will look at simple example how does catching exception impact performance.

Code Sample

Code for catching exception

private static void exceptionTest(){
 int i=0;
 int j=1;
 try{
 int k=j/i;
 }catch(ArithmeticException ex){
 //not good idea to catch run time exception but catch for demo only
 }
 }

Code where conditions are handled

private static void withoutExceptionTest(){
 int i=0;
 int j=1;
 if(i>0){
 int k=j/i;
 }
 }

method to call logic

private static long exceptionTestLoop(int iterations,boolean isCatchException){
 long startTime=System.nanoTime();
 for(int i=0;i<iterations;i++){
 if(isCatchException){
 exceptionTest();
 }else{
 withoutExceptionTest();
 }
 }
 long endTime=System.nanoTime();
 long time=endTime-startTime;
 return time;
 }

main method

public static void main(String[] args) {
 int itr=1000000;
 long timeForCatching=exceptionTestLoop(itr,true);
 long time=exceptionTestLoop(itr,false);
 System.out.println("Time for catching Exception "+timeForCatching+" without catching "+time);
 }

Results

exception_catch

Conclusion

Avoid catching exception as it will reduce response time. above example demonstrate results for simple single threaded application but situation become worst in multi threaded environment.

Filed under Application Performance, JAVA Tagged with , ,

← Older posts

%d bloggers like this: