yaseenkadir
commented
6 years ago I'm most familiar with AWS so I'll be using AWS terminology in the examples below.
Classic
The classic architecture. N-tier (but web and app are together). We'll have application servers running on EC2 instances which communicate with a relational database e.g. RDS.
Pros
- Standard way of doing this
- Pretty easy to scale this up using auto scaling groups
Cons
- Have to manage an OS
- Deployments take longer
- Deployment environment isn't same as dev environment
- Have to manage infra manually
Going this way we'd either bake AMIs that have the application preinstalled and run them automatically or store the application in S3 or something and download them on boot and run.
Classic/Docker
Same as above but instead of using AMIs or application zips or whatever, we pull in a docker image and start running.
Pros
- Deployment/dev environments are (basically) the same, easier for devs to get started
- Pretty standard way of doing things
Cons
- Deployments still aren't easy (though maybe AWS Fargate or ECS is actually pretty easy)
- Have to manage infra manually
PaaS
Using a PaaS where we upload the source/build files directly and have the cloud provider take control of infrastructure.
Pros
- Minimal deployment steps
- Minimal management of underlying infra
- Scaling is easier
Cons
- Lock in, can't easily move to another provider
(I'm also unfamiliar with Elastic Beanstalk)
Serverless
Going serverless. This definitely requires more investigation and would likely require a backend rewrite. But I've been using it at work and I'm really happy with how its been working out.
Pros
- No infrastructure required!
- Easy to deploy
- Scales easily
Cons
- Startup time is a huge issue
- Data layer doesn't scale as app scales due to max connections on RDS
(WIP)
Various choices can be made regarding the architecture of the chosen system. Below is a list of ideal features/requirements. These requirements are likely at odds with each other and we will likely only be able to achieve a few of them.
Developers must be able to easily test the app locally
As a developer I want to be able to click a run button e.g. in IntelliJ and run the app with minimal dev configuration. There MUST NOT be much more than that.
Not super expensive
As a Yaseen I don't want to spend thousands of dollars a year on a side project so that I still have money in the future.
Users can self host
As somebody who values privacy I want to be able to self host my own version of Etched Journal so that I can reduce the chances of an attacker gaining access to my private journals.
As I typed this I realised how important it is. If somebody else developed an encrypted journal there's no way I could trust it.
Deployment is automated
As an operator I want deployment to be automated so that I don't have to manually perform complicated and risky steps.
Deployment should basically be
./deploy.sh.Automated scaling
As an operator I want Etched Journal to automatically scale so that it can handle small to medium workloads e.g. 10s of requests per second.
Thousands of requests per second is out of scope. At that point we can revisit architecture.
As a buzzword enthusiast I want Etched Journal to scale so that I can say that Etched Journal is scalable, elastic, highly available, fully encrypted, blockchain (there are no blockchain features but buzzwords are cool)