Cloud / on-premises

Here the system is running

On-premises is the so-called traditional way of running a system. In practice, this means your own server/servers, on which the necessary applications have been installed (e.g. a web server for REST API calls, a database for data storage, etc.).

Below is a kind of "evolution story" of how traditional servers have been moved to a cloud environment and what has happened in this process. The description is more logical than chronological. The example examines the process using AWS services as an example. The purpose of the description is to give an idea of ​​what kind of options there are in different situations, what it means, for example, from a maintenance and vendor lock perspective, etc.

As the amount of data increased and the power requirements for data processing increased, the importance of scaling servers increased. Cloud servers (ec2) came to solve this. Virtual servers (ec2) were run on "super computers". Users could scale virtual machines (ec2) in terms of number and performance as needed. Virtual machines eliminated the need for dedicated physical servers and their manual scaling and maintenance.

To store and process the growing amount of data from many computers at the same time, various "large disk systems" were created (e.g. Apache Hadoop HDFS, AWS S3, etc.).

The evolution of single disk systems also enabled the implementation of various scalable databases so that the same data on a large disk could be processed in parallel on several different computers (e.g. Apache Hadoop Hive, Sparx and HBase, which are so-called Big Data applications. The Phoenix SQL interface was also built on top of HBase, which converts NoSQL HBase into an SQL database). AWS has brought the Aurora relational database (SQL) to the category of data storage and scalability. Aurora scales as needed, both according to data and processing power from the user's perspective, without separate server management.

Single disk systems also offer the possibility of retrieving data directly from files. AWS has implemented the Athena application for searching S3 files and other data sources. Data can be searched in Athena using SQL. A similar implementation for your own servers or EC2 servers is Apache Drill, which you have to install and maintain yourself.

Traditional web architecture has long been Apache web server (EC2) and some scripting language used to connect to, for example, a database. These web servers could be scaled as needed so that several servers shared pages and/or REST API calls at the same time. The Apache server also handled user authentication.

Due to the cost of EC2 instances, AWS has developed more affordable so-called serverless solutions. In these, a "mini-server" is started and/or scaled quickly only when needed. In these serverless services (e.g. Lambda, Fargate). In practice, the scripts executed by Apache have been transferred to "mini-servers". Apache's http calls are received by CloudFront, LoadBalancer or API gateway, which are AWS services. The authentication previously performed by Apache has also been moved to AWS as part of AWS services.

From the developer's perspective, the traditional web server (EC2) implementation (apache / nginx + database) has been replaced by a "simple application implementation", which can be deployed to the cloud environment in a Fargate container (= docker) behind AWS's http call receiving interfaces. In this implementation, a simple web server is sufficient, which can serve dynamic and static pages quickly even over an unsecured connection (port 80). In this model, the constantly running services are the web implementation (e.g. node server side) on Fargate and the database.

Another option is to export the web application files to S3 and implement REST APIs with AWS's API Gateway. API Gateway in turn calls AWS's Lambda functions. In this model, the only constantly running service is the database. For example, Lambda functions that execute nodejs code are started from AWS actions only when they are called.

AWS also offers a so-called WAF, which can be thought of as a kind of web firewall. It is possible to configure various conditions in the WAF, based on which traffic is either allowed to the actual service or blocked completely. In the traditional model, these were also handled by Apache and/or Nginx modules.

If for some reason the system cannot be implemented on top of cloud services, many of the features of the cloud service can also be implemented in a slightly different way on your own servers. In this case, the installation and maintenance of servers and applications is your own responsibility.