Microservice architecture and RaygunPosted Dec 21, 2016 | 5 min. (987 words)
With the much of the software industry shifting towards a service-oriented architecture (SOA) approach to their software design several new paradigms have emerged. Microservices have arisen as a popular pattern for implementing SOA design principles. Here at Raygun, we support a variety of different ways to handle your microservice architecture.
What are microservices?
Microservice architecture is based around the idea that several small, independently deployable software systems are easier to create and maintain than a single large software system. Aiming to increase cohesion and reduce coupling within a software solution, microservices typically have the following key things:
- Services are small, focusing on a single area of responsibility (billing, logistics, etc.)
- Services are independently deployable
- Services can be of different programming languages, hardware, and environments
- Services should encourage automation of deployment and testing to reduce burden on operations and development resources
An example of this sort of structure versus the typical monolithic software system would be taking a banking application and splitting out the different internal contexts into microservices. Instead of one large system you’d have independent services/systems handling billing, deposits/withdrawals, front-end, and so on. So when a change needs to be made to the billing system, the entire system would not need to be taken down or redeployable, only the microservice that was changed.
What are the drawbacks of microservices?
While incredibly useful, microservices can have some drawbacks that should definitely be thought through before making a switch.
Microservices abstract the complexity of a monolithic application out of the code itself and place it on the network. While the individual software systems are simple, the resulting network that ties them together becomes more complex and requires more fault-tolerance and load balancing.
- Testing and Deployment
With the reliance on sending messages between services over a network, the testing and deployment of microservices becomes harder. Rather than being able to test a system from beginning to end in one system, you now have to rely on complex staging/test environments or the usage of ‘mocked’ calls and responses to simulate the entire system.
While the individual performance of the microservices may be faster due to their smaller size and context specific purpose, the reliance on sending messages between services via the network can bring down performance due to network latency and message processing.
So how can Raygun help?
Raygun offers support for microservice architectures with the freedom of the Raygun ‘application’. Applications are defined in Raygun as anything reporting data to Raygun using a specific API key. So you may have a single monolithic application or a system with dozens or even hundreds of microservices, you can group them or split them up however works best for you. This allows you to configure your Raygun setup to be as granular or overarching as you need it to be.
To better illustrate this here are few example use cases for both a monolithic banking application and a banking app based on microservices.
Monolithic Banking App
Using a single Raygun application, you can track all the exceptions and errors for the entire application. This is the most basic approach that gives full access and information to all team members of the application.
By setting up multiple applications inside Raygun with their own unique API keys, you can then use those specific API keys within your monolithic banking application to create a logical/imaginary separation between different systems. So a large single system can be represented and tracked inside Raygun as a collection of smaller systems. This means you can then assign users/teams to certain applications without having to give them access to the entire system inside Raygun.
Microservice based Banking App
Multiple services, one application approach: (not recommended)
If you have several services under control of a single development or operations team, you can use the same API key with each of those services to have their exception data all tracked under one application in Raygun. While this may seem to simplify administration on the Raygun side, it doesn’t always lead to the most useful information on any of the included microservices.
As each Raygun application only has the ability to integrate with a single Slack Channel, JIRA system, etc. you would be forgoing the ability to separate out that information between different languages or systems. The error grouping would still function but your teams would have to discern between the different services in a single feed of exceptions.
One service, one application approach: (recommended)
By creating a separate Raygun application for each microservice and then assigned certain teams to have access to those applications, you truly start to utilize the power that Raygun provides. You get detailed, easy to use information on the exceptions from a particular service while still maintaining the ability to see trends utilizing the Global Application Dashboard. Combined with our custom reports feature that’s being rolled out soon, you have all the information you need to keep track of individual and groups of services.
This provides the most granular and easily trackable way to maintain exception monitoring on your services. Each service and resulting application in Raygun could have its own Slack/HipChat channel and notification settings for the team.
Final thoughts on microservice architecture
As you can see, our application system allows you to determine how you want to structure and organize your application or services inside Raygun. Given the rise of microservices and service-oriented architecture, having this customization available allows you to adapt as your software systems grow and change over the years.
Do you have any interesting use cases or examples of how you’ve setup your Raygun applications with microservices? Leave us a comment and let us know!
Raygun Crash Reporting gives you full stacktraces for each and every error occurrence, along with environment information, HTTP requests, raw data, browser, OS, affected users and more. Take a free trial here, or book a short demo with one of our team.