Companies want better software. Developers want to work on cool stuff. All this relies on data. But what happens to the data when you go cloud-native?
According to O’Reilly, around 75 percent of companies have adopted microservices – some (28 percent of the total) have had this approach in place for more than three years, while roughly half have adopted microservices in the past three years. That leaves roughly a quarter with no microservices adoption at all.
Behind this move are several drivers. It could be the need to break down monolithic applications into more manageable chunks, the desire to deliver more innovative services at speed, or the pressure to deal with rapid and unpredictable growth. It could be a mix of all three, exacerbated by Covid. Whatever the reasons behind this, microservices forces some big changes on how your developers work and the kinds of infrastructure they choose.
The long term challenge around microservices is how to optimise your tech stack. This should help you get the most out of the apps you build and the data that you create.
The role of cloud According to Carrie Fisher, George Lucas’ most common directing advice on Star Wars Episode IV was “Faster! More intense!” The move to the cloud is similar. Cloud can help you develop your microservices deployments more efficiently and cope with peaks in demand levels, but it is not the only element you have to consider.
As part of their microservices approach, developers like containers for the ease of deployment and the independence that they promise. Tools like Kubernetes can orchestrate your container deployments and help them run across multiple locations and cloud services. In theory, this should help prevent lock-in to any particular provider by portability. However, it’s not as simple as being able to run your application on any cloud.
How you manage data over time will be just as important. As your microservices app components carry out any interactions or process customer requests, they create data that has to be sorted, stored and used for other application purposes too. This role would normally be filled by a database of some description.
To make this process easier for your developers, look at how you can make your data approach as ‘cloud-native” as possible alongside your application. The development of Kubernetes Operators for databases can help in this, as this can automate some of the management processes involved on the infrastructure side. Similarly, looking at Database-as-a-Service (DBaaS) options can help too – rather than having your developers create and run their own database instances, you can use DBaaS to step in and take care of that infrastructure for you. The aim is to make data more useful to developers, and for that data to be available in faster and more intense ways.
Cloud native everywhere and everything
Ultimately, your goal should be to make your data as flexible as your applications over time. Making your data ‘cloud-native’ should help, as this can turn your data from a set of infrastructure that has to be tended and looked after into something that can be consumed as an API as needed.
Looking ahead, data has to become easier to use, manage and consume. Implementing more self-service options for developers to use data can help them be more productive, as data becomes a service just like the others they are used to working with. Rather than having to implement databases and look at data modelling and support in detail, these areas should be automated and managed in the same way as other services. This is the future of data.
As you standardise on microservices to build your applications, there will be ripple effects across the rest of your infrastructure. Whether you are new to microservices, or an old hand at splitting up applications into smaller components, looking at how these shifts affect your developers’ relationship with data will become more important over time. Making data easier to use at scale will affect everyone, from your developers building new applications to how the business extracts value from that data.
About the Author
Patrick McFadin is the VP of Developer Relations at DataStax, where he leads a team devoted to making users of Apache Cassandra successful. He has also worked as Chief Evangelist for Apache Cassandra and consultant for DataStax, where he helped build some of the largest and most exciting deployments in production. Previous to DataStax, he was Chief Architect at Hobsons and an Oracle DBA/Developer for over 15 years.
Featured image: ©Olgasalt
