CTOcast # 0: Ruslan Sinitsky (Jelastic)
Introducing the zero issue of the podcast on technology, processes, infrastructure, and people in IT companies. Today, visiting CTOcast is Ruslan Sinitsky, CTO and co-founder of Jelastic.
Listen to the podcast
Ruslan Sinitsky was born in 1978. Lives and works in Zhytomyr, Ukraine. He was fond of programming since childhood, he graduated from the Zhytomyr Military Institute of Radio Electronics with a degree in Special Monitoring Equipment. In 2001-2008 worked at the National Space Agency of Ukraine, where he was engaged in the development of software for monitoring earthquakes on the Earth's surface. In 2008-2011 - Senior UI Architect at iQueLab. He also worked as a freelancer in various outsourcing companies.
A few words about Jelastic :
In 2008, at the Habr, Ruslan Sinitsky met Konstantin Alexandrov (a programmer from Voronezh), with whom he came up with the idea of a tool for Java developers, which simplifies the process of developing applications and scaling them. Without a personal meeting for 2 years, Ruslan and Konstantin created a prototype.
In 2010, Hivext Technologies, Inc. was founded, becoming the parent of Jelastic. Around the same time, Alexey Skutin joined the team, looking for potential investors and promoting Jelastic in the market. In December 2010, investments in the sowing round were received from the Runa Capital fund, which allowed everyone to gather in one city - Zhytomyr and recruit a development team.
In 2012, the next round of investment took place, in which Almaz Capital Partners participated. In the same year, Jelastic was awarded the Duke's Choice Technology Award, the most prestigious award in the Java world.
In September 2013, Maxfield Capital joined the investor team, and John Derrick succeeded Ruslan as CEO.
At the moment, the company has about 80 thousand users around the world - in the USA, Europe, Asia and 24 partners - a hosting provider. Jelastic positions itself as the only Platform-as-Infrastructure solution in the world.
Listen to podcast
Pavel Pavlov: The topic of Platform-as-Infrastructure has already been touched upon today. I would like to learn more about what is the meaning of your company in this term?
Ruslan Sinitsky:The term is really new, it appeared just recently. Frankly speaking, we created it. Initially, we made a platform - Platform-as-a-Service, with which we positioned our company and which allowed us to simplify the life of developers. But the business model of our product was different from similar solutions, for example, Heroku and other similar products. Our main difference was that we didn’t install our software on Amazon, but on partner data centers. Accordingly, we had to solve the problems of Infrastructure-as-a-Service. It so happened that at first, without realizing it, in one product we solved two problems: Platform-as-a-Service and Infrastructure-as-a-Service. Therefore, our product is more complex and complex than our competitors.
Out of the box, you get the full range - Platform-as-a-Service and Infrastructure-as-a-Service. We have two administration panels: one for developers, the other for cluster administrators. And for our platform it is not necessary to have some kind of bottom layer, it is enough to provide bare iron and we can put a platform on top of it and solve the problems that our competitors solve, but based on Amazon.
Therefore, in a nutshell, Platform-as-Infrastructure is a hybrid of Platform-as-a-Service and Infrastructure-as-a-Service.
Alexander Astapenko: This is very well reflected in the design of your site, where two concepts merge to form Platform-as-Infrastructure.
Ruslan Sinitsky:Yes, in fact, we removed some inefficiency. Our product is designed to eliminate inefficiency: constant repetition of the same actions by administrators, two layers. People are not worried about Infrastructure-as-a-Service or Platform-as-a-Service, they need to solve specific problems. And our product simplifies complex things.
Alexander Astapenko: The direct customers and those who actually pay for the product are B2B companies, that is, some middle layer, and not the end users who will work with Jelastic. These are, for example, hosting providers. So? A few words about who your customers are?
Ruslan Sinitsky:You correctly noticed that there are several levels of clients. If we talk about customers who pay us money directly, then today they are hosters and companies who want to put Jelastic on their hardware. These can be banks, outsourcing companies, integrators, companies providing telecommunication services, that is, the B2B sector. These people, the same hosters, sell Jelastic to developers or SMB. If we talk about integrators and outsourcing companies, they do not sell to anyone, but solve their problems within the company and simplify development processes.
Alexander Astapenko:Do I understand correctly that product promotion goes in two directions: for end users who will work with the results, that is, the Jelastic product itself, and those who will install Jelastic on their servers?
Ruslan Sinitsky:Initially, we created the product for business customers, for hosters, but in principle, we always marketed it for end users. That is, our marketing strategy has always been largely aimed at end consumers. We initially created the Jelastic brand, explained why Jelastic is good, how it simplifies development, saves time, resources. Thus, we attracted end developers, SMB to our site and explained to them. A lot of traffic came to us, then we already distributed this traffic between our partners. Naturally, we did marketing in the hosting industry, went to conferences, explained why hosters need to install the platform, how they can open a new business branch. But the main resources, about 80%, were spent on creating a brand, Jelastic recognition among developers, those people who will directly use this product to solve their problems. Today we are starting to expand our marketing strategy and use more resources to promote our product in B2B, because now we need to communicate with enterprise customers, explain why they need Jelastic, how it can simplify life. There is a need to communicate with outsourcing companies, that is, this is another additional client.
Pavel Pavlov: This is the context of interest in the product, the platform, and how did you build confidence in what you are doing at the beginning of the development of the company and when working with large corporate clients?
Ruslan Sinitsky:Usually people are distrustful of new products, but there are always those who are willing to try to take a chance. These are mainly people who are looking for new markets, who understand that in time by connecting some kind of innovation to their business, you can win a good market segment. In our case, contacts with Parallels were important. They introduced us to the hosters, their acquaintances. And, roughly speaking, certain people have vouched for their name. For example, Sergey Belousov introduced us to his business acquaintances in the hosting industry and people, knowing Sergey and trusting him, at least began to listen to us. This does not mean that they with closed eyes will do what Sergey told them. This means that they at least took us on a visit and listened. At the initial stage, I traveled to various hosting companies. And most of them listened and said: “Okay, come back later.” Nevertheless, we managed to hook one hoster, from which it all started. This is Host Europe - the third hoster in Germany. In principle, the first deal was based on personal relationships. After that, we launched a beta, started publishing about Jelastic, comparing ourselves with competitors, attracting an audience. Accordingly, the traffic went. The hoster who trusted us saw that the end user had an interest, and we began to use it as a user case for other potential partners and began to attract them like that. Then the hoster appeared in America. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships. from which it all began. This is Host Europe - the third hoster in Germany. In principle, the first deal was based on personal relationships. After that, we launched a beta, started publishing about Jelastic, comparing ourselves with competitors, attracting an audience. Accordingly, the traffic went. The hoster who trusted us saw that the end user had an interest, and we began to use it as a user case for other potential partners and began to attract them like that. Then the hoster appeared in America. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships. from which it all began. This is Host Europe - the third hoster in Germany. In principle, the first deal was based on personal relationships. After that, we launched a beta, started publishing about Jelastic, comparing ourselves with competitors, attracting an audience. Accordingly, the traffic went. The hoster who trusted us saw that the end user had an interest, and we began to use it as a user case for other potential partners and began to attract them like that. Then the hoster appeared in America. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships. began to publish about Jelastic, compare themselves with competitors, attract an audience. Accordingly, the traffic went. The hoster who trusted us saw that the end user had an interest, and we began to use it as a user case for other potential partners and began to attract them like that. Then the hoster appeared in America. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships. began to publish about Jelastic, compare themselves with competitors, attract an audience. Accordingly, the traffic went. The hoster who trusted us saw that the end user had an interest, and we began to use it as a user case for other potential partners and began to attract them like that. Then the hoster appeared in America. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships.
The second point that needs to be emphasized in the development of Jelastic is that our product was based on a technical solution that our competitors did not have. They had a big problem with this - compatibility with standard applications. With Jelastic you can deploy any standard application and Jelastic will simplify its scaling. In many cases, he can do this automatically. Almost always, you do not need to rewrite anything, because you can write to the file system, load your favorite libraries, change configuration files, if you think that Jelastic does not optimally provide default settings. We try not to limit the end consumers in using their accumulated experience, reusing their libraries, let’s say so.
Pavel Pavlov: You managed to reach a certain compromise between the universality of the platform, which would suit many groups of users, and the space for flexibility and fine-tuning.
Ruslan Sinitsky: Yes, I think we managed to find a balance.
Pavel Pavlov: How long have you come to this?
Ruslan Sinitsky:We went to this at the level of intuition. I will not say that we were fully aware. Intuitively. Even our deal with Runa Capital, which, in fact, happened by chance. But we already knew that okay, we will conclude a deal with Runa Capital and gain access to Parallels, one of the leaders in the field of virtualization. Having gained access to these technologies and having talked with tech guys inside this company, we appreciated the great potential of this company with a very good virtualization product. And we laid it down. Then it turned out that the product has an advantage that other Platform-as-a-Service does not have - vertical scaling, the ability to automatically scale applications, complete resource isolation, that is, each application can be allocated isolated resources and allowed to write files to the file system, the ability to migrate the application between iron servers without downtime. That is, in the process we began to find our virtues. I will not say that it was originally a clear plan. Initially, the desire was planned to avoid any requirements for changes in the user application.
When we created the first version of our Hivext product, we gathered 5,000 users, and this Hivext was similar to the Google App Engine - Backend-as-a-Serivce. The disadvantage of this approach is that users cannot deploy a standard application, they cannot use the accumulated experience - they have to re-write the application. Accordingly, for a small startup - this is the road to nowhere. Large companies will not go there, only small startups, which in principle are not able to pay money at the initial stage. Having learned from this, we decided to make the main drawback in the next version of our platform the main advantage. We said that we will create a platform that does not require rewriting your code.
We constantly learn, create something, test it on the market, get feedback and improve our product. And even our last changes towards Platform-as-Infrastructure have happened, thanks to the experience accumulated over the entire time of work.
Alexander Astapenko: It is very similar to the Lean approach.
Ruslan Sinitsky: Yes, it almost seems. Honestly, they did not read it initially, but then, when time passed and I found a book, read and realized that we are very close to this.
Alexander Astapenko:But when you come to hosters or some corporate clients, not everyone has Parallels products with which you need to integrate. Each of them has its own environment. As I understand it, every time you come across a new separate case that needs to be decided - how do you integrate with this or that partner? Can you talk a little about this?
Ruslan Sinitsky:This was especially true for the first versions of Jelastic. We did not understand what other requirements for iron are still needed. We did not fully understand where the space would be for maneuver. If we talk about virtualization, we also did not understand whether it is possible to run our product inside other layers of virtualization, based on the same Amazon or Rackspace. Indeed, each partner’s billing system is often self-explanatory, some use some standard solutions, but there are a certain number of these solutions. Over time, we improved our product and currently received a boxed solution. We come to the hoster and say: “To run Jelastic you need hardware with such requirements ...”. Virtualization, not virtualization - he is not interested in it, he does not touch the Parallels virtualization system at all. If we talk about billing, then we created our internal virtual billing, all the processes take place inside Jelastic and now we are integrating at the API level, we say to any billing system of the hoster that at the end of the month you need to remove so much money from the user. How they shoot is their question.
The further the product develops, the more universal it becomes, the easier it is to service it, more documentation, user cases, less requirements for the initial resources for launching Jelastic appear.
Alexander Astapenko: How is the process going on? Who does the integration? Specialists from the host or someone from your side? And how much is the process controlled by the hoster? How much do they want to control it?
Ruslan Sinitsky:The first integrations were almost blind. When we went through this several times, we realized that the processes were repeating. Accordingly, a master plan was created. This is not only software installation, but also fine tuning, preparation of marketing materials, site preparation, customization of letter templates that are sent to users, localization. Therefore, the integration is planned for clear steps on each side: on the side of Jelastic or the host. Two people stand out for Jelastic integration. This is the account manager who leads the project (mostly a non-technical specialist). This is a person who speaks good English, who has good communication skills. And the second person is a techie directly performing technical work: installing Jelastic, configuration, analysis, if something went wrong. There are actions which must be produced on the host side. This list is issued to the hoster and the account manager passes with the project manager on the host side for each item, explains what needs to be done, leads the hoster on the project. Today this is a completely predictable process and we can roughly estimate how long it will take to integrate with a particular hoster, plan our own resources.
Alexander Astapenko: It can be seen that the process has already been prepared over the years of work. I understand that in the beginning it was not at all like that. You went through your own experience. Right?
Ruslan Sinitsky: It was a nightmare from the beginning, to be honest. We are lucky that we have found a person who, when there is chaos, you throw him into this chaos and there immediately becomes order. Such a person is definitely needed by the company.
Alexander Astapenko: In Russia, in the late 90s, such a person was thrown to rule the country, we heard about it.
Ruslan Sinitsky: Well, yes)
Alexander Astapenko:I want now to return to the product itself, which has also developed, as well as the integration process. Who deals with product issues in the company? How a decision is made will this or that feature enter the product, evaluate its prospects, what kind of life cycle it goes through. As you said, you are launching something, testing in the market, getting feedback, changing and so on in this cycle. Who does this and what does the process look like?
Ruslan Sinitsky:When we were 5-7 people, then this issue was resolved easier, fewer people and larger things were more obvious. When people become more and more work begins to appear, then everything becomes more complicated. Therefore, it is necessary to implement certain processes. We invited specialists who came to our team and set up the processes. This concerned the process of determining the priority of a particular functional. Today we use Agile, we use backlog.
There are many sources of information from where we draw directions for the potential development of our product. First of all, these are end users. We always hear the end developers: what is convenient, what is inconvenient, what is like, what is not like, what are the limitations. We periodically analyze the support channel. Support engineers send a report in one direction or another every week, which features were most requested. We hear our hosting partners who also have certain requests for cluster management, or they fail to attract an additional segment of users, because they cannot provide one or another function. We have an understanding of where we want to develop our product. We have internal needs, refactoring modules. Someone in the team may not like the architecture of a particular solution and it has the best offer. There is the needs of the operations team doing the installation; they want to reduce the time it takes. There are more and more directions.
Currently, I communicate with each leader of the directions (for support, communication with hosters, etc.) and we collect feedback, a kind of flat list. We vote in it, that is, each person in the direction determines the highest priority functionality. This is then analyzed and I compile the final roadmap for release. We are once again discussing this roadmap with key employees and we come to the conclusion that everyone understands why exactly these features are the most critical in the current release.
Alexander Astapenko: So you can say that you are the person who forms the Jelastic product?
Ruslan Sinitsky:You can say so, but I want to focus on the fact that the product is formed by the whole team. I’m just that person who collects information from different sources, listens to the arguments of various parties why this is important, I hear the pain of different people and try to set priorities correctly. Explain to some people why, for example, a feature proposed by another department is more important than the one offered by them. Then the team will have an understanding of where the product is developing, there will be no internal conflicts, wars. It is very important. That is, I am a kind of mediator at the current stage.
Alexander Astapenko: Well, the features have gathered, priorities have lined up, got into the release and the market. How do you make the decision the feature you need and it stays or remove it from the product? Or don’t you remove the features that get there at all?
Ruslan Sinitsky:We try to do MVP (Minimum viable product) - something that is easy to do in one squat, which is basically finished and solves a specific problem. We try to give it to end users and look at their reaction, that is, we collect feedback. To see whether we are going in the right direction, to analyze how interesting one feature is compared to another, whether the architectural solution is chosen correctly. For the next release, we are already making some changes, in accordance with the collected feedback for various features, we set priorities. We never released one feature from start to finish in one release. Because otherwise we would focus only specifically on this feature, and there are a lot of directions. Secondly, if you do something wrong when you go deep and try it on end users, remaking will be very difficult and problematic. You will lose a lot of time in the wrong direction, which will be very expensive for the company. Therefore, we try to go in small, iterative steps. For example, we recently released Ruby in a private beta, the hosters did not hold back and published in a public beta. We collected the feedback and we know for sure what is missing in the current Ruby implementation. 100% know what is most critical, and we do this in the next release. We’ll release it again and look: yeah, we covered 80%, now we cover 90% of cases. What needs to be done in order to cover 95% of cases? We collected the feedback and we know for sure what is missing in the current Ruby implementation. 100% know what is most critical, and we do this in the next release. We’ll release it again and look: yeah, we covered 80%, now we cover 90% of cases. What needs to be done in order to cover 95% of cases? We collected the feedback and we know for sure what is missing in the current Ruby implementation. 100% know what is most critical, and we do this in the next release. We’ll release it again and look: yeah, we covered 80%, now we cover 90% of cases. What needs to be done in order to cover 95% of cases?
Pavel Pavlov: And how did the idea of such a transition to new platforms for PHP, Ruby come about? Motivated by the popularity of the platform or something else?
Ruslan Sinitsky:This multilingualism was planned and laid down originally in architecture. We even had a debate within the team about what to do first - PHP or Java. And the dispute was between investors and the founders of the company. Investors had access to the hosting industry, and the hosting industry was mostly about PHP. And it was said: “Well, the hosters know PHP and want PHP.” And we, for our part, said: “They know PHP - they have PHP, they do not know Java - they do not have Java.” I traveled to hosting companies and asked, “Why don't you guys sell Java?” And they unanimously said: because it is difficult, because we do not know how to do it. There was no normal solution. And we started with that. Java itself is a more complex language, more application servers, databases, various combinations. So we still decided to start with Java. Understood that if we solve the issue for Java, then it will be much easier for PHP and other languages to extend the architecture already. But initially the basic principles were laid so that the platform will support many programming languages.
Pavel Pavlov: How did Ruby come about?
Ruslan Sinitsky: We added PHP, we have launched commercial PHP, it works fine, resources are free, and then we went to Ruby.
Pavel Pavlov: That is, step by step?
Ruslan Sinitsky:Yes. Our next node.js, after it is .NET. I think Python will be added along with node.js. Just a couple of days ago, we announced a partnership with Red Hat, in principle, with our competitor, OpenShift (Platform-as-a-Service), that we will support a unified template format for a stack of programming languages, for application servers, databases . There will be a unified format between the two platforms. This means that, for example, developers of databases, application servers or just applications can pack their applications in this format and the application can be easily deployed either in OpenShift or Jelastic and it will not need to be rewritten for a specific platform. Thus, the ecosystem will grow very much in the near future. This is a very serious step towards unification, which is very good for all players in the market.
The text version of the podcast will continue in the coming days.
Listen to the podcast
Ruslan Sinitsky was born in 1978. Lives and works in Zhytomyr, Ukraine. He was fond of programming since childhood, he graduated from the Zhytomyr Military Institute of Radio Electronics with a degree in Special Monitoring Equipment. In 2001-2008 worked at the National Space Agency of Ukraine, where he was engaged in the development of software for monitoring earthquakes on the Earth's surface. In 2008-2011 - Senior UI Architect at iQueLab. He also worked as a freelancer in various outsourcing companies.
A few words about Jelastic :
In 2008, at the Habr, Ruslan Sinitsky met Konstantin Alexandrov (a programmer from Voronezh), with whom he came up with the idea of a tool for Java developers, which simplifies the process of developing applications and scaling them. Without a personal meeting for 2 years, Ruslan and Konstantin created a prototype.
In 2010, Hivext Technologies, Inc. was founded, becoming the parent of Jelastic. Around the same time, Alexey Skutin joined the team, looking for potential investors and promoting Jelastic in the market. In December 2010, investments in the sowing round were received from the Runa Capital fund, which allowed everyone to gather in one city - Zhytomyr and recruit a development team.
In 2012, the next round of investment took place, in which Almaz Capital Partners participated. In the same year, Jelastic was awarded the Duke's Choice Technology Award, the most prestigious award in the Java world.
In September 2013, Maxfield Capital joined the investor team, and John Derrick succeeded Ruslan as CEO.
At the moment, the company has about 80 thousand users around the world - in the USA, Europe, Asia and 24 partners - a hosting provider. Jelastic positions itself as the only Platform-as-Infrastructure solution in the world.
Listen to podcast
Text version of the podcast (1st part)
Pavel Pavlov: The topic of Platform-as-Infrastructure has already been touched upon today. I would like to learn more about what is the meaning of your company in this term?
Ruslan Sinitsky:The term is really new, it appeared just recently. Frankly speaking, we created it. Initially, we made a platform - Platform-as-a-Service, with which we positioned our company and which allowed us to simplify the life of developers. But the business model of our product was different from similar solutions, for example, Heroku and other similar products. Our main difference was that we didn’t install our software on Amazon, but on partner data centers. Accordingly, we had to solve the problems of Infrastructure-as-a-Service. It so happened that at first, without realizing it, in one product we solved two problems: Platform-as-a-Service and Infrastructure-as-a-Service. Therefore, our product is more complex and complex than our competitors.
Out of the box, you get the full range - Platform-as-a-Service and Infrastructure-as-a-Service. We have two administration panels: one for developers, the other for cluster administrators. And for our platform it is not necessary to have some kind of bottom layer, it is enough to provide bare iron and we can put a platform on top of it and solve the problems that our competitors solve, but based on Amazon.
Therefore, in a nutshell, Platform-as-Infrastructure is a hybrid of Platform-as-a-Service and Infrastructure-as-a-Service.
Alexander Astapenko: This is very well reflected in the design of your site, where two concepts merge to form Platform-as-Infrastructure.
Ruslan Sinitsky:Yes, in fact, we removed some inefficiency. Our product is designed to eliminate inefficiency: constant repetition of the same actions by administrators, two layers. People are not worried about Infrastructure-as-a-Service or Platform-as-a-Service, they need to solve specific problems. And our product simplifies complex things.
Alexander Astapenko: The direct customers and those who actually pay for the product are B2B companies, that is, some middle layer, and not the end users who will work with Jelastic. These are, for example, hosting providers. So? A few words about who your customers are?
Ruslan Sinitsky:You correctly noticed that there are several levels of clients. If we talk about customers who pay us money directly, then today they are hosters and companies who want to put Jelastic on their hardware. These can be banks, outsourcing companies, integrators, companies providing telecommunication services, that is, the B2B sector. These people, the same hosters, sell Jelastic to developers or SMB. If we talk about integrators and outsourcing companies, they do not sell to anyone, but solve their problems within the company and simplify development processes.
Alexander Astapenko:Do I understand correctly that product promotion goes in two directions: for end users who will work with the results, that is, the Jelastic product itself, and those who will install Jelastic on their servers?
Ruslan Sinitsky:Initially, we created the product for business customers, for hosters, but in principle, we always marketed it for end users. That is, our marketing strategy has always been largely aimed at end consumers. We initially created the Jelastic brand, explained why Jelastic is good, how it simplifies development, saves time, resources. Thus, we attracted end developers, SMB to our site and explained to them. A lot of traffic came to us, then we already distributed this traffic between our partners. Naturally, we did marketing in the hosting industry, went to conferences, explained why hosters need to install the platform, how they can open a new business branch. But the main resources, about 80%, were spent on creating a brand, Jelastic recognition among developers, those people who will directly use this product to solve their problems. Today we are starting to expand our marketing strategy and use more resources to promote our product in B2B, because now we need to communicate with enterprise customers, explain why they need Jelastic, how it can simplify life. There is a need to communicate with outsourcing companies, that is, this is another additional client.
Pavel Pavlov: This is the context of interest in the product, the platform, and how did you build confidence in what you are doing at the beginning of the development of the company and when working with large corporate clients?
Ruslan Sinitsky:Usually people are distrustful of new products, but there are always those who are willing to try to take a chance. These are mainly people who are looking for new markets, who understand that in time by connecting some kind of innovation to their business, you can win a good market segment. In our case, contacts with Parallels were important. They introduced us to the hosters, their acquaintances. And, roughly speaking, certain people have vouched for their name. For example, Sergey Belousov introduced us to his business acquaintances in the hosting industry and people, knowing Sergey and trusting him, at least began to listen to us. This does not mean that they with closed eyes will do what Sergey told them. This means that they at least took us on a visit and listened. At the initial stage, I traveled to various hosting companies. And most of them listened and said: “Okay, come back later.” Nevertheless, we managed to hook one hoster, from which it all started. This is Host Europe - the third hoster in Germany. In principle, the first deal was based on personal relationships. After that, we launched a beta, started publishing about Jelastic, comparing ourselves with competitors, attracting an audience. Accordingly, the traffic went. The hoster who trusted us saw that the end user had an interest, and we began to use it as a user case for other potential partners and began to attract them like that. Then the hoster appeared in America. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships. from which it all began. This is Host Europe - the third hoster in Germany. In principle, the first deal was based on personal relationships. After that, we launched a beta, started publishing about Jelastic, comparing ourselves with competitors, attracting an audience. Accordingly, the traffic went. The hoster who trusted us saw that the end user had an interest, and we began to use it as a user case for other potential partners and began to attract them like that. Then the hoster appeared in America. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships. from which it all began. This is Host Europe - the third hoster in Germany. In principle, the first deal was based on personal relationships. After that, we launched a beta, started publishing about Jelastic, comparing ourselves with competitors, attracting an audience. Accordingly, the traffic went. The hoster who trusted us saw that the end user had an interest, and we began to use it as a user case for other potential partners and began to attract them like that. Then the hoster appeared in America. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships. began to publish about Jelastic, compare themselves with competitors, attract an audience. Accordingly, the traffic went. The hoster who trusted us saw that the end user had an interest, and we began to use it as a user case for other potential partners and began to attract them like that. Then the hoster appeared in America. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships. began to publish about Jelastic, compare themselves with competitors, attract an audience. Accordingly, the traffic went. The hoster who trusted us saw that the end user had an interest, and we began to use it as a user case for other potential partners and began to attract them like that. Then the hoster appeared in America. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships. And when there were already two, the third is much easier to connect. When three appeared - the fourth, fifth and twentieth went along the thumb track. The first deals were based on more personal relationships.
The second point that needs to be emphasized in the development of Jelastic is that our product was based on a technical solution that our competitors did not have. They had a big problem with this - compatibility with standard applications. With Jelastic you can deploy any standard application and Jelastic will simplify its scaling. In many cases, he can do this automatically. Almost always, you do not need to rewrite anything, because you can write to the file system, load your favorite libraries, change configuration files, if you think that Jelastic does not optimally provide default settings. We try not to limit the end consumers in using their accumulated experience, reusing their libraries, let’s say so.
Pavel Pavlov: You managed to reach a certain compromise between the universality of the platform, which would suit many groups of users, and the space for flexibility and fine-tuning.
Ruslan Sinitsky: Yes, I think we managed to find a balance.
Pavel Pavlov: How long have you come to this?
Ruslan Sinitsky:We went to this at the level of intuition. I will not say that we were fully aware. Intuitively. Even our deal with Runa Capital, which, in fact, happened by chance. But we already knew that okay, we will conclude a deal with Runa Capital and gain access to Parallels, one of the leaders in the field of virtualization. Having gained access to these technologies and having talked with tech guys inside this company, we appreciated the great potential of this company with a very good virtualization product. And we laid it down. Then it turned out that the product has an advantage that other Platform-as-a-Service does not have - vertical scaling, the ability to automatically scale applications, complete resource isolation, that is, each application can be allocated isolated resources and allowed to write files to the file system, the ability to migrate the application between iron servers without downtime. That is, in the process we began to find our virtues. I will not say that it was originally a clear plan. Initially, the desire was planned to avoid any requirements for changes in the user application.
When we created the first version of our Hivext product, we gathered 5,000 users, and this Hivext was similar to the Google App Engine - Backend-as-a-Serivce. The disadvantage of this approach is that users cannot deploy a standard application, they cannot use the accumulated experience - they have to re-write the application. Accordingly, for a small startup - this is the road to nowhere. Large companies will not go there, only small startups, which in principle are not able to pay money at the initial stage. Having learned from this, we decided to make the main drawback in the next version of our platform the main advantage. We said that we will create a platform that does not require rewriting your code.
We constantly learn, create something, test it on the market, get feedback and improve our product. And even our last changes towards Platform-as-Infrastructure have happened, thanks to the experience accumulated over the entire time of work.
Alexander Astapenko: It is very similar to the Lean approach.
Ruslan Sinitsky: Yes, it almost seems. Honestly, they did not read it initially, but then, when time passed and I found a book, read and realized that we are very close to this.
Alexander Astapenko:But when you come to hosters or some corporate clients, not everyone has Parallels products with which you need to integrate. Each of them has its own environment. As I understand it, every time you come across a new separate case that needs to be decided - how do you integrate with this or that partner? Can you talk a little about this?
Ruslan Sinitsky:This was especially true for the first versions of Jelastic. We did not understand what other requirements for iron are still needed. We did not fully understand where the space would be for maneuver. If we talk about virtualization, we also did not understand whether it is possible to run our product inside other layers of virtualization, based on the same Amazon or Rackspace. Indeed, each partner’s billing system is often self-explanatory, some use some standard solutions, but there are a certain number of these solutions. Over time, we improved our product and currently received a boxed solution. We come to the hoster and say: “To run Jelastic you need hardware with such requirements ...”. Virtualization, not virtualization - he is not interested in it, he does not touch the Parallels virtualization system at all. If we talk about billing, then we created our internal virtual billing, all the processes take place inside Jelastic and now we are integrating at the API level, we say to any billing system of the hoster that at the end of the month you need to remove so much money from the user. How they shoot is their question.
The further the product develops, the more universal it becomes, the easier it is to service it, more documentation, user cases, less requirements for the initial resources for launching Jelastic appear.
Alexander Astapenko: How is the process going on? Who does the integration? Specialists from the host or someone from your side? And how much is the process controlled by the hoster? How much do they want to control it?
Ruslan Sinitsky:The first integrations were almost blind. When we went through this several times, we realized that the processes were repeating. Accordingly, a master plan was created. This is not only software installation, but also fine tuning, preparation of marketing materials, site preparation, customization of letter templates that are sent to users, localization. Therefore, the integration is planned for clear steps on each side: on the side of Jelastic or the host. Two people stand out for Jelastic integration. This is the account manager who leads the project (mostly a non-technical specialist). This is a person who speaks good English, who has good communication skills. And the second person is a techie directly performing technical work: installing Jelastic, configuration, analysis, if something went wrong. There are actions which must be produced on the host side. This list is issued to the hoster and the account manager passes with the project manager on the host side for each item, explains what needs to be done, leads the hoster on the project. Today this is a completely predictable process and we can roughly estimate how long it will take to integrate with a particular hoster, plan our own resources.
Alexander Astapenko: It can be seen that the process has already been prepared over the years of work. I understand that in the beginning it was not at all like that. You went through your own experience. Right?
Ruslan Sinitsky: It was a nightmare from the beginning, to be honest. We are lucky that we have found a person who, when there is chaos, you throw him into this chaos and there immediately becomes order. Such a person is definitely needed by the company.
Alexander Astapenko: In Russia, in the late 90s, such a person was thrown to rule the country, we heard about it.
Ruslan Sinitsky: Well, yes)
Alexander Astapenko:I want now to return to the product itself, which has also developed, as well as the integration process. Who deals with product issues in the company? How a decision is made will this or that feature enter the product, evaluate its prospects, what kind of life cycle it goes through. As you said, you are launching something, testing in the market, getting feedback, changing and so on in this cycle. Who does this and what does the process look like?
Ruslan Sinitsky:When we were 5-7 people, then this issue was resolved easier, fewer people and larger things were more obvious. When people become more and more work begins to appear, then everything becomes more complicated. Therefore, it is necessary to implement certain processes. We invited specialists who came to our team and set up the processes. This concerned the process of determining the priority of a particular functional. Today we use Agile, we use backlog.
There are many sources of information from where we draw directions for the potential development of our product. First of all, these are end users. We always hear the end developers: what is convenient, what is inconvenient, what is like, what is not like, what are the limitations. We periodically analyze the support channel. Support engineers send a report in one direction or another every week, which features were most requested. We hear our hosting partners who also have certain requests for cluster management, or they fail to attract an additional segment of users, because they cannot provide one or another function. We have an understanding of where we want to develop our product. We have internal needs, refactoring modules. Someone in the team may not like the architecture of a particular solution and it has the best offer. There is the needs of the operations team doing the installation; they want to reduce the time it takes. There are more and more directions.
Currently, I communicate with each leader of the directions (for support, communication with hosters, etc.) and we collect feedback, a kind of flat list. We vote in it, that is, each person in the direction determines the highest priority functionality. This is then analyzed and I compile the final roadmap for release. We are once again discussing this roadmap with key employees and we come to the conclusion that everyone understands why exactly these features are the most critical in the current release.
Alexander Astapenko: So you can say that you are the person who forms the Jelastic product?
Ruslan Sinitsky:You can say so, but I want to focus on the fact that the product is formed by the whole team. I’m just that person who collects information from different sources, listens to the arguments of various parties why this is important, I hear the pain of different people and try to set priorities correctly. Explain to some people why, for example, a feature proposed by another department is more important than the one offered by them. Then the team will have an understanding of where the product is developing, there will be no internal conflicts, wars. It is very important. That is, I am a kind of mediator at the current stage.
Alexander Astapenko: Well, the features have gathered, priorities have lined up, got into the release and the market. How do you make the decision the feature you need and it stays or remove it from the product? Or don’t you remove the features that get there at all?
Ruslan Sinitsky:We try to do MVP (Minimum viable product) - something that is easy to do in one squat, which is basically finished and solves a specific problem. We try to give it to end users and look at their reaction, that is, we collect feedback. To see whether we are going in the right direction, to analyze how interesting one feature is compared to another, whether the architectural solution is chosen correctly. For the next release, we are already making some changes, in accordance with the collected feedback for various features, we set priorities. We never released one feature from start to finish in one release. Because otherwise we would focus only specifically on this feature, and there are a lot of directions. Secondly, if you do something wrong when you go deep and try it on end users, remaking will be very difficult and problematic. You will lose a lot of time in the wrong direction, which will be very expensive for the company. Therefore, we try to go in small, iterative steps. For example, we recently released Ruby in a private beta, the hosters did not hold back and published in a public beta. We collected the feedback and we know for sure what is missing in the current Ruby implementation. 100% know what is most critical, and we do this in the next release. We’ll release it again and look: yeah, we covered 80%, now we cover 90% of cases. What needs to be done in order to cover 95% of cases? We collected the feedback and we know for sure what is missing in the current Ruby implementation. 100% know what is most critical, and we do this in the next release. We’ll release it again and look: yeah, we covered 80%, now we cover 90% of cases. What needs to be done in order to cover 95% of cases? We collected the feedback and we know for sure what is missing in the current Ruby implementation. 100% know what is most critical, and we do this in the next release. We’ll release it again and look: yeah, we covered 80%, now we cover 90% of cases. What needs to be done in order to cover 95% of cases?
Pavel Pavlov: And how did the idea of such a transition to new platforms for PHP, Ruby come about? Motivated by the popularity of the platform or something else?
Ruslan Sinitsky:This multilingualism was planned and laid down originally in architecture. We even had a debate within the team about what to do first - PHP or Java. And the dispute was between investors and the founders of the company. Investors had access to the hosting industry, and the hosting industry was mostly about PHP. And it was said: “Well, the hosters know PHP and want PHP.” And we, for our part, said: “They know PHP - they have PHP, they do not know Java - they do not have Java.” I traveled to hosting companies and asked, “Why don't you guys sell Java?” And they unanimously said: because it is difficult, because we do not know how to do it. There was no normal solution. And we started with that. Java itself is a more complex language, more application servers, databases, various combinations. So we still decided to start with Java. Understood that if we solve the issue for Java, then it will be much easier for PHP and other languages to extend the architecture already. But initially the basic principles were laid so that the platform will support many programming languages.
Pavel Pavlov: How did Ruby come about?
Ruslan Sinitsky: We added PHP, we have launched commercial PHP, it works fine, resources are free, and then we went to Ruby.
Pavel Pavlov: That is, step by step?
Ruslan Sinitsky:Yes. Our next node.js, after it is .NET. I think Python will be added along with node.js. Just a couple of days ago, we announced a partnership with Red Hat, in principle, with our competitor, OpenShift (Platform-as-a-Service), that we will support a unified template format for a stack of programming languages, for application servers, databases . There will be a unified format between the two platforms. This means that, for example, developers of databases, application servers or just applications can pack their applications in this format and the application can be easily deployed either in OpenShift or Jelastic and it will not need to be rewritten for a specific platform. Thus, the ecosystem will grow very much in the near future. This is a very serious step towards unification, which is very good for all players in the market.
The text version of the podcast will continue in the coming days.