DEV Community: pugkung

Team Topologies

pugkung — Mon, 22 Jan 2024 18:46:12 +0000

I have been trying to look for an optimal way to ensure that my working team is efficiently and which area could be improved or moving toward to. The book "Team Topologies" was being mentioned by my ex-boss and it caught my interest.

This post will be about a short summary of the book contents

Sections

Team Sizing
Type of Team Structures
Type of Team Interactions
TLDR;
Closing

Team Size

Generally team size should be around 5-8 members to avoid communication overload between members.

Large teams or divisions may break down into sub-teams which can still share their skillset and expertise between teams.

Each team could be divided (and should be aligned with each other) by

Business Area
Regulatory
Physical Location
Technical Dependency
Change Velocity

Team Structures

Team are generally identified into 4 categories:

Type	Role
Steam-Aligned	Common team tied to certain product or business
Complicated Subsystem	Specialist in certain field Maintain tightly coupled/legacy components
Platform	Offload underlying tasks for Stream-Aligned/Complicated Subsystem team Provide generic services to other team
Enabling	Support other teams to achieve their goals Discover and try to innovate how to improve workflow

Team Interactions

The interaction between team are generally put into 3 categories:

Collaboration
- Two (or more) teams are working closely in a given time frame for solving certain problems. All teams shared their ownership/responsibility together as whole.
X-as-a-Service
- A team expose a certain way to interact with other team. Similar to how we sent request to API endpoint which require well-defined schema as input. Most interaction are predictable.
Facilitating
- An experienced team act as a mentor to another team to get over obstacles or encourage team to do something (eg. logging standard/agile coach/CICD)

Mode	Pros	Cons	Example
Collaboration	Quick discovery	Exhausting	Platform↔Stream-Aligned Complicated Subsystem↔Stream-Aligned
X-as-a-Service	Well defined Lower cognitive load	Slow innovation Lower consumer insight	Platform↔Stream-Aligned Complicated Subsystem↔Stream-Aligned
Facilitating	Improve deliverable velocity/quality Further identify improvements	Required experience from facilitating team	Enabling↔Stream-Aligned

The interaction mode are not meant to remain as-is forever. Teams will eventually change how to work together over time. For example:

Collaborating teams established an communication agreement between teams (X-as-a-Service)
Enabling team moved to facilitate another team

TLDR;

In summary, this book is meant for managers who are thriving to setup optimal team structure for software development which should be considered by team's type and how they should be interact each other

Four fundamental teams
- Stream-Aligned: general team tied to product/service
- Complicated subsystem: similar to steam-aligned, but maintain more complicated or legacy components
- Platform: provide shared services for other teams
- Enabling: expertise, but not tying to specific business area
Three interaction modes
- Collaborating: initial state of discovery
- X-as-a-service: goal for stable teams
- Facilitating: to enforce or encourage something

Closing

In the end, Team Topologies meant to be an optimal "template" for team management. It explains the "most likely" efficient team format that we should be, or moving to when we are growing into a hugh organization in a rational way.

Wether how much it could be carry out is depend on the constraints and how team member willing to open-up with the changes. These stuff may not be directly mention on the book, but it is all about communication and transparency of leadership people. The more trust we have, the less friction would be regardless of hardship (i believe...)

For more detail, you can visit the author's website (https://teamtopologies.com/) and you could also get their copy of book which will contain more examples and further reading references.

I am currently reading another book that the author published "Remote Team Interactions Workbook" and I would make another post about what I have learnt from it.

Modify and Test AWS Lambda Function on the fly

pugkung — Mon, 22 Jan 2024 18:45:56 +0000

The Problem...

AWS Lambda provide a convenience way to quickly edit and testing code on the web console so you don't have to modify you code on you IDE then deploy it onto the AWS.

Sometime, your lambda could grow very big (due to dependency libs) and AWS will not allow you to edit it on the console anymore...

There are several ways to modify the code in this situations:

Solutions

1: Deploy Package (Traditional)
2: Dirty Install
3: AWS Cloud9
4: AWS Toolkit

Deploy Package (Traditional)

This is the supposedly to be the correct way to publish new version on to AWS Lambda as same as how you are going to deploy the code via CICD pipeline or whatever...

What you have to do is pack you entire source code into a zip file (at root level) and upload it onto Lambda or S3 Bucket.

When the code is uploaded it will automatically deployed as new version of the Lambda function and you can run test against it.

Pros	Cons
✅ No surprise	❌ Slow zip + upload

Dirty Install

From the previous solution, we would want to avoid packing and upload the code onto Lambda from time to time. We will be keep minimal code under the Lambda function so we could still editing it on the console directly.

What we are going to do is to download the required dependencies before each function call to ensure the runtime environment can see and use them.

The code block below is an example code stub for installing request library via pip before executing the code. Put it on the top of the Function code.

import os
import sys
import subprocess

subprocess.call('pip install requests -t /tmp/ --no-cache-dir'.split(),
    stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
sys.path.insert(1, '/tmp/')
import requests

# implement whatever your code after this block

Pros	Cons
✅ Not taking space in Lambda Function	❌ Introduce network cost/latency on every function call

AWS Cloud9

AWS provided a ~~Product~~ Solution for software development on AWS itself. Cloud9 is an IDE running on website (under AWS Console). The IDE instance can be access by multiple developers and update the same code at the same time like how we did on Google Office apps. The IDE also have built in Terminal to run on the virtual environment.

As the Cloud9 is based on the EC2 service, you could configure the Cloud9 instance to sit under the network that you need to integrate you application with.

Also noted that Cloud9 service itself is free, but EC2 that use to host it doesn't. The larger instance (cpu/memory) to compile/execute code will cost you more money.

Cloud9 may introduce new feature as the time you are reading, you could reference it from the AWS Cloud9 info page https://aws.amazon.com/cloud9/

Pros	Cons
✅ No desktop installation required	❌ Incurring EC2 Cost
✅ Can share codebase + environment with multiple collaborator at the same time
✅ Run under actual VPC, no additional configuration needed

AWS Toolkit

AWS Provide a plugin for JetBrains IntelliJ and PyCharm to manage access key/region connection between AWS and the IDE, so you can run the application against the AWS network directly

For installation steps, refer to the guide provided by AWS here:
https://docs.aws.amazon.com/toolkit-for-jetbrains/latest/userguide/setup-toolkit.html

This is actually automation for executing AWS CLI over IAM and STS service which you can also do it manually and could also be use with other IDE or code editor as well.

Pros	Cons
✅ Test your code against actual VPC	❌ Need to reconfigure every time token is rotated
✅ Edit + Debug your code on IntelliJ / PyCharm

Closing

There are several workarounds for editing large Lambda code. One may fit the need for the given constraints or frequency of code changes required.

I hope this guide may give you an idea how to work around with AWS Lambda, so we can focus on productivity rather than frustrating over trivial things 🤪