Abandoning The Castle
Web applications allow users from around the world to consume a designed experience. 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 one doesn’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 is noticed immediately and traced to queries, which are 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 receives 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 further removes the application compute single point of failure. If load balancing is a service and not a hardware device, an additional failure bottleneck is not introduced.
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.
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 support 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
4/5 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, a flexible developer set-up option and supporting scalable cache and database. Costs are competitive and compute is on-demand. This will give a traditional VM server a run for its money cost wise 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. My next priority is separating the cache out from the main VM to get more control over memory utilisation. Next I’d go with either ‘scalable VM pool’ or managed service, depending on what managed service technology I’d be prompted to use. Lastly, Kubernetes would be the way to go if I had an appropriately skilled team and a busy application. Kubernetes can be an overkill. Sometimes it’s better to keep it simple.