Before dabbling into backend development (through this book), my thought was that a database server and an application server were two different things. An application server would host the rest apis and application logic and would communicate with a database (sql) server. As a front end developer (iOS) this was my basic understanding.
In Chapter 32 Deploying with Heroku and 36-37 Microservices.
It seems like we deploy application(s) with a database and restful api to various cloud computing platforms.
It seems like in modern cloud computing (PaaS, IaaS, etc…) has made it so we don’t need to worry about scaling or maintaining servers.
It was stated (microservices chapter) that a microservice should be self contained (with database, rest api, etc).
Assuming our Swift applications are not stateless, would we always couple the restfull apis and databases?
I’m still a little lost when looking at these various cloud platforms, when trying to figure out which of these services supports a state-full Vapor application.
For example lets say I want to use Google Cloud & Docker would I need to use Google Kubernetes Engine?
Managed environment for running containerized apps
It seems like it may be the only Google Cloud option that supports containers and databases but again I’m having trouble conceptually understanding the cloud deployment process/architecture.
There’s a lot to unpack here to be able to answer the question
So to start, let’s define what a server is. Usually a server is a headless machine that runs one or more applications. In the olden days, you would have a single server that ran your application, a web server, your database etc all on one machine (think a traditional LAMP stack). However as web services began to get ever more popular, and you reached how far you could scale with a single machine, applications began to scale horizontally. Services like AWS really helped in this regard because it became very cheap to spin up 100 new servers just for a few days whilst you had a sale on etc.
So modern set ups have their data layers (database and/or file storage like S3) decoupled from the logic layer (the application code). There are a number of reasons for this but it allows them to scale/operate/be maintained separately. Generally apps like Vapor apps don’t need a lot of memory but databases need a ton of memory. If you have a database team, they can manage the database whilst you focus on the application. These days, you can offload the database to someone like AWS who take care of backups and maintenance. (Scaling is still a bit of an issues depending on the DB. Managed services for MongoDB, DynamoDB and Cassandra scale transparently. If you’re running a more traditional DB like Postgres you still have to decide how powerful the server should be and set up scaling rules, mainly because splitting databases is hard, but that’s a whole other topic).
Microservices are another evolution of this philosophy, where splitting up the application into composable services allow them to be scaled individually and worked on individually. But yes, each micro service should have it’s own database that’s separate to other micro services. How you deploy these is a different question. But they must be separate otherwise you end up having to coordinate releases and worry about treading on each others’ toes and you end up with a distributed monolith which is the worst of both worlds.
So back to the question. In general, like everything in depends. But the best option is to deploy your application to somewhere (and GKE via Docker is a good scalable solution) and then use a database service from the same cloud provider. In your case you’d use Cloud SQL. That make sense?
When using a database service for example Amazon’s S3 vs Amazon’s EBS (gp2) as done in Chapter 34 - Deploying with AWS we won’t be able to use Fluent correct?
Since those services (S3) are accessed through a web API.
So would it be correct to say that we can only use Fluent with certain types of database like Amazon’s EBS databases whereas a Database service will be accessed through the internet by our Vapor application.
These databases have different properties and choosing which one to use would depend on the use case (as you said, like everything it depends).
EBS will be faster but there is a limit on storage.
Where S3 can scale without a limit but is accessed through a web api (No Fluent).
So S3 is a file storage system. EBS is essentially a hard disk for your server. They’re file storage instead of a traditional database to be clear. EBS is great for local stuff, but can only be accessed by the machine that’s connected to the disk. So if doing file uploads and you’re scaled to more than one instance file uploads to go to one of the servers and not be accessible to other servers, which is why a centrally accessible system like S3 makes sense, because all instances of the app can access it. Make sense?
To be clear, you cannot use Fluent with EBS (Elastic Block Service). Are you thinking of RDS (Relational Database Service)? That does work with Fluent but is very different to S3 and EBS
So EBS is required for an EC2 instance because it’s effectively the hard drive for that machine. So it holds the operating system, the Swift toolchain, your app code and binary etc. If you were running in ECS with Fargate (which is a server less Docker hosting service) you wouldn’t need to configure any storage
