Microservice databases with mu
mu is a tool that makes it simple and cost-efficient for developers to use AWS as the platform for running their microservices. In this third post of the blog series focused on the mu tool, we will use mu to manage microservice databases in the pipeline we built in the first post.
Why should my microservice manage the database?
As discussed in prior posts, adopting a microservice architecture can increase a team’s ability to deliver software faster through decoupling and team autonomy. By decomposing an application into microservices and then giving teams complete ownership of their microservices, the teams can then make decisions and implement changes independent of other teams and their microservices.
Unless the same approach is taken to decompose the databases that support the microservices, the benefits of microservices will be limited by the cross team dependencies on shared databases. When your microservices share a database then in effect you’ve used the database as an API between the services. This type of architecture causes tight coupling between services and likely will require regression testing and even deployment of multiple services at the same time.
Martin Fowler, in his post titled Microservices, says “Microservices prefer letting each service manage its own database.” By decomposing all the way down into the database you can realize the benefits of agility that microservices has to offer.
Let mu help!
The continuous delivery pipeline that mu creates for your microservice can manage the provisioning of a database. Additionally, the details about the database can be injected into your service as environment variables.
Let’s demonstrate this by adding a database to the microservice pipeline we created in the first post for the banana service.
Define the database
Previously, the banana service was using an embedded H2 database. This won’t work in a production environment so we need an RDS database instance that the microservice can use. Adding a database for a service with mu is as simple as adding a couple lines to your mu.yml file:
service: name: banana-service port: 8080 pathPatterns: - /bananas database: name: banana
By default, this will create an RDS database instance of size db.t2.small with the aurora engine. Next we need to reference the database from our microservice. We can pass the database URL and credentials via environment variables:
service: name: banana-service port: 8080 pathPatterns: - /bananas database: name: banana environment: SPRING_DATASOURCE_USERNAME: ${DatabaseMasterUsername} SPRING_DATASOURCE_PASSWORD: ${DatabaseMasterPassword} SPRING_DATASOURCE_URL: jdbc:mysql://${DatabaseEndpointAddress}:${DatabaseEndpointPort}/${DatabaseName}
This approach does have the disadvantage of passing database credentials as environment variables. This presents a security issue as any IAM user/role with access to ECS task API would be able to discover the credentials.
AWS has recently announced IAM database authentication that can be utilized to obtain temporary database credentials from the microservice via an AWS API call. Although we will save the details for a future blog post, for now it’s worth mentioning that mu can configure the database for IAM database authentication to work around this issue of passing credentials as environment variables. This would be accomplished with a mu.yml like this:
service: name: banana-service port: 8080 pathPatterns: - /bananas database: name: banana instanceClass: db.t2.medium iamAuthentication: true environment: SPRING_DATASOURCE_URL: jdbc:mysql://${DatabaseEndpointAddress}:${DatabaseEndpointPort}/${DatabaseName}
The configuration of the tables and the data in the database is managed with Liquibase. When the service is started, Liquibase creates/updates the database tables and data. This is accomplished by creating the a file named db.changelog-master.yaml in src/main/resources/db/changelog/
Now we can commit and push our changes to cause a new run of the pipeline to occur:
$ git add --all && git commit -m "add database" && git push
We see our pipeline is green, so we have confidence that the new database is working properly with the microservice.
Conclusion
Realizing the benefits of microservices requires decomposing not just the application, but also the databases that support it. As demonstrated in this post, mu makes it simple to manage your database and wire them up to your microservices. The goal is that mu empowers you to implement microservice best practices in your application.
In the upcoming posts in this blog series, we will look into:
- Service Discovery – use mu to enable service discovery via `Consul` to allow for inter-service communication
- Additional Use Cases – deploy applications other than microservices via mu, like a wordpress stack
Until then, head over to stelligent/mu on GitHub and get started!
Additional Resources
- Introducing mu: a tool for managing your microservices in AWS – Introducing the motivation for mu and demonstrating the deployment of a microservice with it.
- Microservice testing with mu: injecting quality into the pipeline – Incorporating automated testing in the microservice pipeline.
- Databases – Wiki page for using databases with mu.
- Microservices – Blog post on principles of microservices, specifically Decentralized Data Management
- banana-service – Code for this blog post
Did you find this post interesting? Are you passionate about working with the latest AWS technologies? If so, Stelligent is hiring and we would love to hear from you!
|
Stelligent Amazon Pollycast
 |