Tuesday, December 31, 2019

Review of 2019 & plans for 2020 as a software engineer

Let me state the disclaimer that this is not a technical post. Rather it's my own reflections of last year and plans about next year related to my technical life. I was doing this privately from the beginning of my career. This time thought of making it public

2019

Achievements


  • vlogging - The biggest achievement of the year was the start of vlogging. I started my first video tutorial with 'text to speech' instead of my voice. But later got the courage to publish in my own voice. 
  • Blogging - Also, mostly able to keep up one technical post per week.
  • Performance optimization - Refreshed application performance optimization skills. Learned new techniques. 
  • Power BI - I learned Power BI and created a dashboard for analyzing IIS logs. Power BI was postponed by me as it was not having much programming elements. Now I understood why everybody going behind Power BI.
  • Containers - Though I had blogged about container technology from the very beginning, I never got enough hands own experience. This year I got a good amount of hands-on time. To be frank, not able to get hold of Kubernetes yet.
  • Azure - Conscious efforts were put forward Azure during the year. Though not able to achieve the goal of passing the Az-300 exam, I prepared a lot for it. The immediate aim in 2020 would be to pass the same.
  • Public events - Similar to previous years attended public events mainly conducted by the Microsoft user groups.
  • Coding diagrams - The next big thing I learned and practiced was coding diagrams using PlantUML. Easy to deal with diagraming as an architect.
  • Interviews - I was nearly taking 3 interviews per week. Mostly Solutions Architects and cloud specialists. It again enforced my perception that to continue working as Solution Architect in US one doesn't need to be hands-on. But should be a salesperson with a basic / breadth understanding of concepts. There were cloud architects who kinds of started with cloud from its birthday (day 1) but never faced any cloud-specific challenge.
  • Enterprise Architecture - It is the year I was slowly getting converted from Solutions Architect to Enterprise Architect or at least had to deal with enterprise architecture. More time I am spending on Enterprise concerns such as protocols, OS versions, HA & DR, AD, AAD, wire sharking than designing solutions. Though I did some solution designs, those were more towards non-functional such as security & infrastructure-related than application functionalities.

2020 - What is ahead?

  • Focus on cloud computing, containers & Kubernetes.
  • The big thing would be an attempt to present a topic in a public event conducted by Microsoft user groups.
  • Pass the AZ-300 certification.
  • Linux - mainly for the container world. At least change home machine to Linux
  • Taste the feel of real micro-services and serverless in at least one application.
  • Learn more and more enterprise practices. Including infrastructure concerns to understand how to run production systems than just building those.
  • Continue making 1 blog post per week.
  • At least 25% posts to be videos.
  • At least 10% posts to external sites such as CodeProject, DZone CSharpCorner, etc..
  • Monthly 1-2 hours to personal projects
  • Some experiments with IoT boards.

What I am not going to do

It is important to decide what to avoid in this world of drastic changes and fancy technologies
  • Blockchain coding - Oh this thing is getting postponed 3rd year.
  • WebAssembly - Maybe watching some videos. Not in deep.
  • Go, Scala & Python - Same as web assembly.

Updates

2020-01-03

Removed work-related references - There is a policy in my current organization that "employees MUST not identify himself or herself as an employee of the company in a blog or on a social networking site". Though I was not using the company name in this post, people were able to identify. Thus removing the work-related references from this post.

Tuesday, December 17, 2019

Azure @ Enterprise - Truth about Cosmos DB SLA

Azure Cosmos DB is getting really high hype similar to how Service Fabric was getting some years ago. It is advertised as the defacto standard for data storage. The main reason people think it will solve all their problems is because of its SLA. I don't think Microsoft is advertising it as the one storage solution for all. They still recommend other storage solutions based on requirements. But somehow the industry thinks Cosmos DB as the ultimate one. Especially managers who stopped hands-on years ago but follows tech news and blogs :)

What is the problem with SLA? Since Microsoft has to reimburse on failure, it is bound to lot of conditions. It's not only Microsoft, even if we are providing a service with SLA, we will also have some sort of conditions associated with it. Below are the conditions for Cosmos DB latency SLA.

As is says the application should be in the same local Azure region. It cannot be a mobile application connecting to Cosmos DB directly through the internet or the application running on-premise.
Next, is the accelerated networking enabled. Accelerated networking is free but available in some VM tiers. Not sure what is the case with containers and App services.
Then comes the protocol. It cannot be the HTTP(s) which has its own overheads.

The below links explain the same.

https://azure.microsoft.com/en-au/support/legal/sla/cosmos-db/v1_3/ - Updated May 2019
https://azure.microsoft.com/en-us/blog/azure-documentdb-service-level-agreements/

Happy Architecting.

Tuesday, December 10, 2019

Networking for developers - Mind map of tools and commands

This can be considered as the second part of a previous post on Networking for .Net Web Developers. The textual version of tools and commands is not that intuitive to use. Here we have a mindmap of networking concepts, tools, and commands for debugging basic networking related issues.

Click on the image to see the SVG version of the same. SVG supports clicking hyperlinks.

An interesting thing here is that this diagram is also created using PlantUML and kept in GitHub. URL below.

https://github.com/mind-maps/software/blob/master/debugging/windows-network-debugging.puml
Feel free to issue a PR, in case of suggestions and additions.

How to set up an environment for editing PlantUML can be found here.

Tuesday, December 3, 2019

Linux Container not allowing to install packages - Selenium network debugging

It started with someone who needed to containerize Selenium. There is standard help available on how to do this. But less when something goes wrong. One such scenario is the network connectivity. In our enterprise environment, connectivity is a mystery and it played a villain role here too.

Selenium providing the debug version of the container image. We tried that to include the ping utility as ping is not part of the standard Ubuntu package.

Below is the Dockerfile we tried to install network utilities into the Selenium image


FROM selenium/standalone-chrome-debug:3.141.59-xenon
RUN apt-get update && apt-get install -y iputils-ping
RUN apt-get install dnsutils
EXPOSE 4444
EXPOSE 5900

Didn't worked. It was complaining about the permission to install. We never used any user name and password while doing anything in this exercise. So confused on how to give permissions. Also, we are mainly a Windows shop. Fewer experts in Linux.

Finally, google helped as usual. We switched to root by using the USER keyword in Dockerfile and get the utilities installed.

FROM selenium/standalone-chrome-debug:3.141.59-xenon
USER root
RUN apt-get update && apt-get install -y iputils-ping
RUN apt-get install dnsutils
EXPOSE 4444
EXPOSE 5900

The beauty of containers is that only one person has to struggle. The Selenium image with network utilities can be obtained from the below location.

https://hub.docker.com/r/joymon/selenium-standalone-chrome-debug-network

For a person from the Linux world working with containers for long, this may not be big news:)

References

https://github.com/WASdev/ci.docker/issues/194
https://github.com/SeleniumHQ/docker-selenium/issues/725