keepsimple
dark
en | ru

#9. Fundamentals of project technical components

I think it would be wrong, having told you so much about the management of IT projects, not to touch on their technical component.

In this article, we will go through the main general technical concepts, which the modern manager should know.

The purpose of this article is quite simple. I want you to be aware of what concepts exist and to have a general understanding of what they mean. This information should be enough to start with. Later on, as time goes by, you will understand exactly what areas you need to improve your knowledge.

To the question "Why is it important for a manager to know the technical aspect of IT projects if it doesn't really imp on his/her work?" I answer: "Because it's impossible to be a high-quality IT project manager if you don't know what concepts and tools your teams operate with, and how your projects are technically arranged." What would you rather be: a captain on a ship who gives banal orders based on some boilerplate theory, until something goes wrong, or a captain who knows all the details of the ship and can identify a problem, understand the scale of the problem and choose the best solution?

Ooh, this is getting serious now, I started using metaphors ☺))))

Since what we are going to discuss below is potentially a huge article – you could write pages and pages about each topic – I'll restrain myself and stick to the very minimum. No more than what you will need to know as a person taking his first steps in learning the art of management. So I recommend that you use this information just to understand the essence of each topic and google all the details. Technologies are developing at an incredible speed, and new variations of concepts related to each of the themes set out below are created every day. Amen.

Server

A server is a program, the key function of which is to process client requests.

For example, you used a browser to open this page. In this case, your browser is a client, and the program, located at www.keepsimple.io, which processes your request and opens this page, is the Web Server. The Web prefix (www), in this case, is used because the servers are different. For example, if you use the Spotify application installed on your PC to listen to music, then the program that you launch via a shortcut on the desktop is a client that connects to the Spotify media server each time, allowing you to search and listen to music. Or, for example, when you insert your bank card into an ATM and input your pin-code, the program that runs on an ATM is a client that sends a request to an authorization server to verify the correctness of the entered pin-code, and so on.

In the development of web applications, web servers are primarily used, and all the code that developers write, testers test, and clients examine is located on web servers.

Since the server is a program, it must be installed on some operating system. The operating system, in turn, is installed on the computer (which, sometimes – although strictly speaking, this is an exaggeration – is called a Server).

Hosting

Hosting is a service representing a specific space on the Internet for our server.

Theoretically, we could install and configure the server directly on our laptop. However, in that case, the server would only be available when our laptop is turned on and connected to the Internet, which is obviously extremely risky for any public project.

That is why we use hosting for the server's needs. There are hundreds and thousands of different hosting providers. Each of them has its own package of options, but the key parameters of the server are:

  • The size of RAM;
  • CPU type and number of cores;
  • Type (HDD/SSD) and volume of the disk;
  • The volume of network traffic;

And many others.

I will not go into a description of the server parameters. Still, I will simply say that ultimately the server is a physical computer with a certain computing power that can be leased in whole or in part.

Staging Servers

I have decided to introduce the topic of staging or intermediate servers separately because they are an essential component in the development of any project. So a manager needs to know about them.

The fact is, if we want to develop a project competently, then one server will not be enough. The server that will eventually be open to the general public on the day the project is launched is called the Production server, or Prod for short. It usually covers those segments of the project (increments), which are not only completed in terms of development, but also approved by the Client. But don't forget that, before approval, we must also hold a demo, and before Demo, the testers must conduct their tests...

It is to ensure that different project participants do not interfere with each other on the same server, that the idea of having intermediate servers was invented.

The idea is quite simple: to create several levels of servers that will take increments on the way to the Prod. Each server is usually taken from the same hosting provider to minimize technical differences.

Spoiler:

This picture shows the optimal configuration for a medium-sized project.

Each rectangle is a server.

Red is the development environment server (Dev. Server, or simply Dev). On this server, the developers are always changing something, and there will always be something not working properly on it.

Pale Yellow is a QA server for testing purposes. Increments are developed on Dev, which is a constant hive of activity, and then they are transferred to Sprint. And so here, on the QA server, are those increments that were marked by developers as "completed" and "ready for testing" (do you remember the columns "In Progress" and "Testing" on our Kanban board?). And having a separate server means that the testers can conduct their tests in the security of knowing that these servers are isolated from the chaos and instability that can occur on Dev. Server.

The golden rectangle is the UAT environment. UAT spells User Acceptance Testing. Usually, after the developers get the go-ahead from the testers, the software, in the form in which it is located on the QA-server, goes to the UAT, where the Client can see the results of the team's work and give them their approval. The Demo is also conducted on a UAT server.

Light green: UAT-2. The main difference is that whereas the UAT-1, QA and Dev servers can have low technical characteristics (it makes no sense to rent a high-powered server capable of withstanding tens of millions of users when your development team consists of a couple of dozen people), UAT-2 is a server that, in respect of its technical parameters, is comparable to a Production server. This enables us to conduct on UAT-2 those tests that cannot be performed on the other servers (for example, stress-test loading).

That's it, folks.

Unfortunately, only the most severe and disciplined companies adhere to this approach, while the majority make do with 2-3 servers maximum (Dev -> Staging (for QA and Client) -> Prod).

Database

An integral component of any project. Basically, the Database is a kind of virtual (usually) data table. For example, when you go to facebook.com and enter your username and password, the system checks the accuracy of the data you entered against the data listed in one of the tables in the Facebook database. Or, when you register on a website, the data you entered during registration create new entries in the Database of this website so that later you can be verified, and so on.

Testing, Monitoring and Analytics Systems

Before a project goes public, the development team usually performs many tasks and installs a range of monitoring and analytics systems, and only after making sure that everything is ready, opens the project for everyone.

For example, if our project has a potential market of 50 million users, and we expect at least 10 million to visit us in the first week, we'll conduct a stress test of the server, with load simulation, using specialized online services (locust, loader.io, etc.) to ensure that our servers will be able to cope with this load. If the test fails, we simply go to our hosting provider, buy additional capacity, and conduct the tests again.

If we want to analyze how easy it is for the user to open the pages of our site, we can configure additional productivity analysis systems (sitespeed.io, pagespeed insights, monitis, new relic, Zabbix, etc.). If, as a result of the analysis, we found that some components of our system are too slow, then probably we'll ask the developers to review the codes of those components and find ways to optimize them.

There are also separate tools for analyzing database performance, such as percona.

If we want to conduct special monitoring of some specific activity that we need for some particular purposes, then there are also some tools for this (Graylog, Kibana, Logstash, etc.).

So, we conducted stress tests, set up performance analysis systems, and established monitoring of various activities. Our next step might be to install an analytical system that would allow us to see which page(s) of the site our users are visiting. Which pages are more interesting, and which pages do they close immediately? Perhaps we would like to know what words the users googled before arriving at our site, and it would certainly not harm to know which devices they use (smartphones, tablets, PCs) and which platforms (Windows, Linux, Mac). Fortunately for us, all this information is very easy if we set up Google Analytics. The service has a free component, so it can be used by absolutely anyone. In general, a separate study of Google Analytics would be useful to everyone who works in IT, not least to present the capabilities of this impressive tool.

Conclusions

In this article, we had a look at servers, hosting, intermediate servers, databases, and systems for testing, monitoring, and analytics.

Actually, I really wanted to also write about GIT, SVN, Continuous Deployment (CI), Continuous Delivery (CD) and Continuous Deployment, to explain the meaning of and differences between each of these practices, but I decided that this article would become too technical and difficult to digest.

After all, you can google these topics if you're curious, but don't worry if you get confused, or the material seems too complex. Probably my desire to write about GIT and CI-CD is sole because they are also management tools, albeit purely technical, and designed especially for developers.

So now we understand what a project is and how it is compiled. We also understand the technical basics of its infrastructure. In the next article, we will look at the cooperation between the Client Company and the Developer Company, "patronize" half close to the end of our conversations.