Modern development - DataStax: The importance of the ‘why’ factor
This Computer Weekly Developer Network series is devoted to examining the leading trends that go towards defining the shape of modern software application development.
As we have initially discussed here, with so many new platform-level changes now playing out across the technology landscape, how should we think about the cloud-native, open-compliant, mobile-first, Agile-enriched, AI-fuelled, bot-filled world of coding and how do these forces now come together to create the new world of modern programming?
This contribution comes from Patrick McFadin in his role as developer relations lead at cloud data management company DataStax.
McFadin writes as follows…
Looking at modern software development processes should be a great opportunity to go into all the cool new ways we have of writing code, of being productive and of delivering results faster. However, the past few weeks have made me question everything with one word: “Why?”
Like a five-year-old who just wants to know things, this approach got me thinking about the heart of a lot of what we assume today.
Don’t worry, no conspiracy theories or crisis of thought here. Instead, I’m going to ask why about that initial phrase. Why do we need more modern software development processes? Each word in this phrase does its own heavy lifting.
What’s actually new in application development?
Why modern? What’s new about software right now?
A lot of what we call ‘modern’ just means cloud… and that often means whatever services the cloud providers make available to us. We can piece these services together and create beautiful applications from the digital equivalent of Lego.
Everyone wants to be a master builder, right?
What’s missing is whether we are making the right choices in the first place around these cloud-native applications. Ideally, we want to make these applications as simple as possible to put together and eliminate the potential trade-offs that we might have faced in the past.
Making it easier to use things that were previously difficult is a massive part of what drives the software industry today: it covers tools like Kubernetes, which make it easier to deploy microservices and containers; it covers managed Kubernetes services that hide some of the complexity that exists; it covers the use of automation and cloud to deliver things like Databases-as-a-Service, based on automation and recommendations to make it easier to manage complex set-ups.
Cloud-native apps will need cloud-native developers
We have to consider the modern software process and how we develop for a world when open source, APIs and containerisation are at the forefront.
Traditionally, we develop for new features – adding more functionality to meet specific needs or fill gaps in the product. However, now we have to think about how to keep that same speed of development in place but add more resilience as well.
The goal for microservices is to make the overall application easier to update, but the ability to switch in new application components can make this less of an issue.
Instead, making applications more resilient and able to scale will be important over time. This cloud-native approach will involve reducing the complexity that currently exists, so that more applications can be built, faster.
As this evolves, the aim should be to make modern software development practices easier, so that the back-end infrastructure effectively disappears for the developer. Rather than having to understand the challenges and requirements of data schemas – or indeed having to know why specific databases are required to meet a challenge – the aim is to make data easier to use at scale as part of these applications. Rather than specific database skills, cloud-native data will be about making the best use of APIs and persistent data services to meet a goal.
At present, we have to know the workings of the tools that we use, even as they become easier to use. While cloud services and cloud-native data options make the scale side easier, we still have to know our theory and our options.
Over time, this will change. Rather than thinking about specific requirements, we can move to thinking about services instead. As developers become more cloud-native themselves, we can start to change our thinking about why we take the approaches that we have learned in the past.
We can bring together cloud-native services and cloud native data in order to make the whole job easier.
McFadin: If you don’t ask why, then how can you start on the what?