Introduction

This module is quite straightforward, but is tedious once the bugs come. You need to build a microservices architecture, most probably in Python (Flask). The only hard part is the architecture design. Once you get the flows out, coding everything should be simple. You will face quite some blockers when handling docker and trying to run docker-compose + setting up API Gateway so remember to start early.

You can view the project on Github or also view the project post Ninjatruck to have an idea of the application. This project won us top 3 in level for 2 awards - VMWare Tanzu + IIE.

Module Overview

IS213 is all developing microservices-based solutions. Each microservice is not complex. There will be message queueing involved, which is great especially since MQs are heavily used in real world architectures. You learn about tradeoffs between monoliths vs microservices, orchestration vs choreography and more.

This module took up about 10-20h per week. Most of the time spent was handling docker and docker compose, API Gateway integration, complex and simple microservice integration.

Component Breakdown

1. Class Participation - Lab and Quizzes (20%)
2. Project (40%)
3. Finals (40%)

Grade Breakdown

If you are aiming for A/A+, you will need to score well on all components. I scored well on all components.

If you are aiming for B+/A-, focus on project and finals, but you should also do CP because it’s free marks.

General Strategy

This module requires a mix of Memory Techniques and Deliberate Practice.

To score well, it just means starting early and finalising your scenarios early on the project. Don’t hesitate too long in choosing your project scenarios. Open Lucidchart, spend some time as a group sitting down together and brainstorming ideas and scenarios. Start from a good problem statement (if possible), and branch off solutions from there. You don’t need 20 microservies, but it should be somewhere between 7 - 14 at the minimum for a good-sized project.

Project Strategy

The project is decently heavy for groups that start late, because of the bugs you will face. The coding is just a copy and paste from class exercises. It is the integration of services, and learning of new technology that takes up the bulk of your time.

You should see the following in your projects:

1. 7 - 14 microservices
2. Using 1 message queue (Rabbit MQ)
3. Using another message queue (for extra marks, we used Kafka)
4. Use of API Gateway (Kong)
5. Use of Another API Gateway (Nginx) for extra marks (not sure if we did this, can’t rmb)
6. Containerisation with Docker and Docker Compose
7. Using one other language other than Python (pick your simplest microservice, develop it using nodejs or Java Springboot if you’re familiar. This is for extra marks.)

The key for the project is to start early and finalise on your scenarios early. Then you split the microservices amongst your group. You have about 5 group members, so each person should take 2-3 microservices and link up on their own.

A good group here is essential. A good group consists of people who take initiative to solve problems, are hard working and won’t shun away from difficult problems, and whom have good work ethic - starting work early, finishing components without delay, actively communicating and asking for help when needed.

Remember that the key here is not to start coding. I have seen many groups who dive into coding without planning the architecture, and end up having to re-write their code when their architecture changes. Instead, here are 2 things which will save you so much time:

Overview Documentation

This document will help you to consolidate everything into 1 location - endpoints, services, data schema etc. You can track everything from this document and it helps you to organise and plan.

In the 2 images below you can see that we laid out the basics of everything. It is very easy to visualize what tools are used, why they are used, what services are there, what the api endpoints are etc.

Additionally, you should have 1 tab for each microservice. You can see that you are able to visualize the different endpoints easily and understand their input and output.

It is also highly recommended that you use Postman for API testing. If you haven’t used this before, I strong suggest taking some time to learn it. I can assure you that many developers in the real world use this, and this is essential for API testing.

Last tip is that, your services should be developed independently. They should be able to be tested by each person using mock data (via Postman), and the results should be the same when you’re connecting all your services together.

Class Participation Strategy

Because CP comes from quizzes and labs, you should use Memory Techniques for Quizzes. For labs they are easy and can be completed before class ends.

Finals Strategy

Memory Techniques are the way to go for finals (as of 2023). Finals involve a lot of open ended questions. They look something like:

1. For Scenario xxx, what may be the advantage of invocation-based, synchronous communication over message-based, async communication.
2. What is the disadvantage of using Docker Containers (for a scenario)?
3. When to use Custom-off-the-shelf vs building your own? What are the tradeoffs?

There won’t be a lot of flashcards for this module, and it helps a lot if you have been doing the development for the project, beccause the questions that will come out can be answered with project experience.

During the project, when you are handling application design, you will have to make some tradeoffs between decisions. You will have to understand when to use async vs sync communication etc. You will then refer to your notes and try to formulate a solution.

This is a part of Memory Techniques as the harder a task, the stronger your memory. Hence when it comes to finals, you really don’t need to study much at all.

Conclusion

This module focuses a lot on development. I would say it’s the first “truly development” module you will take. You should definitely invest some time into this module, and invest more time for the API Gateway components and docker as those are new. Those skills will surely come in handy in the real world. There are so many interviews which have asked me about docker, docker compose, message queuing, api gateways. This is a good skill to have.

Happy building! :)