Current Design

A reverse proxy sits in front of the backend services and it is the only service that is exposed to the public. The backend services are all in a private network. They can talk to each other and the reverse proxy but the public can only reach these services through the reverse proxy.

Components needed

• service discovery
  • enable loosely-coupled communication between containers (no need to know ip of the containers)
  • Kubernetes offer service discovery through DNS

TODO

• deploy multi-service "hello world" application with kubernetes - see wiki
• Test service discovery with kubernetes - see source code for FrontEndApplication in kubernetes-hello-world example
• document workflow deploying application using kubernetes - see wiki

implement blackbox tests for the User API

Da wir schon definiert wie die API aussehen soll, können wir mit der Implementierung anfangen.

Meine Vorschlag wäre erstmal eine "skeleton" / leere Methode schreiben, die noch kein Logik enthält aber Unit Tests ermöglicht.

Architecture design

The application targets to run in the cloud (AWS, Azure, GCP, IBM Cloud) with the ability to move between the cloud providers with no changes to the architecture and minimal changes to the application code itself.

Services

• Public-facing API service - accepts client requests from the internet and forwards to the responsible service
• User service - stores and handles information about the users
• AuthBearer service - sends out and verifies auth tokens
• File service - handles file storing, fetching, updating

Link to edit diagram

Public-facing API

• the only public-facing service

AuthBearer service

• accepts request from other service to authenticate a client and sends a token back
• tokens can be used with other services
• other services can verify token with AuthBearer service
• optional: handle third-party OAuth login ("social-login")

User service

• stores account info in DB
• UUID for each user

File service

• uses s3 for file storage
  • all user files stored in the same bucket
  • files stored using level 3 (name based) UUID
  • /<user-id>/<file-UUID>
• metadata in DB
  • UUID to filename mapping
  • bucket ID where the file is stored
  • tracks storage usage of each user
  • minimal metadata sent to user as XML
    • UUID not included
    • XML contains info for client UI to display/search/filter files (name, size, modified date)

DevOps

• use ansible Terraform for its multi-cloud support
• fabric8 maven plugin to deploy Java application to Kubernetes

imlement black box test cases for API Files

Da wir schon definiert wie die API aussehen soll, können wir mit der Implementierung anfangen.

Meine Vorschlag wäre erstmal eine "skeleton" / leere Methode schreiben, die noch kein Logik enthält aber Unit Tests ermöglicht.

@pokgak @DennisSentler @Asperator
Ich habe nach einpaar Services gesucht, die wir in unserer Architektur einbinden koennten.

Auth/User Komponenten:
Azure Active Directory B2C : https://azure.microsoft.com/de-de/services/active-directory-b2c/
Google Identity : https://cloud.google.com/identity/

Storage Komponenten:
Blob Storage : https://azure.microsoft.com/de-de/services/storage/blobs/
Google Cloud Storage : https://cloud.google.com/storage/

TODO

• how to run tests? - run tests as scripts called from .travis.yaml
• how to do continuous deployment to cloud (GCP, Azure)?
  • define separate jobs for testing and deployment
  • Deployment to a specific cloud can be done through
• workflow when using CI/CD? push to master? PR?
  • CI run when PR, CD run when new push to master
  • define stage in .travis.yaml with condition if: type = push and branch = master
• setup CI for testing PRs using hello-world application
• setup CD for deploying when new commits pushed to master using hello-world application