How To Design Your System For A Web Application?

Let’s say you are building a typical web-application that consists of a frontend, a backend separated from the frontend by an API, and a database. As always, you can manage these things manually, but then you lose control, visibility, and testability. Manual changes can be documented, which might be enough in many cases, but in real world the documentation usually starts to get outdated immediately, and soon it just does not reflect reality.

That is why I encourage dev and ops people to document everything that they can as pictures and code. A picture makes it easy to quickly grasp whole system: see my other post on this matter. Then again when you document everything as code, you have evolving documentation that evolves along the the changing system. Sometimes code documentation might just be scripts which wrap more complex behavior into simpler interfaces. Sometimes we talk about documenting the build of the whole system “as code”.

Some of the benefits of documenting “as code” include: it reduces possibility for a human error, improves repeatability, and creates a shared baseline between different groups of people. You know, we all have heard the saying “but it works on my system…” It makes building complex system consistent and fast as there are many tools for automating builds and deployments: as systems get more complex all the time learning everything is not possible always either. Since automation is possible it enables also automating repeating stuff, and creates room for inspecting system by inspecting code, which is useful e.g. when talking about cyber security. Most known example of “as code” is Infrastructure as Code (IaC).

My system will be based on servers and not containers. IMHO, containers and container orchestration is not a solution for all problems. Also, I am not going cover cloud native alternatives as they require in depth knowledge of the specific problem you have in order to choose the correct cloud service as a solution. Next, I will discuss my approach on how to build and manage a basic web app. Let’s start by listing different layers.

1. Infrastructure meaning building networks, servers, etc. Including SSH key management. Infrastructure is almost always nowadays virtualized so for example getting a server from capacity means using creating it manually using GUI or CLI, or using some automation tool like Terraform. Networking is also one the key things handled in this layer…
2. Platform (backend) meaning application server and API, and other related services like caching, secrets vault, and distributed key-value storage. Another aspect of the platform is frontend. Platform (frontend) meaning how we deliver app and its’ content to users’ browsers. For example, React app that takes advantage of CDN. A separate aspect of the platform is database that is part of the backend but it could be a external managed service so it will be an independent part here – to some extent.
3. Application is the actual application we build separately and deliver separately. The data model of it must be in sync with the database! Application itself consists of frontend and backend: in this layer frontend usually provides GUI for end-users which uses services delivered from the backend.

Next, I will go through different tools which can be used in each case

1. Infrastructure: Terraform (or cloud development kit (CDK)) with CA based SSH key management: CA based one is really only known scalable model…
2. Backend Platform: Ansible with Ansible Vault for secrets. Frontent Platform: Netlify with CDN. Database: For general administration use any admin GUI, and for data migration I recommend using a tool that can version control and migrate your data: e.g. LiquiBase
3. Application: Whether the application is packaged as a native executable or a executable Java JAR, the management of it should be done using a deployer tool that does only this and nothing else – remotely

I also recommend using a command server where admins have software readily installed. Good thing is that you can turn this computer off when you don’t need it.

• Ansible (controller node)
• LiquiBase (versioning data)
• Application deployer (maintenance of the application)
• rclone (Access to the application packages)