For years, software was essentially developed in one way: as a monolith. As the name suggests, this is when you build an application as a single unit in which the user interface and all data code are essentially combined into a lone platform. The design philosophy here involves the idea that an application should not only be responsible for helping a user complete a particular task, but also every step required for the task itself.
This, of course, comes with a number of unfortunate drawbacks. Because the code base for a monolithic database is so enormous, it’s also difficult to manage (and even understand in some cases). This can dramatically slow down the development process for older applications, thus increasing costs as well. Likewise, because everything is so tightly interconnected, it can make the continuous deployment of new features challenging as changes are not isolated. A change to one part of the app will undoubtedly impact others, sometimes in unforeseen ways.
Over the last few years, the microservices architecture has emerged as a viable alternative to this methodology and is one that has been embraced by many. Rather than building an application as a monolith, the software itself is broken down into a series of smaller, loosely coupled and independently deployable services. Therefore, one of the major advantages of microservices becomes a much faster time to market. You can deploy services one-by-one, rather than being forced to wait for all of them to be completed. Likewise, if an individual service goes down, it won’t negatively impact the functionality of the entire program. Troubleshooting microservices is also far easier than troubleshooting a monolith, thus increasing the quality of the product for end users.
Of course, all of this demands the question – what do microservices mean for databases? How do you best use microservices in the database-driven world we’re currently living in? Thankfully, those answers do have straightforward questions – you just need to keep a few key things in mind.
Microservices and Databases: A Relationship Defined
One of the most important things to understand is that even in a microservices architecture, each service will still need some type of persistent storage to function. There will even be some situations where a microservice is acting as a “middle man” for the transition of information from one service to another, although this is hardly the most common application.
Still, a cornerstone of the microservices methodology is the idea that each service should be the owner of its own data.
For the sake of example, consider a web app centered around the management of an e-commerce store that includes separate functions to deal with customers, orders and product services. All of the functionality related to the operation of those services exists in the API and application code in the microservices architecture. This is how developers can push updates to the customer service capabilities of the app without also having to update the other areas as well. Most of the time, this means deploying changes exclusively in the database used by the service you’re trying to update.
Things get decidedly trickier if you also add in additional legacy applications to the conversation that are integrated with and that depend on the microservices architecture. Suddenly, you have multiple databases that you’ll need to update to accommodate for these changes. More than that, you’ll have to do so in a specific order to avoid breaking anything accidentally.
In a larger sense, the database belonging to each microservice must be persistent in order to deploy the necessary changes in the right order. Likewise, you’ll need to assess the database version before you do anything to make sure you have the most updated “picture” from which to work from. Or, to put it another way, you need some type of tool that will allow you to manage database changes AND detect different versions across the various environments you’re working with.
All of this becomes increasingly more complicated if you’re dealing with a large enterprise where these types of changes happen all the time. Here, you’re likely dealing with a separate release team for software dedicated exclusively to managing deployments. These people may or may not fully understand your development culture, thus causing more problems down the road. They may even be managing countless applications at the same time, making it easy for issues like the ones outlined above to fall through the cracks.
This is why a culture that encourages the ability to communicate essential changes – and the order that they need to be made in – is of paramount importance to the development of any successful microservices application these days.
Databases Still Have Their Role to Play
Is it still far easier, more efficient and more cost-effective to develop a microservices application versus a monolithic one? Absolutely. It’s just that because of the critical information that databases contain like metadata, structure and underlying data, a managed approach to database change is still very much a critical part of the application development process.
In other words, all of this is a big part of the reason why database DevOps is so important in the first place. Part of the promise of microservices is your ability to enable continuous delivery in your production environment. Therefore, embracing DevOps for database management is no longer a recommendation for any microservices project. It has essentially become a requirement, for all of the reasons outlined above.
