Q&A: Why Devs Are at the Forefront of a ‘Revolution in Data’
The database field is full of vendors that seek to make it easier for developers and their teams to run their workloads in cloud native environments.
For example, with the recent release of Aerospike Database 6, data-platform company Aerospike has added developer-friendly features to its database, including native support for JSON document models and JSONPath query support.
The New Stack spoke to Aerospike’s CEO Subbu Iyer after the May 4 virtual Aerospike Summit 2022 about the role developers play in how their organizations handle data and what they should look for when choosing a database. (This interview has been edited for clarity and brevity.)
The New Stack: It’s hard for many organizations to make good use of all the data they’re collecting to improve their business. Presumably, some of that problem will need to be solved in part by data analysts and data scientists. But is there a role for developers in helping to solve this problem — and if so, what is it?
Subbu Iyer: Despite everything we’ve talked about in the world of data, I believe we are probably in the first innings of the data journey across most organizations.
Organizations that started early on this journey are a little more mature in how they addressed this vis-à-vis identifying the data sources that really mattered to them to solve a particular business outcome or set up a new business disruption.
I consider developers to be at the forefront of this revolution with data, not so much from an aspect of data but from an aspect of utilizing data to deliver disruptive outcomes for a business.
Subbu Iyer, CEO of Aerospike.
As a developer, you try to build applications, or you try to build services that leverage disparate data feeds and build out something which was not previously possible — whether it’s a fraud-analytics application in financial services, a customer 360 within a telco or an online e-commerce platform, or building out the recommendations engine within an e-commerce vendor.
It really comes down to established companies building out services and applications that were not possible before by leveraging data — and all this is done by developers.
Data scientists and data engineers do play a huge role, but at the end of the spectrum is an application that is actually driving business value.
What are some of the questions enterprise DevOps teams should be asking before choosing a database?
We see in the world of real-time data and real-time applications that some critical components are really important.
One, does the database provide predictable performance? Does the database platform I’m choosing help support my growth and my aspirations from a scale perspective?
Second, is the database platform going to be highly available? If I’m building a business in mission-critical service on this database, I cannot afford for it to go down. Developers shouldn’t have to care If a node in a distributed database goes down, or a node has to be added to increase scale and capacity. The infrastructure of the database should take care of that.
The third piece for these applications and services is latency. It’s not just important that you’re able to drive tremendous throughput but that you can deliver low latency — and both affect customer experience and application performance.
The other aspect to consider is can all of that happen at an affordable cost? That is where a lot of folks actually stumble. They start their journey really well, but then they find themselves in this battle where revenue is going up nicely, but their cost curve is on a hockey stick and that becomes a huge challenge for them.
What role should application developers play when their organization chooses a database and when it’s being customized to their organization’s needs?
I think developers have to have a pretty strong voice and a seat at the table.
To be a good developer, you have not just to deliver what you’re working on today, but you’re constantly trying to learn what’s around the corner — what’s the new technology that is coming out.
I think developers are making some of the most important decisions in organizations. Across the board, whether it’s DevOps tool chaining or whether it is really leveraging data and building out new services, developers are the ones who are showing companies and organizations what the art of possible is and driving the next wave of disruption within organizations. So they should have a stake early on.
The developers and applications teams need to be involved because they are the ones who have to deliver.
How does multicloud or hybrid architecture complicate things for developers who need to work with databases? What do you see as some of the most promising ways of tackling these challenges?
In today’s world, sometimes a cloud is fit for a particular service, and another cloud may be fit for another service, and you may really have a microservices-based architecture that leverages multiple cloud platforms. Even if you’re not going to do that, I think most organizations want to leverage a multicloud platform.
The decision developers have to make, especially in the choice of databases, is, do I build my service on a database that is only available on a particular cloud, and what would it take for me to actually move my service over to another cloud?
You want to look for databases that are multicloud so that it makes the developers’ lives really easy because they’re spending their time working on the service or application they’re trying to build. The database layer is essentially the same — you build once, and you’re just deploying it on another cloud platform because the database is already available on that particular platform.
It’s relevant for any choice of infrastructure that you decide to build your service on. You want to make sure it is available on a multicloud architecture.
What have you found to be the biggest pain points for enterprise developers in working with databases?
What we see out there is developers struggle when databases don’t meet their needs. They start the journey and then they hit a wall at some point in time and they’re left with a choice — which is, do I try to really make this work and spend a lot of cycles with my operations teams to actually continue my journey on this particular database platform, or should I switch?
Most often they do switch, but that’s a very expensive and painful transition for the organization, not just the development team.
You can actually have a single database support multiple models. A concrete example would be in Aerospike Database 6, we actually now natively support JSON documents.
We intentionally built out support for native JSON and JSONPath query because we saw that customers were saying, “If you were to do this, we could actually use your database across multiple workloads at particular applications, and it makes our lives really easy as developers.”
That’s really our vision, to build the Aerospike Database and the data platform to support multiple models because the customers are driving us there
