DataStax developer lead on programming for multi-cloud
The Computer Weekly Developer Network team attended the DataStax UK ‘Developer Day’ event this autumn 2018 to speak to the company’s Veep of developer relations Patrick McFadin.
With DataStax styling itself as a data developer company with an inherent appreciation for the cloud generation, what did (and does) McFadin think we need to keep at font of mind when it comes to programming in the multi-cloud world… and (come to think of it) is this whole data-driven (and indeed cloud-first data-centric) notion of programming really ‘a thing’ or is it all just vendor hype?
CWDN: What’s the big ‘thang’ at DataStax Developer Day events, really?
McFadin: It’s been different at each location. In New York, there was a lot of Cassandra expertise, so the event had to focus on what is next and best practices for getting the most out of the database, whether it’s the open source version or DataStax Enterprise. In Chicago, it was very much aimed at those starting out and learning what Cassandra is.
In London, there was a 50:50 split between those new to Cassandra and those that had experience. However, there was a lot more interest in running multi-cloud environments.
CWDN:: You mention multi-cloud – is this a common theme for you? Is the UK doing things differently to the US and Europe?
McFadin:: Multi-cloud gets interesting because it means you are not tied to a specific cloud vendor, or to your own infrastructure. It helps you avoid lock-in to a specific cloud provider [obviously] when you might want to access other services. For example, Google Cloud Platform has great ML tooling and support. If you are tied into using another public cloud provider, then that might be either off-limits or extremely difficult to add and support.
More platforms can, very often, equal more headaches right?
What I see in the UK – and we had customers presenting on this at DataStax Developer Day – is that firms want to be in control of their cloud strategies, rather than relying on their cloud vendors. One came up to me and said, “We have our own team and a public cloud. We have multiple availability zones. We have multiple data centre locations. But still [in reality] that’s not enough to be sure [for all eventualities].”
The reason for this is that they have millions of customers accessing their services every second. If they are not available, they get complaints. Instantly. We joked about them stress-testing Twitter if a launch does not go well. They have to plan ahead in that way, because it has a material and commercial impact if their apps are not available.
CWDN: So are developers thinking enough about ‘data’ from the get-go when they are building applications — or is their mindset in the wrong order in some way?
McFadin: To be honest, not enough are thinking data first.
Many have this ‘real-time problem’ (where customers will take to social media to complain at the hint of downtime) and they get that this is an issue. For other companies? It’s something that they see coming over the horizon, but they think just moving to the cloud will help.
Scaling up in cloud is easy now. You want microservices? Add more nodes. Bigger storage muscle? Add more nodes. Extra capacity? Add more nodes. But step back and ask what’s happening on the data side – how you are creating and storing that data to make actual use of it? That is not as simple. You can have as much capacity as you like, but if your application is like digital spaghetti and it’s hard to get that data out, it can be really tough to make that data useful. That is a much bigger problem that moving to the cloud alone can’t help you solve.
I see this as the difference between running a database in the cloud — and running a cloud database.
It’s fine to shift a database to a cloud provider if you only want to carry on running in the same way. A cloud database on the other hand, has to be distributed and decentralised.
That is a different problem to solve.
CWDN: What is happening next around all this – and what do developers need to think about?
McFadin: For me, the big challenge that I see affecting all developers in the future is the ‘speed of light.’ You have to get closer to your customers, you have to provide that real-time, right now experience… and you have to look at getting the data that powers all that closer to your customer.
That means getting distributed.
But where does the speed of light come in? You can only get data from one point to another so quickly. You can’t provide a good experience when your data is in one place and your customers are on the other side of the world.
You have to distribute your data. Whether this is using cloud, hybrid, or multi-cloud… it doesn’t matter. It is a big problem to solve because it affects how your customers experience your app. For developers, this is an issue that they have to start thinking about because it covers performance and service.
At that point, I get excited because that is the problem I want to help people solve. [My point of view is obviously one that states] Cassandra is the only database that can deal with that distributed and decentralised approach – the community is going to get really exciting over the next couple of years… and I love being part of that.