📜 ⬆️ ⬇️

How we chose hosting



In this article we want to share how we chose hosting. We hope that our experience will help novice startups to avoid many problems and immediately focus on the product itself. Then we briefly describe the existing Workzilla servers and our costs for them.

It should be noted that all our technical specialists, for the most part, are pure software developers, rather than system administrators, and, accordingly, are less specialized in many things related to the creation and administration of server clusters.

First experience


When our service was still at the idea stage and we were making the first prototype of the Workzilla, we decided the hosting question very simply. The first version of Workzilla was hosted right in my home.
We did not have any users besides our friends, and there were no issues with the reliability of this solution. Naturally, before the first public release, it was necessary to choose something more serious. We came across a hosting company agava.ru , which met our price expectations, which was critical for us. In truth, we have given enough time to the choice of the provider and regretted it very much later.
Those support worked slowly, there were constant failures in work, including without warning (with enviable consistency only money required us). Upgrade iron needed to order in advance, a few days.
For the sake of justice, I note that it was a long time ago and I don’t presume to say that now things are the same there, but we have learned our lessons.
')
Later we decided to host all our servers in the Amazon EC2 cloud. Even despite the fact that they fell 2 days immediately after our migration to their platform, we continued to trust them and this was justified.

Why cloud?


I will cite several reasons, but far from all, why it is much more convenient to host in a cloud.

1. You can very quickly and easily create a new server. And you can create as an absolutely empty server, and clone the existing one with all the settings. It saved us a lot of time.

2. It is convenient to configure access to network ports for each server. In just a couple of clicks, you can restrict or allow access to any network port of a server or group of servers.

3. Disks can be transferred from server to server quickly and without unnecessary copying.

4. You can save an entire server or disk in just 3 clicks.

5. Transparent and clear centralized billing.

There are many more such reasons, but for us what I have listed has already been more than enough.

Why Amazon?




Here, price and many other available services along with EC2, an impressive speed in developing new services and improving existing ones played a decisive role. An important role was also played by the growing popularity of Cloud (this is important if you do not exclude the possibility of selling the company).

Workshop Servers


All our servers are in Ireland. Ping with Europe was expected to be better than with America or Asia. Servers in these regions are currently available.

All servers can be divided into several groups according to their purpose.

1. Auxiliary servers

The first server of this group is a VPN server, as well as a node for monitoring the entire system. We use Nagios and Munin. The t1.micro instance type costs only 15 usd per month. If interested, we can write a detailed article on how to customize it all.

The second server is our SVN repository. There we also host our workflow system and project management system (we will talk about this later). The t1.micro instance type costs only 15 usd per month.

2. Servers for development

At the moment, developers use only one server, which is much weaker than a live server and on which all components of a real system are installed. This is where all fitch and pre-release testing is done. Type of
Instance - m1.small for 85 usd per month.

3. Production

Web server. At the moment, we are using only 1 server connected via Amazonbalances loadbalancer to easily add capacity on days with heavy loads. Usually one server is more than enough if there are no serious promotions or we are not on the main page of habrahabr :)
Instance type c1.medium.

DB server. There is our database on MS SQL Server. The license is relatively expensive, but the built-in mechanisms of SQL Server take a lot of headaches to optimize SQL queries and other things.
Instance type m1.large.

File server All files uploaded by our users are stored here. Instance type m1.small.

In total, our monthly bill is only about 1000 usd, most of which is occupied by a license for using SQL Server.

Thus, these servers can handle up to 3,000 users online and 25,000 visits per day. Perhaps this is not so much, but Workzilla is not just an ad site and not an ordinary freelance in the form in which everyone is used to seeing it. Our business logic is quite complex. We try to provide the customer with always only the best candidates for his particular task (A review of the algorithms already used and those that we are only going to introduce, we will describe in the following articles).

Other AWS Services


We are currently working on building an automatic scaling system so that servers are added and removed automatically, depending on the system load. Amazon also allows you to do this quite simply.

In addition to EC2, we use many other Amazon services. They are all very well integrated with each other. In particular, we use S3 for storing database backups, SES for sending emails, cloudwatch for monitoring servers, etc. We will devote several separate articles to this.

In general, we advise you to work with popular clauses for hosting your solutions. Amazon in our case looked the most preferable.


PS


Our goal is to talk about our problems and their solutions to young teams working on their projects. We are pleased to hear the ritic (especially constructive). Wishes about the topics of the following articles - Wellcome.

Sample list of future non-technical articles:
- Search for first employees
- Run the first version
- Search for first users
- What difficulties have we encountered
- Remote team work

Sample list of future technical articles:
- Preparing for a mass advertising campaign with JMeter
- DR - how we solve the problem of force majeure.
- More about backups
- Service monitoring with Munin, Nagios, etc.
- The problem of choosing a reliable SMTP server

Source: https://habr.com/ru/post/174147/


All Articles