In today's world, simply being able to develop a web application is not enough. An important aspect is the setup of deployment tools, monitoring, as well as managing and administering the environment in which it operates. The era of manual deployment is fading into oblivion; even for small projects, automation tools can bring significant benefits. When deploying 'by hand', we often forget to transfer something, to consider certain nuances, or to run a forgotten test; this list can go on for quite a while.
This article may help those who are just beginning to grasp the basics of creating web applications and want to understand the key terms and conventions a bit better.
So, building applications can be divided into two parts: everything related to the application's code and everything related to the environment in which this code runs. The application code can also be divided into server-side (which runs on the server, often involving business logic, authorization, data storage, etc.) and client-side (which runs on the user's machine, often interface-related and associated logic).
Let's begin, perhaps, with the environment.
The foundation for any code, system, or software is the operating system, so below we will look at the most popular systems available in the hosting market and provide a brief overview of them:
Windows Server – the very same Windows, but in its server variation. Some functionality available in the client (regular) version of Windows is not present here, for example, certain services for collecting statistics and similar software; however, there is a set of utilities for network administration and basic software for deployment (web, ftp, ...). Overall, Windows Server looks like regular Windows and behaves like it, but it costs twice as much as its regular counterpart. However, considering that you will likely be deploying your application on a dedicated/virtual server, the final cost for you may increase, but not critically. Since the Windows platform occupies a dominant place in the user OS market, its server edition will be the most familiar to most users. servers (web, ftp, …). Overall, Windows Server resembles a typical Windows system, behaves like an ordinary Windows, but is twice as expensive as its regular counterpart. However, considering that you will most likely deploy your application on a dedicated/virtual server, the final cost for you may increase, but it won’t be critical. Since the Windows platform holds a dominant position in the market for user operating systems, its server edition will be the most familiar to most users.
Unix-like system. Traditional operations in these systems do not imply the presence of a familiar graphical interface, providing the user with only a console as a control element. For inexperienced users, working in such a format can be challenging, as evidenced by the exit from a fairly popular text editor. Vim, the question associated with this has already accumulated over 1.8 million views in 6 years. The main distributions (editions) of this family are: Debian — a popular distribution, where the package versions are primarily oriented towards LTS (Long Term Support - long-term support), which is reflected in a fairly high reliability and stability of the system and packages; Ubuntu - contains distributions of all packages in their latest versions, which may affect stability, but allows for the use of features provided with new releases; Red Hat Enterprise Linux – an OS, positioned for commercial use, is paid, but includes support from software vendors, some proprietary packages and driver packages; CentOS – an open-source variation of Red Hat Enterprise Linux, is distinguished by the absence of proprietary packages and support.
For those who are just beginning to explore this area, my recommendation would be systems Windows Server, or Ubuntu. When considering Windows, it is primarily the familiarity of the system, Ubuntu - more tolerance to updates, and consequently, for instance, fewer problems when launching projects on technologies that require newer versions.
So, having determined the OS, let's move on to the set of tools that allow deploying (installing), updating and monitoring the state of the application or its parts on the server.
The next important decision will be – hosting your application and the server for it. Currently, there are three most common ways:
- Hosting (keeping) the server on your own — the most budget-friendly option, but you will need to order a static IP from the provider so that your resource does not change its address over time.
- Renting a Dedicated Server (VDS) – and managing its administration and load scaling yourself.
- Paying for a subscription to a cloud hosting service (often allowing a free trial of the platform's features) where the pay-as-you-go model is quite common. The most notable examples in this area are: Amazon AWS (offers a free year of service, but with a monthly limit), Google Cloud (provides $300 credit that can be spent over a year on cloud services), hostingYandex.Cloud (offers 4000 rubles for 2 months), Microsoft Azure (provides free access to popular services for a year, plus 12,500 rubles for any services during one month). Thus, you can try any of these providers without spending a penny while getting a sense of the quality and level of service provided.
Depending on the path chosen, the only thing that will change is who largely bears the responsibility for a certain area of administration. If you are self-hosting, you should understand that any outages related to electricity, internet, the server itself, or the software running on it—all of this falls entirely on your shoulders. However, for learning and testing purposes, this is more than sufficient.
If you don't have an extra machine capable of serving as a server, then you may want to opt for the second or third path. The second case is identical to the first, except that you transfer the responsibility for server availability and its resources onto the hosting provider. Server and software administration are still under your control.
Finally, there is the option of renting resources from cloud providers. Here, you can configure automated management of virtually anything without delving too deeply into technical nuances. Additionally, instead of a single machine, you can have several instances running in parallel that may, for example, handle different parts of an application, while not differing significantly in cost from owning a dedicated server. Moreover, here you have access to orchestration, containerization, automated deployment, continuous integration tools, and much more! Some of these features will be discussed below.
In general, server infrastructure looks as follows: we have what is called an "orchestrator" ("orchestration" is the process of managing multiple server instances), which manages changes in the environment of a server instance, a virtualization container (optional but frequently used) that allows applications to be divided into isolated logical layers, and Continuous Integration software that enables the updating of deployed code through scripts.
So, orchestration allows you to see the statuses of servers, perform "rolling updates" or "rollback" of server environment updates, and much more. Initially, this aspect is unlikely to concern you, as to orchestrate something, you need multiple servers (you can also have one, but what's the point?), and to have multiple servers, there must be a demand for them. Among the tools in this area, Kubernetes is primarily in the spotlight, developed Google.
The next step is virtualization at the OS level. Currently, the concept of "containerization" has become widespread, which originated from the tool Docker, providing functionality for isolated containers that run within a single operating system. What this means is that in each of these containers, you can run an application or even a set of applications that believe they are the only ones in the entire OS, completely unaware of anyone else existing on that machine. This feature is highly useful for running identical applications of different versions or simply conflicting applications, as well as for separating app components into layers. This snapshot of layers can subsequently be written into an image, which can be used, for example, to deploy an application. In other words, by installing this image and deploying the containers it contains, you get a ready environment for running your application! At first, you can use this tool for either exploratory purposes or to gain real benefits by distributing the application logic across different layers. However, it's worth mentioning that containerization is not always necessary or suitable for everyone. Containerization is justified in cases where the application is
fragmented,microservices architecture.) Continuous Integration. Travis CI The main tools currently available in this area are Jenkins (CI software written in Java, which may seem somewhat complex at first), (written in Ruby, subjectively somewhat easier than Jenkins,however, it still requires some knowledge in deployment setup), Gitlab CI (written in Ruby and Go.).
Now that we have discussed the environment in which your application will operate, it's finally time to look at the tools available in today's world for creating these applications.
Let's start with the basics: Backend (backend) – the server side. The choice of language, basic functions set, and predefined framework structure here is primarily determined by personal preferences, but it is worth mentioning for consideration (the author's opinion about languages is quite subjective, although it aims for an unbiased description):
- Python is a user-friendly language for inexperienced users, forgiving certain mistakes but can also be strict with developers to prevent serious errors. It is a mature and purposeful programming language that emerged in 1991.
- Go is a language from Google, also quite friendly and convenient, making it easy to compile and produce an executable file on any platform. It can be simple and enjoyable, but also complex and serious. It is fresh and young, having appeared relatively recently in 2009.
- Rust is slightly older than its previous colleague, having been released in 2006, and is still quite young compared to its counterparts. It is aimed at more experienced developers, although it still tries to solve many low-level tasks for the programmer.
- Java is a veteran of commercial development, first appearing in 1995, and is one of the most commonly used languages for developing enterprise applications today. Its foundational concepts and complex runtime environment setup can be quite challenging for beginners.
- ASP.net is a development platform released by Microsoft. The C# language (pronounced C-sharp), which emerged in 2000, is primarily used to write functionality. In terms of complexity, it is comparable to a level between Java and Rust.
- PHP was initially used for HTML preprocessing, and while it currently maintains absolute leadership in the programming language market, there is a noticeable trend of declining usage. It features a low entry barrier and simplicity in coding, but when developing larger applications, the language's functionality may prove insufficient.
And the final part of our application – the most tangible for the user – Frontend (frontend) – is the face of your application; it is this part that users interact with directly.
Without going into details, modern front-end development relies on three pillars, frameworks (and some not), for creating user interfaces. Accordingly, the three most popular are:
- ReactJS – not a framework, but a library. It differs from the proud title of a framework only by the absence of certain features "out of the box" and the need to install them manually. Thus, there are several variations of how to 'prepare' this library, forming unique frameworks. It may be a bit challenging for beginners due to some basic principles and a rather aggressive build environment setup. However, for a quick start, you can use the 'create-react-app' package.
- VueJS – a framework for building user interfaces. Among this trio, it rightly claims the title of the most user-friendly framework, with a lower entry threshold for development compared to its mentioned counterparts. Moreover, it is the youngest among them.
- Angular – considered the most complex of the frameworks mentioned, it is the only one that requires the presence of TypeScript (a superset of the JavaScript language). It is often used for building large corporate applications.
In summary, it can be concluded that deploying an application now differs radically from how this process used to occur. However, no one prevents carrying out 'deploys' the old-fashioned way. But is the slightly saved time at the start worth the vast number of pitfalls a developer choosing this path is about to encounter? I believe the answer is 'no'. Spending a bit more time familiarizing yourself with these tools (and that's all that's needed, as you must understand whether you need them for your current project or not), you can win back that time significantly by reducing, for example, the instances of phantom errors dependent on the environment and appearing only on the production server, overnight investigations into what caused the server crash, why it won't restart, and much more.
Source: habr.com
