Google this week revealed it is embedding its Gemini generative artificial intelligence (AI) capabilities across the portfolio of databases it provides as part of an effort to reduce the time and effort required to manage increasingly complex IT environments.
Announced at the Google Cloud Next ’24 conference, Google is making it possible to leverage Gemini to both generate code, automate the management of fleets of databases and accelerate migrations from one platform to another.
Andi Gutmans, vice president and general manager of databases at Google Cloud, said rather than requiring IT teams to adopt master generative AI tools that might be made available by each provider of a database, Google is pursuing an approach that enables IT teams to employ a single framework across multiple databases.
In addition, Google is extending AlloyDB, a curated instance of the open source Postgres database it provides, to add support for natural language queries enabled by generative AI.
As the building and deployment of artificial intelligence (AI) applications become more commonplace, there will be a need to reduce the level of cognitive load currently required to manage fleets of databases, said Gutmans. In fact, the management of databases is gradually shifting toward DevOps and platform engineering teams as organizations find themselves building and deploying more data-intensive applications, he added.
It’s not clear at what pace that convergence may be occurring, but as more applications are built that require access to an inference engine to invoke some type of AI capability, it’s clear that most of the existing processes in place to manage databases will not scale. The database administrators and IT service management (ITSM) teams that largely manage databases today will need to work more flexibly with application developers and data science teams to, for example, expose data residing in a database to a large language model (LLM).
At the same time, IT teams will also need to decide to what degree to continue to rely on existing database platforms versus embracing, for example, more modern platforms such as Spanner that is designed to run at higher levels of scale more efficiently, said Gutmans.
Each organization will ultimately need to determine how best to structure IT teams to accomplish that goal, but it only be achieved if the tasks currently used to manage various platforms become more automated.
Of course, there are just as many cultural as technical hurdles that will need to be addressed. Each fiefdom in IT, in addition to having its own nomenclature, has its own culture. It’s all but inevitable some of these teams will clash as workflows and processes evolve. IT leaders will need to spend more time ensuring separation of duties and responsibilities are clearly defined among teams that will need to work more closely together than ever.
It’s not likely the way IT teams are structured will be completely revamped, but the one thing that is for certain is the difference between success and failure going forward will be determined by the level of collaboration that can be achieved and maintained.
