In FusionReactor 8.2.0 we have added support for the Java application Frameworks okHTML, Spring Boot and Micronaut. This brings the list of supported Java application frameworks to; Spring framework, Spring Boot, okHTML, Micronaut, Struts 2, Play, Vaadin, JSF, Vertx, Grizzly and Jersey.
In this blog, we look at why Microservices are beneficial to organizations, things to consider when using microservices and how different Microservices are tracked in FusionReactor.
Why tracking Microservices is important?
Software architecture using Microservices divides a system into a number of smaller and simpler services. These services are independent of each other and typically communicate with each other through REST calls. These independent services can use different languages, Frameworks and environments making the infrastructure very flexible.
Using Microservices breaks down the monolithic applications you currently run into more maintainable apps. While initially converting applications to Microservices can be time-consuming the long term benefits are definitely worth it in most cases.
There are many benefits to using a Microservice-based architecture, with the 5 biggest benefits being
Building and maintaining your environment is quicker and easier
As the code of a service is smaller and less complex, creating the base functionality required for the application a very simple process. Often a template can be created and reused so bootstrapping a new service takes minutes.
You are not limited to a specific language or Framework and do not have to worry about the libraries or databases used in this service being incompatible with libraries or databases of a separate service.
Structured around the needs of an organisation, not a speciality in a particular language
With Monolithic projects, it is common that one team will own and manage the development of an entire project. Any work required for this product must be done by a single team, which can quickly cause delays in features being available.
Microservices, on the other hand, can be developed by an engineer of any team. If additional functionality is required, rather than adding to an additional project they simply create a new service to supply the functionality they require.
Improved reliability and speed of bug resolution
The large and more complex the applications are, the harder it is to track down issues. Having smaller and simpler apps means that writing automated and manual testing is more simple; often most unit tests can be autogenerated to some extent from your IDE.
Finding any issues is a quick process as there are hopefully no large functions that try to do too much in a single function.
Infinitely scalable
There is nothing worse than being limited to how and if you can scale your application. With a large application where you may have complex dependencies and threading models, scaling will be difficult to configure and sometimes impossible.
If all you have is a series of small apps that communicate with each other to access information, there are no dependency concerns. If the way you are currently scaling is no longer the best solution switching to a new approach has very little risk
It’s perfect for SCRUM
Scrum promotes Cross-functional small teams where any member of the team can do every required task. It does not matter if these teams are in the same location or other sides of the world.
When every developer is working on the same application and often the same module of the application it can get messy, but if everything is independent of the components around it you can be truly cross-functional and not get in each other’s way.
Considerations when using Microservices
When using microservices you can gain a lot, but there are certain things you should keep in mind when implementing Microservices in your infrastructure.
Documentation is vital
When you have hundreds of potential APIs that are running, knowing the available routes for each API and the restrictions in place for that route is something that must be documented.
When creating routes, naming conventions and versioning of APIs must be carefully thought out to keep the service simple and understandable. A route should have one task only and if a change is needed a new version should be created.
Automation is key
Automated testing and deploys will make or break a Microservice-based architecture.
If new services are being created regularly and being worked on constantly, having unit tests capable the individual functions and integration tests to ensure the connectivity into the API is critical to ensuring the stability of your application.
Keeping your services on the most up to date version of the code as you scale up your environment can quickly become a challenge. At this point, having a staging environment and auto deployments to keep your services up to date becomes a priority.
Transparency is a must
Finding issues within microservices is a challenge, with the code being split into so many smaller components.
If a user reports an issue in your application, knowing exactly which service has an issue is not simple. In order to find these issues, you need to be able to see the traffic running on your server and any the reason for any errors that are occurring.
You could use logs for this, but the best way to track your Microservice deployment is with an Application Performance Monitor (APM). An APM will give you metrics on the server traffic and tools to help you track down the root cause of errors.
Tracked framework examples
Spring Boot
Spring boot is the most commonly used framework in Java, it makes developing applications from web apps, to complex APIs very simple with it’s structured MVC layout. It’s JDBC extraction makes integrating with SQL and NoSQL DBs simple and it’s simple testability add ons that make automated testing quick and simple.
In FusionReactor Spring boot your request will be deconstructed into it their individual controller and hibernate calls.
In our example, we see a call to add an item to a shopping cart. We can see the addToCart method being called within the CartController and the individual JDBC calls made during the execution, as well as the final redirect call.
In the details of our request, we get a breakdown of each action in the execution of our request.
For requests with errors the full stack and an EventSnapshot is captured to get you to the root of your issue quickly
Micronaut
First Introduced in May 2018, Micronaut is a fairly new framework to be introduced to Java. It allows users to build scalable and performant applications in Java, Kotlin or Groovy. With its reactive HTTP server and client capabilities, efficient compile-time injection and well thought out features for microservice development. It is perfect for applications where heavier MVC frameworks are not an option.
With Mirconaut, the request and response are tracked as two different transactions. When the response transaction is complete the response object will be linked to the request object. For each transaction, you see the status code, protocol and request URL.
In each transaction, you see Headers and Cookies. Unfortunately, JSON tracking is not currently available for Micronaut, this is something we are working on but as of yet have not been able to implement.
OkHTTP
okHTTP is a popular alternative to the Apache HTTP Client for making HTTP / HTTPS calls from within your Java application. It is efficient with HTTP and HTTP2 clients, with advanced connection pooling and the ability to recover from common connection problems.
okHTTP request, you will see that each HTTP call is tracked as its own transaction. The transaction has a parent of the Web Request that contained the okHTTP call.
In the request we track any JSON data send and received in the response, as well as the headers and cookies of the request.
