It is always fun to start a new project. Fresh and simple classes, clear boundaries, clear architecture – everything is logical and beautiful. New functionality is added quickly and easily.

Time passes, the project grows and new requirements keep arriving. So the day comes when you find something bad in the code. Someone cut a corner and made a small glitch. It even happens that you yourself do something in a hurry, honestly inserting “still todo” into the code – simply because this functionality is needed for the upcoming release, and there is no time to do everything correctly. “We know it’s there, but we will definitely fix after this release, but now we need to issue this version,” is usually said at that time. It’s a technical debt.

However, there is nothing more permanent than temporary! Usually it happens that the technical debt is only increasing. Just as a loan in a bank requires interest payments, the presence of technical debt takes its interest. We pay for this with the increasing complexity of making changes, the increasing non-obviousness and illogicality of the model, the disappearing enthusiasm of the team.

Then at a certain point, it becomes clear: The story repeated itself and we have in our hands the next “big ball of mud”. What to do and can this be avoided?

Nowadays, many see the answer in microservice architecture. It has clear physical boundaries, which will not allow cutting corners. Not at least in the way it would have been done in the case of a monolith system.

But the microservices approach has its price, stemming from the distributed nature of such a system. Where everything happened before in one process, we now have inter-server interaction. Which comes with data transmission over the network, as well as serialization/deserialization of data. Where there used to be transactional integrity, now there is event consistency. Instead of synchronous calls, with a clear result, now there is an asynchronous call to several nodes, each of which may return with an error or might give a timeout. And many other issues that are not obvious at first glance, but will automatically pop up because we are using distributed systems. Even when starting a new project, it may be difficult or even impossible for us to properly divide the future system into microservices, simply because we do not know how the system will develop. And trying to think about the architecture in advance is usually unproductive.

In general, when developing a new project from scratch based on microservices, the feeling of shooting flies with a cannon does not leave. The system still does not look so complicated as to apply division into subsystems.
Obviously, when the system starts to grow there is a moment when the price of microservices pays off. It will be reducing the costs of decreasing the productivity of the team when the system becomes more complex. Martin Fowler (Martin Fowler) well illustrated this in his article Microservice Premium:

Read more »

Recently the first version of a system was put into production, which we helped to develop. This system is based on a microservice-architecture approach.

This approach has recently gained a lot of popularity. And as usual with ‘new things’, they are being hailed as being the best thing since sliced bread. However to realize the true ‘pluses and minuses’, you need to put building a system like this into practice. We did this, and we would like to tell about our experience.

Read more »

On March 16, the new versions of php, namely v7.0.17 and v7.1.3, were released. This is good news for many php developers, but for us it has an extra meaning, because our patch has been accepted there. The patch that fixes ‘keep-alive’ connections in php-fpm sapi.

Php-fpm first appeared as a separate patch for php 5.2, adding a manager for fastcgi processes, that allows you to organize individual pools, monitors the execution times of workflows and much more. In the php 5.4 branch it was accepted as an official sapi, which mean we didn’t need to apply this patch every time a new bugfix version of php arrived.

Read more »

In today’s article we are going to focus on the Angular2 framework . We will talk about the Angular1 drawbacks,  describe  the main changes in the new version of the framework and, most importantly, share our impressions of the new version of the software.

Read more »

Our clients often try to push us to hire freelancers and remote developers to expand the team. Sometimes we agree, but more often – we actively resist the suggestion 🙂 This article will help us to understand various schemes of remote development and determine which schemes are efficient for different types of projects.


The first step is to define the terms. If we talk about physical location of employees and degree of their involvement in a project, there are two basic dichotomies: Contract vs Staff Employee and Office vs Remote Work.


Remote dihotomy

Read more »

We’re often asked how much it costs to make a Trading Desk system. We literally just the other day received this letter:
“…I must know how much it costs to develop a complete Agency Trading Desk, even just a ballpark figure… It would be a big help if you could give me an approximate cost…”

When you start developing what our correspondents imply by an Agency Trading Desk (ATD), it turns out that their understandings differ.

We have several ATDs at various stages of development. Before starting development, we looked at quite a few commercial systems. “Looked at” isn’t the best word, but maybe evaluate; by this we mean our analysts combed the length and breadth of functions and conducted a detailed analysis of the fundamental features.

We’ll soon be placing a description of several systems here. We will start with TheTradeDesk and Cappture. These choices may seems somewhat strange. TheTradeDesk is without a doubt the leader in its field; it’s a full DSP with a very richly functional ATD, especially in terms of RTB purchasing. Cappture is a new and, at the moment, fairly unknown system. As it turned out, one of our Japanese clients, a digital agency representative, uses exactly these systems and wanted to create several hybrid functions in their own ATD system.
Read more »

The task of forecasting traffic

When making banner advertising solution, it’s very important to provide advertisers with the possibility of campaign forecasting. This kind of forecast lets the user know:

  1. If it’s possible to return the necessary number of impressions in a planned period
  2. Potential banner placement for a given advertising space with given targeting conditions.

Practically all modern advertising platforms (Google, AdWords, OpenX, Yandex.Direct) provide forecasts, although usually without mentioning the quality of the forecast. We will speak in more detail about how a forecast system can be built and what the factors influence the quality of the forecast.

A typical forecast system uses a cumulative advertising-space statistics system as a starting point.
Read more »

Writing requirements specification is one of the first stages of the project development. It precedes the system development. The requirements specification describes the business domain, the existing infrastructure of the customer, the requirements for the created functional as well as non-functional requirements. The resulting document is useful for both the business user so that he made sure that all of his wishes for the future system had been taken into account, and for us to assess the cost of system development.

Requirements specification. Basic principles.

In our projects, when returning videos from servers, the question of disk subsystem efficiency comes up. Obviously, gigabit network interfaces are more efficient than, say, a 2 disk RAID 0. If video clips shared the same popularity, then hard disks would be a bottleneck when returning content.

We, however, have been lucky and there has always been a small set of clips which make up 80% of the traffic and a long line of less-frequently-accessed clips. This small set subsides in the file system’s cache and is returned practically without any disk activity.

For example, if we have 100 gigabytes of clips on a server, and the server has 24 gigs of memory, then we can draw this graph. Along the horizontal line, we have files sorted by popularity; along the vertical line, we have traffic caused by these files. The total traffic is the surface area under the line.
Read more »

Last week, the “Russian Internet technologies” conference took place, where we presented our experience working with streaming video and protecting video content.

A fairly large portion of our projects have to do with storing and publishing video content on the Internet. One of the many questions our clients often ask is the question of protecting content from illegal reproduction and distribution. There’s a wide-spread belief that there exist programs and technologies which are capable of guaranteeing that the copying and redistribution of licensed content is impossible. In reality, these software only gives off the impression that is possible.

In our presentation, we sought to discuss existing technologies, their vulnerabilities, and free, open-source equivalents which grant the same level of protection as proprietary and very expensive products.
In particular, we showed that popular “protected” video streaming protocols, like RTMPE, don’t guarantee the protection of content from illegal copying. No existing DRM system can simply provide 100% protection.
As an alternative to expensive and often limited content-protection systems, a series of simple techniques were suggested which would offer the same level of security.

Our presentations can be viewed here.