Developer Caveats for Database as a Service
Data management expert Tony Baer doesn’t mince words when it comes to what developers need to do to leverage Database as a Service tools (DBaaS).
While developers may be able to sign up for DBaaS and go it alone, the founder and CEO of dbInsight doesn’t recommend it. “If you’re a developer, partner with somebody who owns the data,” Baer said when The New Stack asked what best practices he recommends. “Don’t consider business analysts your enemy. Don’t consider SQL developers your enemy.”
None of which is to say that developers have to use relational databases, he added, but the best way to decide which database to use is to work with someone who knows the data.
There’s long been a divide between data and developer types, but it wasn’t always so. In the early days of computers, the compute power ran on the same mainframe as the data. It’s been a back-and-forth since then to move data away from the compute power into its own layer, then back again, Baer said. Data has gone from on-premise to the cloud, originally with the trend being to “lift and shift” databases without changing who managed them.
“These are basically database platforms that they were using internally and thought, ‘Now that Amazon has proven there’s a business in renting out compute infrastructure, we know how to manage these databases we have. We have deep technical expertise and resources, we can run this as a service,’” he said.
Now, you’d be hard-pressed to find a database vendor who doesn’t offer DBaaS, he added. In part, we can thank Kubernetes for that, Baer said.
“We’re basically refactoring all of our logic and all of our processes into microservices, and in turn, we’re running them in containers, and we’re orchestrating them with Kubernetes,” he said. “That’s made for a huge revolution in databases, and allows us to really rethink databases.”
Kubernetes is good for building an elastic infrastructure without reinventing the orchestration part of it. Kubernetes also provides a way to make a cloud application or database portable, because orchestration doesn’t have to be reinvented for each cloud provider.
Orchestration is also key to elasticity, which refers to the ability of the cloud to add server capacity to meet demand; as well as data elasticity, which is the ability of data models to be flexible. Elasticity is important with analytics because the workloads tend to be spiky, as opposed to transactions where there’s a more even flow, he said.
APIs are also changing the data landscape, he added.
“With an API, you can have different projections [of] how you view that data,” he said. “It could be a relational, could be a document, it could be a graph. Now, it’s not going to be as performant as, say, a pure engine. But you’re seeing a lot of multimodal databases go that way.”
The cloud and database-as-a-service really frees developers to work faster, Baer surmised.
Developers also have more developer-friendly options, like document databases — such as that offered by MongoDB Atlas.
That allows developers to “grind out” apps quickly, he said, without worrying about typing data. But there is a caveat, he warned: At some point, developers accrue technical debt if the app changes or needs change. It may seem old-fashioned, but relational databases still have a role to play, because they’re still the best way to analyze the data, he said.
That’s yet another reason to consult with the data owners before coding.
Another consideration before handing over that credit card to DBaaS providers: Know what services are offered by the various cloud providers.
“You may want to look at what types of services are offered in a cloud — in addition to the database — because you may want to take advantage of some of their dataflow services, you may want to take advantage of some of their machine learning services, maybe even their Kubernetes services,” Baer said. “Increasingly, choosing a cloud is like is like choosing an ERP system: You’re looking at what are the other services that you want to take advantage of.”