Top Data Challenges in Cloud Application Development
Yes, everyone has a cloud strategy – it might be public, private, or hybrid and it might be just for greenfield applications or part of a lift-and-shift strategy or both. For years, organizations have been flocking to the cloud given the promises of – cost reduction, computing flexibility, and much improved availability of services. The kicker is that there are a number of challenges that can erode many of the benefits associated with the cloud, and it requires proper planning and execution to make the most out of any cloud investment.
The first stumbling block Data. You know the stuff that your cloud apps collect, process analyze and report. While many teams and organizations have adapted application delivery and support models to fit their cloud strategy, it’s often surprising to find that many of these same teams have forgotten about Data. Delivering a service to your users from the cloud necessarily means lots of application instances that will be spun-up, on-demand all over the globe. Correspondingly, you’ll have an explosion in the number of databases that need to be replicated, synchronized, and managed all over the globe that support these application instances. Without a transparent and automated database deployment process to keep your applications and databases in-sync every time there is a change, your team is headed for trouble.
The next major challenge is the cloud application development workflow itself. The cloud mantra is “you build it, you run it,” and it’s common for teams to have invested in a transparent pipeline that includes build automation, continuous integration, and continuous delivery for application code. However, the same isn’t always true for data. Every time there is a database schema or logic change, database code often flows through a completely separate, manual, and opaque deployment process. Unsurprisingly, manual review of database code and custom database deployments performed by-hand by DBAs simply doesn’t scale to the cloud – there are far too many database instances across more environments than can be counted for any type of a manual effort to succeed. To successfully adopt the “you build it, you run it” approach organizations must allow database code to flow through the same transparent, unified, and automated pipeline as application code in order to achieve necessary scale.
The last major issue is software architecture. As cloud adoption has matured, teams have gone from simple infrastructure-as-a-service solutions to platform-as-a-service or even serverless solutions. Architecturally, this has meant a shift away from giant monolithic applications (and databases), to microservices based solutions where a small database or datastore underlies each microservice. This change in software architecture means even more databases to manage. To make matters worse, the variety of database platform in use has exploded. Development teams are now making database choices based on what best support their microservice. That not only means more instances to manage from a database deployment perspective, but also widely diverse of set or more database platforms that must be managed.
To truly get the most value out of a move to the cloud, it’s necessary to recognize and address the data challenges that can quickly erode many of the benefits that made the move a necessity in the first place.