Internship Q4 2022 Retrospective

This was the first time we had multiple interns working on the same project during 3-month internship. We had 3 promising interns in varying stages of their education and the idea was for interns to learn as much as possible and to get hands-on experience with technologies that are in-demand, but aren’t taught in university. Things like deploying to AWS and integrating with many AWS services and Google services. On the other hand, interns were free to make decisions on some technologies like using Java SpringBoot on backend and React on frontend.

The project was to implement a social network web application similar to This problem domain was chosen because it is familiar to anyone and we saw use-cases for many different technologies we wanted to use (so a bit backward approach than what should be done on a real project which is to choose technologies based on requirements not the other way around).

First half of the internship was dedicated to learning these technologies:

  • Ionic framework with React for implementing PWA
  • Amazon Cognito - idP service for handling users (This also required implementation of AWS Lambda function to make nice confirmation URLs)
  • Amazon S3 - object storage for storing images (Interns had the opportunity to learn about S3 presigned URLs)
  • Amazon SES - email service for sending out notifications and remainders
  • Firebase - for sending in-app notifications
  • Google Maps integration
  • PostgreSQL with PostGIS extension
  • Docker Compose - for reproducible environments during local development
  • Playwright - for writing end-to-end tests

During this time, the project was a monolith application deployed using AWS Elastic Beanstalk and AWS Amplify with RDS for PostgreSQL. CI/CD pipeline consisted of GitHub repositories that would be automatically deployed using AWS CodePipeline and AWS CodeBuild services on each PR merge. Interns had an opportunity to do Code Reviews for each other. Project progress was tracked on Jira. DevOps work was done by the mentor of the internship, so interns could focus on feature development.

Second half of the internship was dedicated to learning advanced microservice concepts, so it involved a lot of learning and proof-of-concepts. Monolith application was split into 5 microservices:

  • User service
  • Event service
  • Group service
  • Notification service
  • Image service

Interns were given a choice how they are going to implement communication between services and they chose the event driven approach using message broker which is the most decoupled way of integration, but also the most complex. The technology that they had to familiarize themselves with was Kafka which was used as a message queue for communication between services. Also, Kafka Connect with Debezium connector was introduced for implementing Outbox pattern. Concepts that interns had to learn were:

  • Outbox pattern
  • Distributed transactions using Saga pattern
  • CQRS pattern
  • Materialized views
  • Resilience patterns using resilience4j library (Circuit breaker, Retry etc.)
  • Dead-letter queue
  • Zero-downtime deployment using Rolling update deployment strategy
  • Trunk-based development and feature toggling using LaunchDarkly

This time around, AWS infrastructure was created using Infrastructure-as-Code with Terraform. Instead of deploying to AWS Elastic Beanstalk, microservices were deployed to Kubernetes (Amazon EKS Cluster) using ArgoCD. CI/CD pipeline is presented in more detail on the following image:

CI CD pipeline for Internship project at Inviggo

In the end, the architecture of the system looked like the following image:

Software architecture for Internship project at Inviggo

This architecture was much more challenging to implement than simple monolithic architecture, but it had the advantage of high availability and scalability. Unlike the monolith application which ran entirely in AWS free-tier, this architecture was more expensive.

In conclusion, this was the first time we ran an internship with more than one intern and we were very satisfied with the results. However, there is a lot of room for improvement that we are going to implement for the next group of interns:

  • Start with microservices, IaC and GitOps from the beginning
  • Chose a better problem domain where some of the concepts we want to learn come more naturally
  • Better planning and tracking of progress with daily standups (we weren’t very strict about this) and other scrum rituals like sprint reviews with open invite to anyone in the company who wants to attend

Cover photo credit Isometric Vectors by Vecteezy.