Bi-Weekly Report #5 — Tatag Aziz Prawiro

The end of one thing is just the beginning of another

— Simone Elkeles, New York Times Bestselling Author

Time sure flies fast. Before you know it, it’s already the fifth bi-week of this PPL Course. I was hoping, or rather, expected that this is not the last bi-weekly report since the course plan initially stated that there are 6 bi-weekly reports, but policy changes and we as a student can only follow and probably throw a little bit of complaint that might or might not be heard (LOL). Anyway, enough idle talk, in this bi-weekly report I will mainly be talking about three topics. These topics are Software Architecture, People Management, and Penetration and Stress Testing.

Software Architecture

Software architecture is basically an architecture, or plan, of how software is built. There are many types and many ways to build a software architecture model, but still, every type and ways need to have these goals in mind when used. According to Garlan (2000) a software architecture:

1. To understand the system: what it will do and how it will do it
2. To determine how much of the system will reuse elements of previously built systems and how much of the system will be reusable in the future
3. To provide a blueprint for constructing the system
4. To reason about how the system might evolve
5. To analyze dependencies and select the most appropriate design, implementation, and testing techniques
6. To support management decisions and understand risks inherent in implementation and maintenance

While these points are very much needed for the development of good software, I do think that how these points are implemented depends on the team and the scale of the project itself.

In the case of AdHub, since it’s (currently) a small project, and the targeted product is an MVP, we do not use a very complicated or highly scalable architecture. We actually simply uses a monolithic structure using MVC (or in Django’s case, MTV) pattern. This diagram is the high-level view of our application:

AdHub Architecture

As you can see, AdHub doesn’t use an overly complex architecture. Even so, the functions and source code structure in AdHub is designed to be very modular, so even with such a simple architecture, it should be reasonably scalable.

As we all know, we use Docker to help us deploy our product online. In this architecture, Docker and GitLab CI/CD help us to automate the deployment of the database server and application server. In particular, we use docker-compose here to easily deploy the database server and web server in one command.

# docker-compose.yml
version: '3'

services:
  db:
    image: postgres
  web:
    build: .
    command: bash -c "python3 manage.py makemigrations && python3 manage.py migrate && python3 manage.py collectstatic --no-input && python3 manage.py runserver 0.0.0.0:8000"
    volumes:
      - .:/adhub
    ports:
      - "8000:8000"
    depends_on:
      - db

People Management

If you have been following my bi-weekly report since the beginning of this course, you should know that I am the Hustler of my team. With that position, comes a responsibility that mere Hackers does not get, that is, to manage the people of AdHub.

Internal Team Management

It’s a given that a team needs to have good chemistry, a good relationship in order to function optimally. In order to do achieve that, the Hustler needs to put an effort to keep the team together, even during low productivity phase (or in Indonesian slang, it’s called the demot phase). To do so, I, as a Hustler, always try to keep a good relationship with all the team member, and also keep everyone’s relationship with each other at a favorable position. Keeping only your relationship good with each other is not good enough for the team, you need to keep the team’s relationship with each other good too. Efforts that I did to do that includes,

1. Try to keep the chat groups lively and friendly.
2. Be a mediator when conflict arises.
3. Try to be moderate, not too inclined in a certain outlook.
4. Always try to see things with multiple perspectives.
5. Regularly play and chill together with the team.

A thing that I need to note here, the Hustler is not the leader. Rather than being a leader, a hustler is like the manager of the team. If I am going to make an analogy, Nick Fury is like the scrum master, and Hawkeye is like the hustler of The Avengers. So I can’t really “act” like a leader here since I don’t actually have any authority. I actually have an experience being the head of PASKIBRA during my high school times, but being a hustler is not exactly the same as being the head of an organization.

Relation with people outside of the team

The development of AdHub involves not only the team itself, but there are other people as well. The most obvious one is, of course, the product owner. Aside from the product owner, there are the scrum master and the supervising lecturer. We also need to maintain a good relationship with them as the team cannot function without proper support from external sources.

The scrum master is the closest of these external connections to the team. You can even count scrum master as inside the team actually because the scrum master observes the team productivity very closely every day. The scrum master also arranges scrum meetings, scrum planning, and sprint retrospective. And so, we can just maintain a good relationship with the scrum master just like we maintain a good relationship within the team. Sometimes I even play games together with the scrum master since we have a game in common.

With the product owner, we establish a WhatsApp group in order to communicate about the product. The product owner is an alumnus of Fasilkom UI and is actually really open and friendly, so it’s nice that we can discuss things without a strict restriction.

With the supervising lecturer, we always have feedback since there are bi-weekly individual reviews. We also do sprint reviews with the lecturer every two sprints, so the lecturer can know our team and our product’s status regularly. We don’t really establish a 24/7 communication medium like the case with the product owner and the scrum master though, because the lecturer is not only supervising us and it’s not their job to be our always-ready support.

More on Testing: Penetration and Stress Testing

In the past report, we talked about Mock Testing. Today we’re going to talk about two other kinds of testing, Penetration and Stress Testing.

Penetration Testing

Penetration testing is a test of security. When we do penetration testing, we test the security of our application by doing all kinds of “hacking” work. We try to find a security breach in our application by hacking our own application. Since we’re not actually a hacker, we could use some penetration testing tools on the web that are available. These testing tools provide basic but adequate penetration testing tools for our application. Tools that I use to penetrate AdHub is https://pentest-tools.com/. Here is the report for a penetration test by said tools:

As you can see, since the app was made quickly and as an MVP, there is a medium risk of security in AdHub. But since Django has built-in security, there are a number of green ticks in our penetration test that was automatically implemented by Django. Thanks, Django!

Stress Test

Stress Test is a test that evaluates the performance of our application. The test mostly evaluates by increasing traffic that goes to our application. This test will assess if our app can handle heavy traffic or not. This test is NOT USED to wreck our application, our to test Facebook level traffic to our application, no. This test is used to test the expected traffic of our application. Since AdHub is an MVP (currently), we should not test the website using Facebook-level traffic, millions of users are out of the scope of AdHub. I use Locust to stress test AdHub. Below are the steps that were done to test AdHub.

• Install locust

pip install locust

• Make locust_script.py script to run locust

• Run the script

locust -f locust_script.py --host=http://152.118.201.222:21203

• Open the web interface and run the expected swarm, in AdHub case, I think I will start with 1000 concurrent users.

• Here is the report of the test

As you can see, our server has a stable increase in response time with 1000 users and 20 hatch rate. When I try to manually access using my browser, the website responds for a very long time, probably more than 1 minute until the page response. I think this means that AdHub still has a very bad scaling system. But still, 1000 users and the website is not dead. Next, I will try to lower the bar a bit with 500 users and 10 hatch rate.

With 500 users, the response is faster, probably around 30 seconds, but still 500 concurrent users still arguably is a bit too much for AdHub. I will try to lower the bar again to 100 users and 30 hatch rate.

With a hundred concurrent users, the AdHub actually still performs very good. It has a really good response time of under 10~20 seconds and the page loads fast. Given that AdHub is an MVP product, this is pretty good, since the market itself still hasn’t been established yet.