Monstrous frankenstek
Author: Ilya Stechkin
About the monster of Dr. Frankenstein, who wanted to bestow life on dead matter, many have heard. As you remember, everything ended sadly - the death of the scientist and his relatives. And the monster itself. Let this story serve as a warning to developers who are trying to take away life from OpenStack, creating projects without taking into account the logic of the development of the ecosystem.
')
Today, no one doubts that the clouds are needed not only for idealistic romanticists, but also for businessmen. Communal computing - the clever name for cloud technologies - will be useful to those who provide banking services, are engaged in logistics, treats patients, trades, develops software products, analyzes large amounts of data, organizes events ... Even those who write texts or post cats in social networks - use clouds, although not aware of this.
But the cloud is, first of all, a data storage and processing architecture. It is fundamentally important to understand that the cloud involves the transition from physical servers to virtual machines. In other words, you get the opportunity to more effectively use the existing infrastructure, the fleet of existing equipment; operate on logical nodes, not physical servers. And you can build such a design in your own data center. Then the data will not leave the company, security will be exactly at the level that you yourself are able to provide, but with all the benefits of the cloud will be at your disposal. This is called a private (or private) cloud.
There are scenarios in which critical data is stored in a private cloud, and applications using this data exist in a public cloud. For example, you have data on the cost of your products, including information about the principles of pricing. Obviously, this information constitutes a trade secret. But changes in the price of objects of sale should be reflected in the online catalog. In this case, the catalog itself, which is a list of products and fields for displaying prices, as well as online order forms may exist in an open cloud, since this information is not secret. Price changes can be automatically transferred from a private cloud to a public one. Conversely, completed order forms can be automatically forwarded from a public cloud to a private cloud in order to provide better protection for customers' personal data. Such a “symbiosis” of private and public clouds is called a “hybrid cloud”.
There are both open and proprietary solutions for building private and hybrid clouds. However, the problem of the latter is that they, in most cases, are developed by companies that may become hostages of the “sanctions war”. In other words, there are no guarantees that the next round of sanctions will not close client companies access to updates and support services of cloud solution providers. This is probably why more and more attention is paid to open cloud platforms, among which the obvious leader is OpenStack.
You can understand enthusiasts from regions that are trying to “ride the wave” and offer their services to create a cloud to one or another large company. This is their chance to break through to a big market. It is more difficult to understand eminent IT companies offering the same one-day crafts that earned the nickname “Frankenstek”. The client turns out to be misled and in expenses. It harms both the image of companies and the concept of open source. After all, the main advantage of open source for users is the ability to save on the development and implementation of solutions, and for developers - the ability to work together to reduce the time and cost of creating a product. It is this “collective creativity” that allows us to offer a quality product that can compete with the decisions of major vendors for less money.
In the novel Mary Shelley, the scientist Victor Frankenstein creates the living from the inanimate. In our case, everything happens the other way around. The creators of “Frankenstek” turn a living product that can develop and grow - into zombies. Such projects after “birth” are doomed to remain at the same level of development, while the whole OpenStack ecosystem evolves every six months - in accordance with the release cycle.
The developers of “frankenstekov” from all the functionality of OpenStack leave only the one that the customer needs at the moment. Imagine a Rubik's Cube that spins only in one direction and only one facet. An absurd artifact is obtained, is not it?
When a client formulates TK developers, he takes care of solving the tasks that face him here and now, this is normal. It is abnormal when developers overlook the further evolution of the ecosystem whose life activity they use when solving the current client problem.
Meanwhile, as already mentioned, OpenStack changes every six months, new functions appear, old bugs are corrected, opportunities open that did not exist in previous versions of the product. Conversely, some features are no longer supported. This means that after six months, the client may be left with nothing.
To create a “cloud” customer spends substantial funds. If the product is made taking into account the features of the ecosystem, then any company specializing in OpenStack can support it. And support for any software product is required: at least we are talking about the timely installation of upgrades, security updates, training the customer’s employees in working with the product ... Frankenskte is completely dependent on its creator. It is excluded from the process of the evolution of the ecosystem, so that for the introduction of new "chips" from the next release you will need to invest as much money as in the initial installation.
Once, several active contributors to OpenStack created the Piston company. They decided that they could overtake the developer community and make a proprietary commercial product based on the “vanilla” OpenStack. They understood how the community functions and made an informed choice. The experiment gave negative results, providing the community with an opportunity to make sure that independent “doping”, without taking into account the interests of the majority of participants in the development process, leads to undesirable consequences. The company Piston was on the verge of bankruptcy and was acquired by the IT giant Cisco, “frakenstek” ruined its creator.
Unfortunately, many Russian developers have ignored the experience of overseas colleagues. And continue to engage in amateur, consistently turning a living product into a dead essence, parasitic on the budgets of the customer.
Meanwhile, the customer, most likely, is not alone in the search for solutions to various tasks. This means that products developed for the client can become part of the OpenStack ecosystem. So it will be supported and improved by the whole community. There is, however, a nuance: for this, the development company must have weight in the community in order to interest other players in the project. From a team of 100 engineers, you should not expect a comprehensive examination, support for all components of the ecosystem, the ability to engage in product implementation, customer training, support for both previous and current versions of OpenStack.
However, hundreds of engineers can easily cope with the implementation of a solution developed by one of the “locomotives” of the community. It is easy to determine the composition of the “locomotive depot”. It is enough to open the Stackalytics service.
Once again we will remind that the client, after the implementation of the solution based on OpenStack, as well as any proprietary solution, will require support. For example, you may need to upgrade to new versions of the product. It is desirable that this process be carried out without serious consequences and without additional costs.
A simple example: you made a driver for some proprietary storage. Half a year passes, the time comes to update the system, administrators make an upgrade of the system, and then it turns out that the driver does not work ... And serious money was paid for a lot of money. The reason is that there have been changes in the system core, but nobody thought about the driver. Because the community had no information about its existence, it was made “on the knee” in the process of “finishing” the version of the distributive that was relevant at the time of the project delivery. But you, for sure, are not the only customer of the manufacturer of this stock. And another hundred companies would be happy to have such a driver, and even in working condition. And if it was made by the whole world, then, firstly, for each of the interested companies, it would come out much cheaper, and secondly, the community would take care to make the corresponding CI and test it for any assembly: this scheme is really It works that it is easy to observe everything in the same Stackalytics in the Vendor Drivers section.
To summarize: the average OpenStack user needs a representative in the community. A company that implements, through partnerships with the “locomotive”, can represent the interests of its client. Thus, if a developer adequately assesses his strength and takes care not only of short-term profit, but also of the welfare of his client, he benefits the whole community. And vice versa: if he cares about the welfare of the community, then he will inevitably benefit the client, making his life easier in the future. This is what distinguishes the living and developing OpenStack from the dead, cold and greedy to client money “frankenstek”.
About the monster of Dr. Frankenstein, who wanted to bestow life on dead matter, many have heard. As you remember, everything ended sadly - the death of the scientist and his relatives. And the monster itself. Let this story serve as a warning to developers who are trying to take away life from OpenStack, creating projects without taking into account the logic of the development of the ecosystem.
')
“Thank you, Cap!” Or a few platitudes about the clouds
Today, no one doubts that the clouds are needed not only for idealistic romanticists, but also for businessmen. Communal computing - the clever name for cloud technologies - will be useful to those who provide banking services, are engaged in logistics, treats patients, trades, develops software products, analyzes large amounts of data, organizes events ... Even those who write texts or post cats in social networks - use clouds, although not aware of this.
But the cloud is, first of all, a data storage and processing architecture. It is fundamentally important to understand that the cloud involves the transition from physical servers to virtual machines. In other words, you get the opportunity to more effectively use the existing infrastructure, the fleet of existing equipment; operate on logical nodes, not physical servers. And you can build such a design in your own data center. Then the data will not leave the company, security will be exactly at the level that you yourself are able to provide, but with all the benefits of the cloud will be at your disposal. This is called a private (or private) cloud.
There are scenarios in which critical data is stored in a private cloud, and applications using this data exist in a public cloud. For example, you have data on the cost of your products, including information about the principles of pricing. Obviously, this information constitutes a trade secret. But changes in the price of objects of sale should be reflected in the online catalog. In this case, the catalog itself, which is a list of products and fields for displaying prices, as well as online order forms may exist in an open cloud, since this information is not secret. Price changes can be automatically transferred from a private cloud to a public one. Conversely, completed order forms can be automatically forwarded from a public cloud to a private cloud in order to provide better protection for customers' personal data. Such a “symbiosis” of private and public clouds is called a “hybrid cloud”.
There are both open and proprietary solutions for building private and hybrid clouds. However, the problem of the latter is that they, in most cases, are developed by companies that may become hostages of the “sanctions war”. In other words, there are no guarantees that the next round of sanctions will not close client companies access to updates and support services of cloud solution providers. This is probably why more and more attention is paid to open cloud platforms, among which the obvious leader is OpenStack.
You can understand enthusiasts from regions that are trying to “ride the wave” and offer their services to create a cloud to one or another large company. This is their chance to break through to a big market. It is more difficult to understand eminent IT companies offering the same one-day crafts that earned the nickname “Frankenstek”. The client turns out to be misled and in expenses. It harms both the image of companies and the concept of open source. After all, the main advantage of open source for users is the ability to save on the development and implementation of solutions, and for developers - the ability to work together to reduce the time and cost of creating a product. It is this “collective creativity” that allows us to offer a quality product that can compete with the decisions of major vendors for less money.
What is “frankenstek” and how it is dangerous
In the novel Mary Shelley, the scientist Victor Frankenstein creates the living from the inanimate. In our case, everything happens the other way around. The creators of “Frankenstek” turn a living product that can develop and grow - into zombies. Such projects after “birth” are doomed to remain at the same level of development, while the whole OpenStack ecosystem evolves every six months - in accordance with the release cycle.
The developers of “frankenstekov” from all the functionality of OpenStack leave only the one that the customer needs at the moment. Imagine a Rubik's Cube that spins only in one direction and only one facet. An absurd artifact is obtained, is not it?
When a client formulates TK developers, he takes care of solving the tasks that face him here and now, this is normal. It is abnormal when developers overlook the further evolution of the ecosystem whose life activity they use when solving the current client problem.
Meanwhile, as already mentioned, OpenStack changes every six months, new functions appear, old bugs are corrected, opportunities open that did not exist in previous versions of the product. Conversely, some features are no longer supported. This means that after six months, the client may be left with nothing.
To create a “cloud” customer spends substantial funds. If the product is made taking into account the features of the ecosystem, then any company specializing in OpenStack can support it. And support for any software product is required: at least we are talking about the timely installation of upgrades, security updates, training the customer’s employees in working with the product ... Frankenskte is completely dependent on its creator. It is excluded from the process of the evolution of the ecosystem, so that for the introduction of new "chips" from the next release you will need to invest as much money as in the initial installation.
Upstream: the right choice
Once, several active contributors to OpenStack created the Piston company. They decided that they could overtake the developer community and make a proprietary commercial product based on the “vanilla” OpenStack. They understood how the community functions and made an informed choice. The experiment gave negative results, providing the community with an opportunity to make sure that independent “doping”, without taking into account the interests of the majority of participants in the development process, leads to undesirable consequences. The company Piston was on the verge of bankruptcy and was acquired by the IT giant Cisco, “frakenstek” ruined its creator.
Unfortunately, many Russian developers have ignored the experience of overseas colleagues. And continue to engage in amateur, consistently turning a living product into a dead essence, parasitic on the budgets of the customer.
Meanwhile, the customer, most likely, is not alone in the search for solutions to various tasks. This means that products developed for the client can become part of the OpenStack ecosystem. So it will be supported and improved by the whole community. There is, however, a nuance: for this, the development company must have weight in the community in order to interest other players in the project. From a team of 100 engineers, you should not expect a comprehensive examination, support for all components of the ecosystem, the ability to engage in product implementation, customer training, support for both previous and current versions of OpenStack.
However, hundreds of engineers can easily cope with the implementation of a solution developed by one of the “locomotives” of the community. It is easy to determine the composition of the “locomotive depot”. It is enough to open the Stackalytics service.
Once again we will remind that the client, after the implementation of the solution based on OpenStack, as well as any proprietary solution, will require support. For example, you may need to upgrade to new versions of the product. It is desirable that this process be carried out without serious consequences and without additional costs.
A simple example: you made a driver for some proprietary storage. Half a year passes, the time comes to update the system, administrators make an upgrade of the system, and then it turns out that the driver does not work ... And serious money was paid for a lot of money. The reason is that there have been changes in the system core, but nobody thought about the driver. Because the community had no information about its existence, it was made “on the knee” in the process of “finishing” the version of the distributive that was relevant at the time of the project delivery. But you, for sure, are not the only customer of the manufacturer of this stock. And another hundred companies would be happy to have such a driver, and even in working condition. And if it was made by the whole world, then, firstly, for each of the interested companies, it would come out much cheaper, and secondly, the community would take care to make the corresponding CI and test it for any assembly: this scheme is really It works that it is easy to observe everything in the same Stackalytics in the Vendor Drivers section.
To summarize: the average OpenStack user needs a representative in the community. A company that implements, through partnerships with the “locomotive”, can represent the interests of its client. Thus, if a developer adequately assesses his strength and takes care not only of short-term profit, but also of the welfare of his client, he benefits the whole community. And vice versa: if he cares about the welfare of the community, then he will inevitably benefit the client, making his life easier in the future. This is what distinguishes the living and developing OpenStack from the dead, cold and greedy to client money “frankenstek”.
Source: https://habr.com/ru/post/270211/
All Articles