Issue link: https://resources.awscloud.com/i/1496553
©2020 IDC #US46773920 2 are in common use, such as those of open source DBMSs, both for relational data access (SQL) and other types of access, such as key value. Adopting databases with such APIs should make the task of finding developers to build and maintain database applications easier because knowledge of such APIs is pervasive. This yields greater flexibility from a staffing perspective. New Data Optimization Opportunities For the most part, the incumbent DBMSs that are most commonly used by enterprises on premises have been designed to serve two classes of use cases: online transaction processing and business intelligence analytics. New classes of applications are emerging, however, that require database support. These include "edge data"-focused customer experience applications, deep and recursive data analysis that is not well served by SQL, support for artificial intelligence (AI) and machine learning (ML), complex relationship analysis using data graphs, and streaming data capture and real-time event handling. Such new workloads require purpose-built databases that feature better scalability and performance while supporting a more agile development process. In some cases, these workloads are best served by specialized data management systems such as document, memory-optimized, key value, graph, and other database technologies that provide data management beyond the relational paradigm. But acquiring such technologies from different vendors and knitting them together can be problematic, creating complex integration projects in the short term and complicated maintenance challenges in the long term. Many enterprises are looking to rewrite their applications to embrace an API-driven microservices architecture, which also puts extra pressure on the database to perform and operate in a highly distributed manner that the incumbent system may not be able to manage. Limitations of Traditional Data Management Licensing and Deployment The large incumbents not only are centered on established database technology but also tend to offer two choices: either run in the traditional manner in your own datacenter or run in their cloud. The on-premises version tends to be offered under a perpetual use license and maintenance agreement that requires a significant up-front expense and continual increases in fees as your use of the metered resource (usually CPU) increases. In some cases, this agreement is enforced using periodic invasive audits meant to ensure that you are complying with the terms of the agreement. The cloud version comes under a subscription but runs best only on that vendor's cloud platform. This means the user is put in the position of needing to put all database applications on the vendor's cloud or find a way to connect the applications to the database, which is technically problematic. A DBMS vendor's cloud platform tends to lack the breadth of features offered by the three main cloud platform vendors, so the user must often locate some applications on that platform and others on a major cloud platform and coordinate them somehow. Breaking Down the Boundaries in Data Management A better approach may be to start by committing to one of the major cloud platforms and then building on it. One could do this by selecting a variety of products from different vendors or from open source, each offering the specialized functionality required and integrating them, but this approach leads to operational complexity. Each vendor tends to take an approach that works well within the domain of the database in question but does not necessarily support the integration of data and applications for other database systems. This lack of interoperability leads to frustrating boundaries in data management. Another route would be to examine the database technology offered by the cloud platform provider. Such technology should be easier to integrate and produces a simpler vendor relationship.