In our world of mobile gadgets focused on applications, it is no longer customary to talk about sites. Classic web sites serve mainly for informational purposes, and business needs web applications to work with the target audience.
And then the question inevitably arises about where these web applications can work as reliably, quickly and cost-effectively as possible. The choice of possible solutions is quite large and we will consider the advantages and disadvantages of some of them below. But still, looking ahead, we can say with confidence that cloud solutions are currently the most optimal.
As mentioned above, you can run a web application on different platforms. You can use the company's own servers, you can use Shared Hosting providers, you can purchase VPS/VDS web hosting, for instance, from DigitalOcean, or you can use cloud infrastructure from Internet giants - Amazon Web Services (AWS), Google Cloud, Microsoft Azure and so on to host your web application. There are also solutions specifically focused on web hosting web applications like Pantheon or WP Engine.
A lot of possible solutions cause a headache for a beginner. What to choose? What is cheaper? Which is more reliable? Where is the best technical support? Where are there more opportunities and where is the growth prospect better? Let's look at the pros and cons of each of the options.
Of course, complete freedom of action when using your own server is captivating. With sole use, you get full control of your server configuration, root access and the ability to independently ensure the highest level of system security. But you have to pay for such freedom, and the high cost of a dedicated server is the main drawback of that solution.
The need to pay for depreciation of equipment, server space and the work of highly qualified administrators negates all the undoubted advantages of such a solution for web hosting your web applications. In addition, you need to understand that high cost also means the costs of finding, hiring and managing highly qualified personnel, and, for instance, for equipment, you need to draw up and adhere to a strict replacement plan for components. This option is definitely not suitable for beginners, as it requires skilled work with many technical aspects. Sometimes it takes an entire team to work with a dedicated server. But there is an option to use collocation - to rent a server from your service provider's equipment in its datacenter and that can significantly reduce your costs.
If you decide to use Shared web Hosting, then on the contrary, everything is fine with the cost of the necessary costs. This is probably the cheapest solution. In addition, you often additionally receive free domain names. Your server is configured and generally does not require special technical knowledge to use. Everything is maintained and administered by the service provider's support service. But at the same time, you are extremely limited in adding and configuring additional features for your project.
Moreover, the performance and stability of your web application can be seriously affected due to sudden and significant traffic flows and consumption of server resources by neighboring web sites and web applications. And you can have several hundred such voracious neighbors! The promptness of technical support with such a large number of customers is most likely not to be expected. In addition, the issue of shared hosting security is acute, because if at least one of the web sites or web applications is hаcked by attackers, most likely they will be able to access the resources of other projects on that server. For these and other reasons, the shared web hosting market has been stagnating in recent years.
One of the most popular solutions. Many people are familiar with DigitalOcean with its popular offers. Virtual private servers are more expensive than Shared web Hosting, but for that price difference you get resources allocated only for you on the server, server neighbors do not affect the performance of your web application, configurability is very high because you have full root access to your system and thus have the full right to perform all without exception operations. It is convenient to vertically scale your VPS manually and with downtime. It is enough to stop the VPS, add resources and start it again. This won't work with a physical server.
But again, in addition to a fairly tangible price, high qualifications and serious technical knowledge of server management are required here. In fact, we need specialists of the same level as for managing physical servers, the only difference is that there are no problems with hardware (no need for a replacement plan, procurement, installation, etc.), but the infrastructure is the same. Therefore, highly qualified administrators are needed for VPS web hosting. To configure a working environment for your web application and maintain it, you will need a lot of time.
The hosting option is when a specific web application is launched for you, they give you administrative access to it, but the server is not directly managed by you. So you are limited only by your application. You can only manage what it allows you to do within its framework. And since there are a lot of people like you on a physical server, all the same problems that are characteristic of Shared web hosting arise - instability of the amount of actually available resources, slow response of technical support, and so on.
Let's stop here in more detail. The dynamics of the growing popularity of cloud solutions in recent years is impressive. The analytical company Gartner estimated the volume of the global public cloud services market at $242.7 billion by the end of 2019. In 2021, the global market for the introduction of cloud technologies will exceed a total of $306 billion, according to the same Gartner. Cloud-based solutions are chosen by companies and organizations regardless of their size. Everyone finds something of their own in them, but the general advantages of cloud solutions are obvious:
The resources consumed can scale almost instantly to your requirement depending on the change in loads. Even when using the company's own clouds based on an internal multi-server infrastructure, scalability is not achieved so easily, and the cost of its implementation in that case is very high.
Capital expenses are replaced by operating expenses, because instead of large advance payments for the purchase and installation of equipment and software, you make regular uniform payments for the access of your employees to the resources they need, and only upon their consumption.
Eliminates the need to purchase and install your own servers or rent servers from providers / datacenters for applications and information storage, which saves both office space and funds for the creation and maintenance of server rooms (air conditioning, access security, uninterrupted power supply, etc.)
There is no need for own staff of system administrators to maintain server equipment.
There is no longer a need to take care of regular updates of the systems used - the cloud provider does it for you and, as a rule, completely unnoticed by users.
But with all the advantages of cloud technologies, in the process of their introduction into the company's work, the problem of a high entry threshold invariably arises. It lies in the complexity of choosing a cloud architecture. For instance, it is not easy to choose an AWS stack suitable for your project, which would provide all the needs and its cost would not go beyond the budget.
In general, if we talk about AWS, then you can imagine it as a kind of constructor from which you can make a lot of different things - the main thing is to be able to do it. Hosting a web application using AWS is sometimes compared to assembling a computer (compared to buying a ready-made web hosting order from a provider): EC2 is a motherboard and memory.
It allows you to run instance based on an operating system image. EBS is like a disk. You can say: make me a 45 GB disk and connect it to such and such an instance (the created "disk" will be called volume). As a result, a new device appears in your system that you can mount, format and work with. Everything that was recorded on it is saved regardless of the life of the instance. S3 is like an external storage. You can save large files there and store them there forever. And there are also services for logging, monitoring, databases, DNS and many others.
How to assemble from that set of components exactly the "computer", or AWS stack, which will ensure the optimal operation of your application and at the same time not overpay? It is not clear to a novice in cloud technologies which specific AWS stack scheme to use, which services and components to choose, and how to connect them together. You can evaluate the complexity of the choice using that CNCF Cloud Native Landscape scheme.
Complicating the task of choosing is the fact that to use AWS Cost Forecast or a calculator for calculating expenses, specific knowledge and skills are required from the user. In addition, it is very difficult to create descriptions of processes, structures and necessary scripts. All that requires highly qualified specialists who are deeply versed in Amazon, Google or Microsoft cloud technologies.
In general, the main disadvantage of hosting in the clouds is that it is complicated.
If we consider the services of App-specific providers, which are designed primarily for developers, then well-known examples of such services are Google AppEngine, VMware Pivotal Cloud Foundry, Heroku, Pantheon and others. Such services represent sets of ready-made components for creating applications, as well as frameworks for managing the platform. In that case, the components will be database services, repositories, automated deployment tools, monitoring, testing environments, and similar services.
The level of entry into these services is lower than in the cloud, but nevertheless, to deploy your application web hosting on systems such as Heroku or Pantheon requires writing a special manifest, which is very difficult for beginners to develop and debug. The disadvantages resemble those of Managed web hosting - you only have what they give you. At the same time, something is often not completed, for instance, the desired specific version of the component. In addition, price plans are inconvenient - you either do not fit into the plan, or pay for more resources than your project consumes.
As a result, it often turns out that in the process of growth your application starts to cost too much, but since you have already adapted it for a specific PaaS, it is already difficult for you to switch to some other solution. But at the same time, App-specific providers do not have the problem of selecting and connecting many components, like AWS or other cloud providers.
We propose to significantly reduce that threshold of entry into cloud technologies for companies with the help of our new WSP product being developed. In fact, the entry threshold is reduced to the presence of only three necessary components:
Your application must be dockerizable, that is, be able to work in a docker container and be built through docker build.
Customization and differences from competitors
After deploying the application using WSP, you can subsequently customize it using your own terraform scripts, for instance, or other methods. At the same time, those customizations that are not managed from WSP will not be lost after subsequent deployments of new versions of the application. Another advantage of WSP over its main competitors, Pantheon and Heroku products, is that they require pre-writing a manifest for the application being deployed, which requires high qualifications and in-depth knowledge of the product.
At the same time, competitors' applications will work only on their own infrastructure, and in the case of WSP, applications work on Amazon's infrastructure and will continue to work on it even if they refuse to continue using WSP. As a disadvantage of WSP, you can name the need to pay separately for the use of WSP and AWS accounts, whereas in Pantheon and Heroku you pay only for their accounts.
Unlike scalability solutions offered by service providers, WSP provides the ability to use autoscaling, or, in other words, horizontal scalability. Autoscaling is easily configured depending on the needs of your application. Considering that you only pay for the resources actually used, autoscaling becomes a very profitable solution. If the load is reduced, excess server capacity is released, respectively, you pay less.
Autoscaling is beneficial in cases where the load on your application has a clearly pronounced peak character. For instance, online stores – buyers are massively connected to servers during sales or on holidays. Autoscaling will ensure stable operation of servers during peak hours and turn off unnecessary resources when the need for them disappears. The same can be attributed to news blogs with a pronounced peak load during periods of relevance of hot topics.
The screenshot below clearly shows how easy it can be configured:
Monitoring and logs
Setting up monitoring and logging systems is an extremely non-trivial task in AWS. In WSP, logging using ELK stack (Elasticsearch, Logstash, Kibana) and monitoring using Prometheus or Grafana are configured and connected extremely simply. That is, they are connected automatically to each application if the use of that functionality was selected when registering an AWS account with WSP. At the same time, you can always disable monitoring and logs, for instance, to save money. And vice versa, turn them on when they are needed.
Since monitoring and logging are deployed in an AWS account, they are included in the AWS price. Consequently, these functions do not disappear even if you have abandoned the use of WSP.
WSP performs a detailed breakdown of costs during the deployment of the application, which allows you to make an accurate forecast of the costs for cloud services used by your application. You can view that generated breakdown and the rest of the cost management data in AWS Cost Explorer. There you can see the costs by time periods (per day, per month, per year) and by services.
Technical domains with certificates
Now we are able to automate the creation of a zone and its delegation. Thus, if the user is satisfied that the technical domain for his application will be a subdomain of our domain, then he does not need to do anything - the subdomain is created (and works) in his Route53 automatically. If the user needs his own domain, then he can configure it, but then he is responsible for prescribing NS himself. Certificates for these technical domains are issued and assigned automatically. This completely eliminates the need to take care of registering, configuring and protecting your application domains.
Automatic database deployment in Amazon RDS
WSP can automatically deploy a PostgreSQL, MySQL, or MariaDB database instance to your Amazon RDS application. This is configured directly in the "Environment settings" of your application:
If, while working with your application, WSP deploys a new version of the application or rolls back to a previous version, the work session switches from the current to the new version of the application completely unnoticed by you. Implemented a full Zero Timeout for such cases.
One more thing!
Lift&Shift. Special attention in the development and concept of WSP is paid to the fact that you absolutely do not need to somehow adapt and redesign your application to work in the cloud. With the help of WSP, it will work without any additional effort to adapt it.
In WSP, access to your applications is restricted using Access Rules. You can add to them those networks and addresses from which access is possible. Access from all other networks and addresses will be closed.
WSP provides asynchronous operation. You can simultaneously initialize, build, and deploy applications. Everything will work at the same time. Even if you close the browser session, you will not interrupt the execution of already running tasks.
All components used in the product are standard. These components are a recognized global industry standard, have open source code and are free. No proprietary components are used. For instance, for pipeline in WSP, Tekton is used.
All secret data, such as passwords, usernames, etc. are encrypted.
Continuous Deployment (CD) is supported. That is, the platform can automatically build and deploy the application by commit in the GIT repository.
Currently, as a support for the concept of "Infrastructure as a code", WSP can read application parameters from special files from the git repository, that is, in addition to setting application parameters from the UI, it is possible to set parameters in a file.
Plans for further development
Currently, WSP only works with Amazon's cloud infrastructure. In the future, it is planned to expand that list with Google, Microsoft Azure and DigitalOcean cloud services. Support is also planned for those consumers who use Kubernetes-based infrastructure.
Another interesting way to develop WSP is to use ready-made docker images of applications directly from DockerHub.
As can be seen from the advantages listed above, the main value of the WSP project is the maximum simplification of the process of entering cloud technologies for those who want to join them. For a mobile developer, data analyst, devops, dokops, etc., it is enough just to formulate your need and you can try to implement it quite simply in the cloud using the rich capabilities of WSP.
Zero downtime is a big statement, I'm afraid not all applications are ready for that.
If you train on cats, it works. And real applications impose significant restrictions — in such a deployment scheme, as far as I understand, the old code must work correctly with the new data scheme.
At one time I was puzzled by creating a PWA for a web application. There were difficulties.
In the end, we created a mobile shell application through which we work with a web application.
After half a year, there are no problems, it works reliably.
There is a manifest file, there is a service worker file, but at the moment it is not registered, so there is no way to install it as an application. It looks like this feature is in the works.