- In the context of developping a microservice architecture for a graduate course,
- facing the need for securing such architecture in real life
- we decided for not covering this topic in the course
- and neglected introducing distributed security concerns theory/labs,
- to achieve depth of knowledge in how to design/implement microservices,
- accepting that security is a topic on its own which deserves a dedicated grad course,
- because it is easy to "think" a system is secure when it's not, and we don't want to provide a false sense of security expertise as a learning outcome.
- In the context of deploying a message broker to support the TMT architecture,
- facing the need to chose between different deployment technologies
- we decided for RabbitMQ
- and neglected other options like Kafka,
- to achieve simpler ramp-up for students,
- accepting that RabbitMQ is more limited in terms of features and scalability capacity
- because heavier solution might not run on a student laptop easily
- In the context of deploying the system into its runtime environment,
- facing the need to chose between different deployment technologies
- we decided for using Docker Compose
- and neglected other options like Kubernetes,
- to achieve simpler ramp-up for students,
- accepting that docker compose is not really recommended for production environments
- because it is easier for students to only interact with Docker for both image building and deployment
- In the context of use case/user story u,
- facing concern c
- we decided for option o
- and neglected other options,
- to achieve system qualities/desired consequences,
- accepting downside d/undesired consequences,
- because additional rationale.