DEV Community: Husyn

What's in it for me?

Husyn — Thu, 23 Feb 2023 10:09:38 +0000

Why people join meet-ups, tech communities & guilds? Why invest their personal time and attend or speak in events for free? Even conduct tech workshops where they have to make sure attendees do the learning by doing and grow.

This is a big undertaking and not an easy one! In community events no-one gets paid it's all by the people for the people. I'm involved in organising AWS User Group Dubai Meetups and doing it "consistently" for past many months. But why?!

For me, there are 2 simple reasons

1 - At every stage of my career, someone was there to show me how to do it right. I was a mobile application developer and from there transformed my career into cloud. Number of people helped me achieve this goal. It's a debt, time to pass it on!

2 - When everyone is growing then the overall culture of growth and right mindset kicks in. Have to create a snowball effect where right discussions happen, skills are valued and people thrive.

To achieve this, I'm going to conduct a workshop on "Serverless Architecture for Beginners" @ Murdoch University Dubai on 10th of November 2022. And I will continuously organise events where everyone at every level of their career can participate and have an impact.``

How to be an Architect?

Husyn — Thu, 07 Jul 2022 09:56:06 +0000

The one question which I asked a lot while being a developer half of my career. And is a common question I receive working as full time Solutions Architect. I rarely got 2 similar answers to the question. But it is somewhat agreed understanding that Architects in a technical team are very senior people who should know everything. This is not a complete truth and nor a lie. What architects are supposed to do (I believe) still varies from organisation to organisation.

Types and Kinds of Architects

In my career I worked in 3 countries and many organisations. And the very definition of "Architect" is not same everywhere. Sometimes architects are extremely technical, they can code features and infra, create diagrams and present very complex solutions to non-technical stakeholders, manage budgets, have SLAs and KPIs, experiment and maintain the technical roadmap, understand security, cloud, business domain, integrations, architecture, development methodology, team dynamics and much more. These kind of architects are Angels to know and work with. A software engineer might grind under them but true growth is exceptional.

Another kind; enterprise and sometimes solution architects are quite theoretical. They know certain tech lingo and create high level diagrams and can discuss integrations. But their core competency is system understanding and business domain. They naturally grow from Business Analysts stream rather than Software Engineering. In large organisations, such architects are the glue for communication and standardisation. Both of which are always a challenge in enterprises. These architects seldom code and are "technical" of different type. Perspective is key here; someone from deep software development background might not comprehend their importance. But there're a lot and good reasons why the role exists.

Technical or non-technical is a separate debate on it's own. And which specific skills to have depends. In this article I'll share the ideas which applies to all kinds of architects and some other overlapping roles.

First Principles & Decision Making

The core skill for this role I believe is critical thinking and decision making. For any problem statement different roles in software engineering domain will have different solutions based on their perspectives. An Architect is the one which should understand all such perspectives and take decision based on first principles.

The decision making is a short expression but require a number of capabilities to do it right. It's a balancing act between below mentioned (sometimes conflicting) ideas:

technology best practices and business value
biases and preferences
planning, designing and delivery
short term vs long term architecture
tech debts vs perfect code base and practices
many more...

To be good in decision making, one should have a number of non-technical soft skills. These soft skills help architects sell their story to the wider audience. In many scenarios, everyone agreeing to the story (architecture / solutioning) is much better than partial support towards the end goal.

Soft Skills

In SOFTware Engineering I believe soft skills makes the most sense (for architects specially, sometimes more than technical knowledge). Humans create software for humans. So without soft skills, technical knowledge alone seldom works. The failure rate of software products is full of skills. Article by Forbes discusses 14 points, none of them is about tech!

Business vs tech

Every engineer at some point in her career thinks that optimised, documented, test-covered, and formatted code is the best code. That's how the source code should be. The truth is, only code which matters is the one that creates some business value. The more senior people you see in tech, the more business they understand & support. Without business, tech in it self is worth nothing (or puny).

Every architect should understand this idea and practice it equally well. It doesn't mean technology is not important or it's impact is not valued. Balancing the both is the key!

Biases & preferences

Software world is always changing, so much so that no two products are built the same way. Given this, everyone has some kind of preferences and biases. These biases are due to our past experiences. We like to repeat what we have already done. It reduces the learning time and potential risks.

Bias is not only gender or the ones common in AI/ML space. There are LOT of Biases in software engineering. [1] and (https://github.com/charlax/engineering-management#biases) 2 discusses these and you'll be amazed how much of these are common around us. It's just that we don't know they exists until we know. An architect should know these and identify, point & rectify them when required.

Writing

If you're the perfect shooter or can lift 1000kg but never told anyone then you're just wasting the talent. It's the same if you never contribute anything back. Anyone who has to stay relevant has to read! I don't believe there's any exception to this rule. Same like medical profession where doctors have to read medical journals to keep them updated with latest advancements. Software professionals have to read about new architectures, programming paradigms, development methodologies, etc.

Defining & Naming

This is a hidden talent which I observed some of the great architects have. They name practices and architectures when they develop or *discover something. They productionise the tool which creates an entity in the universe which others can refer to and further build upon. Naming software have an impact on it's stakeholders. If something has a name then it comes to life with health, behaviour, lifecycle, and other such attributes.

Some other aspects like versioning, maintaining lifecycle of APIs, nomenclature of artifacts, etc. are traits of this same competence.

*We discover best practices and patterns from iterative refinements

Architects to Follow

Given a list of skills an architect must have, there must be some role models to follow. Whatever I know today majority of the credit goes to these architects, leaders and great writers who shared their thoughts and experiences. Sharing the list for the readers:

Martin Fowler. He's so great that few times I shared his idea and people were sceptical. When I mentioned that Mr. Fowler suggests this, everyone instantly agreed with it. His video on YouTube are amazing and his website is absolutely amazing for anyone to learn software architecture (and beyond)
Mark Richards. I attended two trainings from him and he knows the solutions of problems which we didn't knew we'll face in future given our tech stack and team dynamics. His YouTube channel is full of remarkable discussions.
Gregor Hohpe is someone I feel touch the philosophical aspects of Architecture and Engineering. His articles under AWS blogs are worth reading over and over again.
Some other greats I love to read are Sam Newman and Neal Ford

Cloud Architect

Cloud Architects are new beings and they demand special mention here. The special part about this role is the breadth of knowledge and skills required. We read that cloud democratise IT; it means cloud architects has to be well versed in

Infrastructure (networking, compute, storage, etc.)
Application architecture (architecture patterns like microservices, event driven systems, queues, design patterns, etc.)
Enterprise architecture (large scale integrations, costing, maintenance, tech debts, etc.)
Security, automation, management, etc., etc.

Any "good" cloud architect can't be good in one area and be ignorant in other. They have to be a full package for the organisation. In terms of real-life example, AWS architects have a proper T shaped skillset. Yes there are specialised SAs, but even they understand basics of other domains like every specialised medical doctor have to go through MBBS.

So you might be an architect planning to explore cloud. Or in your early career thinking someday you'll be an architect. Be open to this idea that Architects come in all shapes and sizes. And that depends on the opportunities they get in the career & projects they work on. The variable which one can control is what they love to do, and there's a high chance that some kind of Software Architect exists which does that! Keep designing, keep learning, everyone is an architect; depending on the scale.

Cloud usage maturity levels

Husyn — Wed, 25 May 2022 04:27:41 +0000

From morning till night we interact with infinite things and all of them have a unit of measurement. Temperature, weight, our cars fuel tank, etc. All such units help us understand the level quantity and/or quality of something. We have to measure the level of expertise and complexity as well which is done well in higher education area. Whenever we read level 101 it is apparent that content is introductory in nature. And when something is level 400s then it is expert level. This doesn't look like a world changing idea but it has a great deal of importance. Form Fredonia University pages I found below definitions of course numberings. I'll also share the relevant Cloud trainings or courses in alignment with these levels.

Level 100 - Introductory

Introductory courses where no pre-requisite is required. Definitions and basic knowledge is offered without application or analysis.

Training sessions are focused on providing an overview of Cloud services and features, with the assumption that attendees are new to the topic. Building blocks (Cloud Services) are introduced and their purpose is expected rather than their workings or usage.

Level 200 - Intermediate

Often have level 100 as pre-requisites and now the knowledge acquired should be at a level where it can be applied.

It is assumed that basic understanding of services are there. Sessions are focused on implementation of services and how to combine them in a project.

Level 300 - Advanced

These courses teach the complex ideas in application and analysis of ideas. It is expected that anyone at this level can independently develop using what they have learned and improve it.

At this level specific area of interest is targeted like DevOps, AI, Microservices, Networking, etc. Now the topics are not generic in nature and industry best practices are discussed. Ideas like optimisations are continuous improvement live at this stage.

Level 400 - Expert

These courses are not public in nature and are under wisdom umbrella rather than knowledge. Only knowing is not enough at this level and critical thinking is essential to compare and contrast ideas.

Trainings or discussions are for attendees who are deeply familiar with the topic, have implemented a solution on their own already, and are comfortable with how the technology works across multiple services, architectures, and implementations.

AWS Specifics

AWS in their certifications and trainings (both classroom and on-line) categorise the content in two levels. It doesn't maps with the generic course levels but does a good job at dividing the expertise level into multiple areas. The two main levels are Fundamental and Advanced.

Fundamental Level

A developer who is new to AWS or at the fundamental level have experience in developing, testing, deploying and debugging AWS applications. A job at this level include:

Development

Write code suited for AWS environment
Basic Cloud Native development

Deployment

Build and manage deployment artifacts on AWS
Use AWS continuous integration and continuous delivery (CI/CD) services for automation

Security

Implement authentication and/or authorization for applications and AWS services
Implement encryption using AWS services

Maintenance and Operations

Implement observability using AWS Services
Optimize applications using AWS services and features

Advanced Level

At this level few years of AWS usage is recommended. All the knowledge in fundamental should be there and developers should have experience and expertise in designing and developing highly available, fault-tolerant, secure, and scalable applications on AWS. Designing a system from requirements is a must at this level. A job at this level include:

Planning and Design

Required to understand designing a system given constraints like availability, cost, technology stack, etc.
Determine design patterns to meet organizational or project requirements
Select best suited AWS services to support design and non-functional requirements

Development & Deployment

Select best suited tech stack with industry best practices
Understand re-usability and modular design
Design and manage deployment artifacts lifecycle
Implement high cohesive and low coupled applications

Testing

Develop automated unit, load, and integration tests
Come up with scalability and multi-region requirements based on continuous testing
Analyse results from automated tests and improve the system

Security

Implement security for users and applications alike
Implement security for data and integrations
Define and implement run sheets for attacks and security breaches

Observability and Monitoring

Instrument application code
Implement processes like incident management
Debug application code issues
Troubleshoot application code, data and integration issues

Organisational Use

Every organisation have to develop some kind of policies / rules around the competency of their employees. This competency decides career paths, promotions and compensations. How awesome it would be that every organisation clearly document this and make this public to (at least) all the employees, then a lot of debate and waste can be eliminated. Alas, our world is not perfect!

However I love that AWS has this sorted out in their certifications. Level 100 is the practitioner certificate. Level 200 can be mapped to associate level certificates. 300 or 400 level to Professional ones and Speciality ones. There's still lot of wisdom which can't be tested or exhibit by any certification. That could be level 500s which is specialised and reserved for PhD level studies. Large Enterprises have complexities which require skillset at this 500 level. That's one of the reason that still a lot of businesses are not 100% cloud native or taking a slow route towards it.

Update

Similar to Cloud maturity model, Dario Goldfarb from AWS shared a Security Maturity Model. It is nice to have these basic knoledge documented and available for everyone to guage where are they in terms of security.

Cloud is not for us

Husyn — Mon, 18 Apr 2022 07:22:07 +0000

For some Cloud is an apparent truth. For others it is unknown territory which is yet to be matured or explored by them. We as humans are always afraid of unknowns and when the change impacts hundreds or thousands of people where majority of them are not exposed to the destination then it really is scary.

This post by computerworld from 2014 discusses about fear attached to cloud computing. Concerns like transparency, absolute dependency, hidden metrics about compute processes and costing. Here's another one post from 2015 talking about five fears about Cloud. The post shares valid points like Data Security, Accessibility, Cost, Losing Control and Migrating back in case of failure.

But even in recent times the perception has not changed. It has improved but still many organisations fear this latest technology paradigm. A blog by Atlassian written in 2021 discusses issues like security, visibility and decentralized access, subscription costs, right tooling and controlled workflows.

I have seen many other issues like

Scarcity of experts
Dependency on 3rd party AWS partners, vendors or AWS support
Democratization of decisions
Time

Out of the issues above, time is the most critical one. Quite a number of times, large organisations (through their employees) become comfortable in what they know. They don't want to go extra mile and explore new areas of advancements. In such organisations, Cloud is always an after thought. Some IT leader in management thinks that world is moving to cloud and we also should. And that's how many organisations start their cloud journey. Soon realizing that cloud is not mature enough, can't manage their load, is too costly, etc., etc. The issue here is the mind set changes rather than technical.

Time is also critical in a way that the migrations and post-migrations improvements should be completed in months. Rarely that's the case. Large organisations approach this like: Cloud Discovery, Cost/Feasibility/Other Analysis, Business Use-cases, Solutions Intents, Business buy-in presentations, budget approvals, security approvals, etc. All this luggage of past era is what cloud is NOT suitable for.

Cost is another very scary part of cloud computing. Especially in third world countries which are late majority or laggards Ref on terms. The issue here is that of approach and learning from the industry. You don't have to start every project on EC2 & after maintaining it for x years realize that it should be serverless. The team has to be made up of passionate people who like to explore, join meetups, read blogs, etc. They'll be the ones who will be coming up with ideas eventually bringing the cost down.

The final fear according to me is how to manage the cloud. This is a genuine issue and should be really given deep thoughts. To start with cloud is really simple but to master it is the real challenge. It's the same as playing Flappy Bird game. It is super easy to start & even a 1 year old can play it. You just have to tap the screen to play. But to master it, yeah that's a totally different level of complexity.

Cloud is somewhat similar. Everyone can create an account and you'll find thousands of blogs and videos on how to do something on EC2 instance. Well Cloud is much more than EC2s, with AWS having more than 200 services (at the time of writing this post). A better approach is how to use the building blocks and make them work together to solve a product problem. This is much harder then it seems. Managers prefers AWS Marketplace solutions or AWS Partners to manage the cloud for them.

I've also seen Cloud Ops team which kills the whole cloud idea. You have to raise a ticket which has SLA of 7 days. Then an EC2 is created and passed to OS team to harden it. Then Security team examines it, then network team sets the paths and budget approval and 4 levels or approvals and then the question is why are you even moving to cloud?? Stay in the good old data-centre with 3 months lead time on a VM.

There could other considerations in your organisations as per the local context. But all of us at this point should consider that cloud is not something in future, in fact it is a living truth. So maybe update our perspective and look at the positive reasoning of why so many world level organisations have moved to cloud. There must be a good reason that they followed that path. Still if cloud is not the solution, then maybe you're the few niche organisations for which Cloud has to update itself.

How to learn AWS Cloud?

Husyn — Thu, 14 Apr 2022 07:05:27 +0000

If I have to tell you the name or details of companies like Netflix, Twitch, LinkedIn, BBC, Sony, Adobe or Twitter and many more then this post is not for you. The cloud computing is a myth and we're better of with Abacus. If not, then all of these companies and thousands others use Cloud for their computing needs.

It is not esoteric that Cloud is the power house behind agile teams and great products. It is the only logical way of creating a digital business in this age according to me. So if cloud is so much important then everyone should learn it. And if many people wants to learn it then it should be pretty straight forward. But on the contrary it is very confusing for beginners to pick up cloud (services). There are 175 Services in Amazon Web Services (AWS) alone as of January 2021.

So the intricate problem is that "cloud is important and everyone should learn it but it is huge and knowledge is scattered." To have a solution to this problem I came up with a list of my own about how to learn Cloud or specifically AWS Cloud.

Documentation

The most obvious place to learn any technical product or service is the official documentation. Documentation is amazing if it is written for specific specific use-cases or the topic in hand is not like ocean. AWS Documentation is huge on the other hand. It is so huge that each service has few thousand pages of its own. And since there are over 175 services, you can figure out how much documentation there should be. AWS Documentation covers everything from pricing, FAQs, APIs, Architecture, Best Practices, Integrations, Limits, Updates, Security concerns, implementation examples, templates, etc. It is great if you want to know about a specific section of a service but if you're a beginner then reading documentation is not going to help you. Read on for better alternatives.

Presentations, Workshops and Trainings

AWS invests a lot on promoting itself. There are thousands of workshops and trainings by AWS employees throughout the year in almost every part of the world. Other than AWS itself, there are User Groups which are managed by non-profit local communities. This is a great place to understand the basics and start with the cloud space. You can check the online AWS workshops and AWS Trainings if you're a beginner or if you want to learn about a specific services. It is also a great way to learn about AWS Certification.

Courses

Other than workshops or presentations, you can buy courses on the topic of AWS and related technologies. My personal favourite is A Cloud Guru which is a subscription based platform to learn lot of cool technical technologies. If you don't want to pay for a subscription then search for one-off course on Udemy and you'll find great stuff there. It is also a good way for beginners to start their cloud journey.

Podcasts, Meetups, Twitch, YouTube and Blogs

Now some tips / suggestions if you're not absolute beginner. All the above techniques will help you learn the technology but will not help you in managing it or operationalize it. If you want to manage teams, products or have to use cloud in an enterprise level then below suggestions are for you.

To know what are the latest trends in cloud you can listen to Podcasts. Two amazing free podcasts are AWS Public Sector Podcast and Tech Chat. Both of these podcasts cover different topics and industry trends.

Other than Podcasts, AWS YouTube Channel is also amazing. You'll learn how others architect their systems, solutions of problems by users, interviews and much more. For more technical knowledge checkout AWS Twitch and for content in multiple languages DevAxConnect twitch channel.

If you anything else where we can learn AWS then please comment on the YouTube video.

Understanding Cloud Knowledge

Do checkout my YouTube video linked below in which I share how much cloud you should know and how much you have to work for it. I've tried to follow the HOTS (Higher Order Thinking Skills) to explain how to tame the Cloud Dragon.

YouTube Video

I also happen to make a video on the topic in case if anyone wants to hear all of my love for AWS! If you've made it so far then here's the slides I used in the video for you.

Is Cloud Expensive?

Husyn — Wed, 13 Apr 2022 09:03:01 +0000

The Cloud (Computing) is one of the latest trends in Software industry. Well yes it's not so latest as AWS was launched in mid 2000s and since then has become a monster of its own. There was a famous iPhone commercial There's an app for that. And now we can say that for any use-case there's a "Service for that!" AWS is the Cloud services provider which has the majority market cap in this space. Still it is small compared with the whole software industry.

There are millions of applications of every kind which are not using any Cloud services. Specially in developing and under developed countries the hesitation to adopt cloud is because of it's cost. These markets being so cost sensitive don't consider the total cost of ownership concept, heavily marketed by cloud vendors of all types. I've tried to remove this misconception and came up with 10 reasons of my own on why cloud is cheap.

Utility Pricing

Same like we have billing for our house utilities, cloud services are charged on usage. If you don't use any services then don't have to pay anything.

Free Tier

When we sign-up for a new AWS account, it comes with lot of free stuff. Some of these free tier services are for 12 months and some others are forever free (again based on usage). Get the details of all such services here.

Student Program / AWS Education

If you're student then access AWS (limited) services for free via AWS Educate program. One must have active ".edu" email address. I received $100+ in credits when I was a student and learned a lot with those.

Startup Program / AWS Activate

AWS specially love startups, not only they might be next Netflix app but it's all free promotion and adoption of AWS. A startup can get up to $100,000 in AWS credits. More details here.

Reserve Instances

If the application is compute intensive or just require stable EC2 instances then Reserving instances for 1 or 3 years is a good idea to save some bucks. It is up to 72% cheaper then on-demand (utility) price.

Savings Plan

Savings plan is similar to Reserved Instances where the purchase is not based on server per year but $ per hour.

Spot Instances

The magic behind the AWS on-demand capacity is Redundancy! But it also means that resource utilization is not optimal most of the time. This extra capacity is available to the consumers via SPOT Instances.

AWS Lightsail

Not every application is using Microservices Architecture. In fact majority of the web is working on PHP language and 35% is just WordPress. To setup such server should not take few clicks and few minutes. That's what LightSail does! It has lot of templates to create servers with a fixed pricing model. LightSail is perfect entry point to the cloud for lot of users.

Economy of Scale

This point applies for someone who is thinking long-term. As your cloud usage grows, the cost doesn't spikes up linearly. It goes down actually. The higher the AWS bill, the more discount you'll get.

Commitment Free

This is my favorite point and consideration with the cloud. There are just no commitments at all and anyone can mix and match any services with any provider. One can stop any service and not have to worry about the bills from that point onwards.

YouTube Video

I also happen to make a video on the topic in case if anyone wants to hear all of my love for AWS! If you've made it so far then here's the slides I used in the video for you.