On the Use of Microservices at RBC
It has been a fast-paced four months as a Full Stack Developer co-op as RBC transforms its digital strategy. As part of this transformation, Business Financial Services (a team within RBC) has been gravitating towards implementing microservice architecture to better handle load from 800,000+ clients daily.
What are microservices? Microservices are small applications where each service serves a specific purpose. The microservice architecture champions modularity, which in turn improves scalability. More instances of specific services can be spun up as load increases, as opposed to spinning up more instances of a monolithic application needing several times the resources of each microservice.
As BFS implements microservice architecture, several problems have surfaced. With hundreds of microservices projected to be created within the next few years, it becomes a huge task to keep track of the URL of each microservice, especially considering application movement between developer environments (dev, QA, production). Furthermore, BFS uses Bluemix and other hosting platforms to serve its applications, meaning load balancing cannot be centralized or delegated to a single platform. Bluemix also doesn’t provide fine-tuned health checks, meaning unless your instance has crashed Bluemix will continue routing traffic to it. Finally, Bluemix only routes traffic to instances on Bluemix, which limits our hosting platforms to just Bluemix.
The Solution: Microservice Magic!
Solving these issues is Eureka. Netflix released Eureka in 2012 as their solution to the issues that arise with using the microservice architecture. Eureka works like a phone book; when a service is spun up it registers itself with Eureka, providing its URL and how other services can connect to it. Most importantly, it fetches the latest copy of the microservice registry from Eureka. This registry is updated as services go up and down, and all microservices receive the changes. When a microservice needs to connect to another, it finds the URL of the service in the registry and makes the call. Furthermore, even if the Eureka server is unreachable, all the microservices still maintain the latest copy of the registry and can continue working.
Within BFS, several teams use Angular for the front-end and Java Spring Boot for the back-end. Spring Boot includes support for Eureka natively, so Eureka server setup is as easy as including the dependency and spinning up the application as a standalone Eureka server. Setting up microservices to be Eureka clients is easy as well with Spring Boot; simply include the appropriate client dependency and set the Eureka properties to connect to the correct Eureka server.
Once a Eureka server and clients have been made, the microservices are ready for calls to be forwarded to them. In the UI, REST calls need to be forwarded via another Netflix open source project called Zuul. Although a “phone book” has been made (Eureka), the UI needs a service to query the Eureka server which returns the appropriate URL. Zuul provides this functionality. Think of Zuul as a reverse proxy; Zuul takes a service ID matching the one found on Eureka and returns its appropriate URL. In the application properties file in the back-end of the UI, properties can be specified to proxy all calls made to a certain slug to a corresponding service. For example, the back-end portion of the UI can be configured to forward all calls from /my-example/** to the service ID my-api, with the path parameters ** being forwarded to the service as well. Zuul uses Eureka to fetch the registry of services’ URL, and setup in a Spring Boot application is like that of a Eureka client — include the dependency, add an annotation and a few lines of code, and your application is ready to forward requests via Zuul!
Now we have a server which stores the registry of all microservices registered on it, and clients can connect successfully to each microservice individually. But what about microservices talking to other microservices? Say we have an API handling all calls related to where a certain make of car can be purchased, and another API handling the current price of those cars. How would those two microservices be able to talk to each other?
A third open source solution that Netflix introduced is called Ribbon which allows for communication between microservices through Eureka. Zuul was introduced above as a reverse proxy, but it serves the outward facing part of routing. Ribbon is the inward facing part. Ribbon serves as a routing layer between microservices; it fetches a list of servers each microservice is running on and uses the registry from Eureka to populate different client contexts. Having a routing layer increases modularity by allowing the user to address concerns such as security and logging and abstracting away from core API code. Again, setup is as simple as the process described above in Eureka and Zuul.
With this many microservices in play and many more planned, API testing and monitoring becomes ever more important. With hundreds of thousands of clients leveraging our software and services, it is crucial to thoroughly test APIs before they go live to ensure stability. As microservices often rely on one another to produce an expected result, it’s also critical to monitor the health of each microservice and determine if certain designs need to change to optimize resource usage.
Overall, the microservice architecture at RBC has improved modularity and allowed us to scale quickly with minimal effort to the developer. Microservices promote abstraction, and separating logic in a way that makes sense. These four months at RBC have been fantastic, and I can’t wait to see the advances happening in the API ecosystem as a result of the microservice architecture becoming more and more prevalent.
On a last note, I’d like to include a special thanks to Tobias Coetzee, Senior Engineering Manager of Platforms & DevOps at RBC, for his time and contribution to the creation of this article, as well as his continued support of the co-op team here in BFS. I want to thank my team, managers, and the executive team as well for their passion for fast-paced learning and growing in the short four-month co-op term at RBC. If you’re interested in learning more about microservice architecture, there is a fantastic video available here which goes in depth about Netflix’s use of Eureka and the microservice system. Another interesting read is Martin Fowler’s take on microservices available here which discusses the recent surge in popularity of microservices.
Stay Ahead 📈
API testing and monitoring — start free-forever here: ibm.biz/apitest
We hope you found value in this article. Special thanks to Brian Lin for sharing. Please let us know in the comments what you would like to see next time!
