Database, as the basic software of IT system, plays a very great role. So what are some of the ways in which an enterprise can choose to use a database? What are the characteristics of different ways? This paper will analyze twelve situations (the first six are local and the last six are cloud-based) from the perspectives of usage mode, application scenario, future development, cost factors (human resources, finance, time) and risk points.
Approach 1: business database + business services
That’s the traditional way. Enterprises purchase large business database software, and corresponding purchase service support work. In the last 30 or 40 years, this has been the dominant mode of use. It can also be said that all kinds of enterprises to meet the rapid development. However, with the change of Internet in the past two decades, this approach has had a great impact.
This approach is suitable for traditional enterprises, which have high requirements on database, limited technical capabilities, and relatively fixed future development. Future development will change with the development of commercial database. In general, future cloud demand will have a great impact on it. In addition, under the requirements of localization and autonomy and controllability, this mode will also be greatly affected.
From the perspective of human cost, the overall investment is not big, mainly provided by the manufacturer. Own personnel is mainly to complete the audit, evaluation and other work. From the financial cost analysis, is several programs, relatively the highest one. Often see “a state-owned bank, the annual database procurement XXXX million news” in the press.
Due to the large financial input, this approach is generally limited to large and medium-sized enterprises or some special industry requirements. The time cost is relatively small. Choose commercial database + service, that is to value its product development technology accumulation and mature commercial delivery ability. Whether product maturity, stability; Or service support aspects, generally can be delivered in a relatively short time.
- Technical risk: closed and closed technology; It does not meet the requirements of autonomous control.
- Political risk: such foreign products are also susceptible to the political environment.
- Financial risk: easy to be kidnapped by manufacturers, economic investment is not controllable.
- Personnel risk: it is greatly affected by the technical ability level of technical personnel of the manufacturer, and its own personnel cannot afford it and cannot grow for a long time.
- Functional risks: mature commercial products are difficult to be customized to meet customers’ individual needs; There is also the risk of integration with other components.
- Transition risk: after adopting one commercial product, it is difficult to transform other products.
- Commercial products, including domestic database and emerging database manufacturers. As a good supplement to commercial products, these two schemes have advantages in comprehensive cost, but they still need to be further strengthened in product functions and service capabilities. After all, similar to foreign commercial products and services, has been 40 or 50 years of accumulation.
- Commercial services, in addition to original services, also include third party services supporting companies. In the latter choice, for foreign and domestic manufacturers, the difference is still relatively large. Recently, I have seen the cooperation between domestic database manufacturers and third-party service companies, with many actions (including training, certification, delivery, etc.).
Mode 2: commercial database + autonomous service
This approach is also common. In the former approach, as the enterprise USES commercial software more and more, the need for its own services becomes urgent. By establishing its own service system, the enterprise can better meet its own needs. This way, suitable for a certain amount of technology accumulation of traditional enterprises. The future development changes with the development of the commercial database, the overall relatively stable.
From the perspective of labor cost, it has more input than the former. Commercial database product promotion for many years, the number of relevant talents is large, so it is generally easy to recruit needed talents, and often the price is not too high. This is in stark contrast to the later open-source software. Financial cost input is still relatively large, and the purchase cost of commercial software accounts for the majority of the total.
Look from time cost, compare former somewhat increase, but overall still slant little. This is mainly because of the mature ecology of the commercial database, which is easy to build the delivery, operation and maintenance system. And talent, it is easier to supplement.
In terms of risk, it is similar. In terms of technical risks, there is still a gap in the control of commercial products by its own personnel compared with the original factory. Of course, the risk of corresponding personnel will be reduced, and the ability to control the product through its own personnel will be greater.
In some key core areas, original support is still recommended to reduce technical risks.
Approach 3: open source database + commercial services
With the increasing maturity of open source databases, more and more enterprises begin to use open source databases. However, compared with commercial databases, open source solutions have higher requirements on enterprises’ own technical capabilities. As a result, many companies considering jumping on the open source bandwagon have taken this approach. Suitable for enterprises in transition, from commercial to open source, this approach can be somewhat risk-averse. But it is transitional stage commonly, still want to cultivate the service ability that the enterprise has in the long run.
In terms of labor cost, it is in the middle level. Compared with business services, its comprehensive labor cost has been reduced. The financial cost input is generally moderate, but the service providers differ greatly. Time cost input is less, but compared with business solutions, enterprises need to do more technical investigation on business services. Therefore, more time is needed in the initial evaluation stage.
- Technical risk: open source database itself technical risk, enterprise technology selection risk and business service capacity risk.
- Personnel risk: it is greatly affected by the technical ability level of the technical personnel of the manufacturer, which needs careful evaluation.
- Functional risk: in general, open source databases still lack functionality compared to commercial databases. So this part needs to be evaluated carefully.
Different from commercial services, there are different capabilities and no uniform standards for open source services. Some open source databases are commercially supported in the so-called “original” category, but they are not well received at home.
Approach 4: open source database + autonomous services
This is typical “Internet” play, but also a more common way. Suitable for large scale, enterprise customization requirements of the scene. When you’re mature, consider moving to an in-house private cloud or database product, solution, or even external enablement.
The labor cost of this way is relatively high, but according to the scale of enterprise use, the difficulty of great difference. The development of open source database has also gone through a period of time, and the number of talents in the market has gradually increased. But for the high-end talent, is still relatively scarce, talent cost is also high. Financial aspect, also basically show on manpower cost.
In addition, there is a need to invest in infrastructure, perhaps even more than the commercial solution. Time cost is high, enterprises to establish a mature open source database operation and maintenance system, is the need for a certain amount of time accumulation.
Risk analysis is similar to the above one, highlighting personnel risks and requiring long-term training investment.
Approach 5: open source custom database + commercial services
This is a special case of plan 3. Instead of using native open source products, companies use custom open source solutions from third parties, either pure software or a combination of hardware and software. This kind of approach will be tailored to the shortcomings of open source software, to meet the needs of enterprise software.
However, in this way, enterprises generally cannot operate and maintain independently and need the commercial support of third-party companies. There are higher requirements for the enterprise-level features of the database, but the native open source database can not meet the situation. This is ideal for a short period of time when you need to remove a business database. With the continuous deepening of the use of open source database in China, there are more and more such start-ups. Very optimistic about the future development of this model.
Labor costs, mainly from third-party services, are generally not high. Financial cost, mainly depends on the scheme, the difference is large. Time cost, can regard as pure business plan.
- Technical risks: the customized part is not open, and the enterprise cannot control it; In addition, native open source version changes may not be applicable to the solution in the short term
- Personnel risk: it is greatly affected by the technical ability level of the technical personnel of the manufacturer, which needs careful evaluation.
- Transformation risk: limited by the scheme, there are some transformation risks.
Mode 6: private cloud + cloud service
The final enterprise privatization deployment is a cloud-based compromise. Due to some special conditions, some enterprises cannot directly use the public cloud, but they need the platform capability similar to the public cloud. Therefore, some cloud vendors or database vendors offer a private cloud-based deployment solution. It can be understood simply as moving clouds home.
There used to be a saying that private clouds would shrink and public clouds would rule. However, judging from the development of domestic cloud market in the past two years, the development speed of private cloud is even faster than that of public cloud in some indicators. While we now talk about the “toB” market as the next blue ocean, this model is also an important part of the toB services market. This way, suitable for large enterprises, long-term optimistic.
From the perspective of cost, labor cost input is not big, mainly depends on the manufacturer’s personnel input. In terms of financial resources, although there are some cost advantages over large commercial solutions, the advantages are not obvious. In terms of time cost, it is also longer than the traditional solution. After all, this is not the replacement of a single technology platform, but involves Iaas, Paas and other levels.
Its risk point besides in financial aspect, more is considered in the technical dependence to the manufacturer. This approach is even more dependent than traditional solutions. Vendors generally provide a good private cloud, and corresponding to their own public cloud open scheme; But for other public cloud or enterprise own platform, it is more difficult to get through.
Mode 7: naked cloud + open source database + independent services
This is an early stage of cloud adoption, with the enterprise using only the Iaas portion of the cloud and building the rest itself. This approach can make full use of the elastic advantages brought by the public cloud and extend the enterprise’s original technology accumulation to the cloud. This approach is also the most “smooth” for the enterprise, and even applications can use public cloud resources just as they use internal IT resources. Suitable for cloudy, cross – cloud needs. However, the disadvantage is the inability to take advantage of the added value brought by the technical capabilities of cloud vendors.
From the perspective of cost, the enterprise can achieve “optimal”. Under the condition of only using bare-metal machine, it is completely possible to optimize the selection according to the strategy of “getting the lower price”. In a certain scale, the public cloud still has its price advantage, and can also make full use of elastic capacity, dynamic reduction, according to the enterprise development at any time to adjust IT investment. In terms of personnel, there is little change with the independent operation and maintenance of the enterprise. In terms of time, due to the improvement of the underlying delivery speed, there is still some improvement.
There is little risk, just a reliance on the public cloud infrastructure, and easy migration to other cloud vendors or back to ownership.
Mode 8: naked cloud + commercial database + third-party services/autonomous services
This is a special case. The enterprise chooses to build the business database on the public cloud. But it did not choose the cloud vendor to provide, but independent construction or choose a third party vendor to help complete. These tend to be small and medium-sized enterprises that are not large enough to support privatization deployments and applications that rely on commercial database products. Enterprises want to take full advantage of the elasticity of the cloud, so combine this usage.
Financial costs, mainly for the infrastructure level, will be less than self-built. Manpower, time respect, difference is not big.
The risk is that some commercial databases are not supported for cloud scenarios and the enterprise has some technical risks. Either has the stronger independent technical ability, or relies on the third party service provider.
Mode 9: cloud database (open source) + cloud platform services
This is the most “traditional” database service launched by cloud vendors, and is currently the most popular choice. Cloud vendors build their database products based on the open source database version plus their own platform services. Its core database and the open source version, is exactly the same, each competition is more platform service capabilities. This approach has very low requirements for enterprise operation and maintenance, and can basically rely on the capabilities provided by cloud vendors (except for individual high availability and disaster recovery requirements). This scheme is more suitable for the initial cloud enterprises, can gradually explore the difference between the cloud and the original way.
In terms of financial cost, there are undoubtedly advantages compared with commercial solutions, but there are almost no advantages compared with independent open source. It is more in the rapid delivery, expansion and shrinkage of capacity and other aspects of the product characteristics. In addition, as for the labor cost, the operation and maintenance work is greatly reduced, so it can save a certain amount of labor and reduce the size of its own personnel. Time costs have also risen.
The database itself is not very risky, after all, it USES the same version as open source and is technically portable to other cloud vendors. When the database version upgrade, also can enjoy the corresponding technical dividend. However, there is a certain dependence on platform services, different capabilities, need to have a process of adaptation. In addition, operation and maintenance rely on cloud vendors, there are some technical risks. Autonomous technical ability, will gradually lose.
Mode 10: cloud database (open source customization) + cloud platform services
In addition to the open source version, cloud vendors typically offer proprietary custom versions. It is often a deep customization based on a version of an open source database, with enhancements for certain features. Some, of course, feed back to open source in the form of feedback to the community (which may be merged into a new version in the future), but many exist only in “cloud private DB”. If the enterprise has strong requirements for a particular scenario (e.g., seckilling) or other aspects (e.g., finance-level data synchronization), it may consider using this solution. when
However, using it also means deep binding with cloud vendors. Also, in terms of platform services, the situation is similar. This approach is suitable for situations where there are requirements for the database and the native open source version does not support it.
Similar to the previous approach.
The risk is to bind a single vendor, generally difficult to come down. This is similar to using a large commercial database. Of course, you can design on the application side to minimize feature dependencies. In addition, because it is a customized version, future updates to the open source version may not be supported anytime soon, and may not even be considered for support, leading to a completely separate branch. In view of this, the enterprise also needs to pay attention.
Mode 11: cloud native database (self-developed) + cloud platform service
Some big cloud vendors, in addition to the above two, can through self-research database way, increase the future product competitiveness. According to the latest Gather report, more cloud vendors are joining in, which also brings vitality to the overall database market. From the perspective of prediction, we are all optimistic about the future development of cloud native database. Compared with the first two approaches, this kind of database is born in the cloud, and it takes into account the characteristics of cloud environment from the beginning of design, so it is very competitive.
Of course, from the current point of view, the existing cloud native is still in the “primary” stage, in the future after solving the larger scale of scalability, more read more write ability, and so on, it will really enter a spurt of development. Existing each big factory, in this one domain in succession key layout, increase investment. For enterprises, there is undoubtedly another option, especially in some scenarios (such as mass data), which cannot be satisfied by native open source or extended open source products.
At present, all factories are sparing no effort to promote, so from the cost of the enterprise can benefit; But in the long run, further observations are needed. In terms of personnel, enterprises also need some investment, after all, this is a brand new database, although the cloud manufacturers provide a good platform for interaction, but still need enterprises to do a certain amount of technology reserves, so personnel still need some investment. In terms of time, more testing and evaluation work needs to be done for this relatively new product, so more investment is needed.
The risks are similar, or even past. Enterprise applications will be completely dependent on vendor products. Although many are advertised as compatible with open source or commercial databases, they are not the same product. This also needs to be carefully assessed. In addition, for compatibility, backup recovery, high availability, data synchronization, cross-cloud disaster tolerance, etc., are worth investing in research.
Method 12: cloud database (self-research) + cloud service + cloud hosting platform
This is a kind of niche solution, the background is originated from the database vendor and cloud vendor cake partition problem. Some database vendors (such as MongoDB) do not want the cloud database market to be dominated by cloud vendors, but want to be dominated by themselves and build an independent ecosystem independent of cloud vendors. At present this kind of way domestic see not much, here temporarily do not comment.
Author: han feng
First published in the author’s personal public number “hanfeng channel”, welcome to follow.
Source: creditease institute of technology