How Data Gateways Simplify Developers’ Lives

According to research by SlashData and the Cloud Native Computing Foundation, there are around 6.8 million developers working with cloud native technologies, which equates to around 41 percent of all back-end developers today. They’re keen to use new approaches like containers and Kubernetes, as they can move faster and implement their applications quickly.

Data is quickly becoming more and more critical to these applications. But developers want to spend less time installing and managing databases; they prefer to have these instances managed by others. According to Gartner, spending on cloud database management systems (DBMS) will be 50% of the total database market by 2022.

Why is this shift taking place? Developers want to concentrate on what they do best: building applications; and they want to reduce tasks that pull them away from development.

Another example of this shift is the trend of teams creating their own API layers (known as data gateways) that sit between application code and databases. Data gateways make it easier for developers to work with data, without getting bogged down in the details of managing schema, data migrations, and other database administration tasks.

SEE ALSO: Modern Data Warehouse Benefits Outweigh the Financial Cost

How data gateways work in practice

To learn more about data gateways, let’s consider the reasons why developers create these abstractions. One common use case is to mask changes to the underlying database over time.

For example, consider the changes that occurred when the Apache Cassandra® project changed its primary interface from Thrift to Cassandra Query Language (CQL). This change represented a major upheaval for developers that had built multiple applications or microservices on the Thrift API. Some of these teams elected to introduce abstractions that implemented the Thrift API, translated incoming Thrift messages into CQL invocations on Cassandra, and returned the results as Thrift messages. This approach preserved the previous investment in application development, at the cost of maintaining abstraction layers over time.

These abstraction layers provide a level of self-protection for developers: by using a utility or tool that meets their needs, they can avoid some of the infrastructure management problems and pitfalls that would otherwise arise. However, these layers need to be supported over time to avoid technical debt building up. They also should be evaluated alongside new approaches to avoid any sunk cost fallacies that might affect project roadmap decisions, and the opportunity cost associated with failing to adopt new features that could improve performance or reduce cost.

Generalized API data gateways are now emerging to provide a more uniform approach to abstracting database infrastructure. Rather than internally developed and managed software, external open source projects are proving easier to adopt and use over time. These projects enable a second common use case, which is potentially even more valuable than the “self-protection” approach described above: enabling rapid development of applications that support massive scale.

How Stargate’s APIs simplify development

As an example, the open source project Stargate makes it easier to deploy Cassandra databases and interact with data using developer-friendly APIs. Instead of being forced to invest in learning yet another database-specific query language, developers can use APIs that they are familiar with, such as GraphQL, REST, gRPC, or JSON documents.

While some developers have deep experience with open source databases and are able to work with a variety of different schemas, others will not have that same level of expertise. This can make it hard to create and adapt schemas that will promote high performance at scale. One aspect of Stargate that is especially intriguing is its flexible approach to managing schema. Stargate provides APIs that support both “schema-first” and “API-first” approaches. For example, the Stargate Document API completely abstracts the underlying CQL of the Cassandra database, providing a schemaless “API first” approach for storing JSON documents.

As another example, the Stargate GraphQL API supports two different types of schema-first development. The “CQL-first” approach allows access to existing Cassandra tables defined via CQL. This requires familiarity with how the database works. Once the database is up and running and the schema defined, the data gateway can plug into this and then serve up data through the GraphQL API.

Alternatively, when the developer team just wants their database instance up and running, the data gateway can handle this process for them—without requiring them to know the best approach to the underlying database schema in that particular situation. This “GraphQL first” approach defines a standard set of API queries based on a simple GraphQL schema provided by the developer, and then the data gateway automatically works on how best to deploy the database and create the underlying CQL schema to implement the developer’s intent.

Regardless of skill and experience levels across the team, the data gateway can simplify the process of schema creation and ongoing management to ensure a consistent approach. In turn, this results in more efficient queries, improving performance for the whole application.

Data gateways: Value, scale, and speed

Businesses are using more and more data in their operations in order to meet customer expectations, so developers will continue to need to learn new skills to build data-intensive applications. Developers can meet these expectations and execute with speed by thinking more in terms of data services, as opposed to traditional databases. Using a data service via an API is easier than specifically developing for one database or another. Instead, the service should provide the information that the application needs, on-demand.

The data gateway abstracts database infrastructure; it interacts with the database to carry out requests, and then presents that information back to the app. Using an open source data gateway rather than designing new abstraction layers for each application reduces time to market and management overhead for the team.

By combining a data gateway with APIs and cloud native computing, developers can automate the majority of their data infrastructure. This can make scaling up and down in response to demand easier and faster compared to traditional approaches. With more and more applications going cloud native, data gateways are becoming an essential part of how developers achieve value and scale quickly.

DataStax Astra DB, a DBaaS built on Cassandra, includes the open-source data API layer Stargate. Learn more.

The post How Data Gateways Simplify Developers’ Lives appeared first on JAXenter.