Web applications allow users from around the world to consume a designed experience, but circumstances change. There may be flaws in the design as sure as there are costs associated with providing a seamless session to a growing customer base. To save costs, one can abandon a traditional server approach for a compute option that scales down when you don’t need it. Is it time to abandon the castle?
The Monolith
A monolithic application hosted on a single server isn’t all bad. It can be expensive to run if it’s deployed on a machine with high specs, but if the team is familiar with it, it’s a mechanism to get features into production.
Another advantage of a monolith is a benchmarked environment. Performance degradation can be noticed immediately and traced to queries, which can be resolved with built-in modern application framework interfaces.
The single server does have other risks than high cost though. Having a single point of failure without backup is undesirable as this constitutes an unreliable service for end users.
Autoscaling VM’s
One answer to single point of failure is having a backend pool of virtual machines that autoscale based on a metric such as CPU utilisation. An HTTP/HTTPS load balancer recieves traffic from the internet and redirects that traffic to the most available machine holding a copy of the application. This improves cost control as machines can be added or taken away depending on server load. It also removes single point of failure.
Migrating from single server to multi machine as discussed can be a problem if user session and cache data is not handled appropriately. The existing cache can be switched out for a dedicated cache initially and later a cluster or a managed service would be appropriate.
Likewise, the database needs to be abstracted out. For a traditional relational database, this means vertically scalable, also possibly imposing a single point of failure. A cloud managed service provides a high availability mode though and replication and backup can be managed. This architecture can be self-managed with a bit more effort.
Docker/Kubernetes
This is not a one size fits all solution. Not all developers are familiar with Docker and Kubernetes. This is the best option if you have a savy team and want a highly scalable, available and balanced cost option. The development environment is simplest with a Mac or Linux machine. Skaffold for development work is the way to go, as this tool helps supports developers by handling the container dev to deployment workflow.
The database and cache can simply form part of the cluster and can be best implemented through recipes (or charts) using a tool called Helm.
Managed Service
9/10 times this is the way to go if you’re trying to host a web application. Google App Engine is an example of a managed service that facilitates automated builds from version control, whatever local dev environment you want really and supports scalable cache and database. Costs are competitive and compute is scalable. This will give a traditional VM server a run for its money on the pocket and takes the admin out of the development process.
The limitation with this approach is the cache. You generally get locked in to specific technologies you currently don’t dev with. The way forward here is to migrate the cache.
My Choice
I’d stick to the monolith if there’s no need to shift out. The next priority is separating the cache out from the main VM to get more control over memory utilisation. Next I’d go with either the scaling VM pool or managed service option, depending on what managed service technology I’d be prompted to use. Lastly, Kubernetes would be the way to go if I had a correctly skilled team and a busy application. Kubernetes can be overkill. Sometimes it’s better to keep it simple.