As microservices-based development becomes more common, many developers are asking what is a microservice and what does it mean to my role as a database professional? In this three-part blog series, we’ll explore what microservices are and how they differ from traditional architectures, along with performance considerations for microservices deployed in infrastructure-as-a-service (IaaS), database-as-a-service (DBaaS) and platform-as-a-service (PaaS) environments.
What is a microservice?
So, what is a microservice? There are many definitions; however, I like to think of it as a number of independent services that can interact with each other in kind of a federalist model. They are loosely coupled, but they can be managed, maintained, tested and deployed somewhat independently of each other. They tend to be based on specific business capabilities or application functionality areas.
From a database perspective, the way the data store is used and interacts with the application can be very different from traditional application architectures. A common pattern in microservices is for each service to be built on its own database or data store. This is actually quite different from the way applications have been built with relational databases. In a traditional application architecture, an application is typically built on a single database with tables, queries, procedures and triggers used to manage, manipulate and orchestrate processes around the data.
In this traditional development pattern, business logic and manipulation of data elements were accomplished using stored procedures within the database. There are many pros/cons to doing this, and we won’t get into those in this blog, however, this model creates challenges when it comes to application upgrades and changes. With heavy reliance on stored procedures built into the database, any changes made to the application or UI often required the stored procedures to be rebuilt or rewritten as part of an upgrade.
Creating business logic
Furthermore, because of these stored procedures in the database, developers had to create business logic in two different layers – the application and the database. To simplify this, developers began to place more emphasis and focus on building business logic in the application layer rather than in the database, but they couldn’t be fully disconnected. Even with removing business logic from the database, there are still many tables that maintain relationships with each other. Because of these interdependencies within the relational database model, QA becomes absolutely critical since changes in one part of the application might introduce regressions somewhere completely unrelated. This becomes unavoidable as application functionality grows over time and the application relies on a single database platform, and it’s exacerbated for a high transaction volume application.
In response to this challenge, development patterns are changing and many application teams are building applications using microservices-based architecture. With this method, each service is independent and is loosely coupled with other services. That loose coupling is accomplished through Application Programming Interfaces (APIs) that provide a handshake between the services. This means that each service is fairly independent, allowing for separate releases for each service without introducing regression issues for others. This model can be very advantageous from a QA perspective, and it allows for more frequent release cadences for individual services. It creates somewhat of a federalist model for application development where each service can survive and thrive on its own due to its loose coupling with other services.
A unique architecture
As we further explore what a microservice is, a distinguishing aspect is that each service is built on top of its own database. Where traditional architectures might have a single application with multiple services running on a single database, each microservice runs on its own separate database. While this microservice database may have interrelated tables, it’s at a significantly smaller scale than a traditionally architected application.
Architecting with each service having its own database also removes many interdependencies between functionalities, thereby allowing each service to be developed independently. Application interaction with the database is done through APIs as well, so most business logic lives in the application and not in the database. Any kind of procedural language logic affects only that particular microservice and won’t have an impact on any other microservice within the application landscape.
This model of development tends to correlate with newer, cloud-native applications, but the concept of microservices is not exclusive to cloud-based deployments. However, given that most deployments of microservices architectures are in the cloud, there are several different deployment patterns to consider.
With IaaS, each service is deployed on its own database and interacts with other services using APIs. In this model, a common development approach is to incorporate containers and orchestrate these applications using Kubernetes to provide more control over the application while enabling scaling.
When using DBaaS platforms like AWS RDS, AWS Aurora, Azure SQL DB, Azure Cosmos, etc., many of the routine activities associated with database upgrades, patching and backups are taken care of by the DBaaS offering directly.
Next steps
If you are a DBA or a DevOps Engineer transitioning to working on applications that are built using microservices, consider this. While this structure unburdens us from the dependencies between tables, functionality, etc., within a single application on a single database, it creates new challenges when administering these types of applications. In this blog, we answered the question, “what is a microservice.” In parts 2 and 3 of this blog series, we’ll look at some of the challenges and considerations when monitoring performance for microservices-based applications.
