EasyTravel is a monolithic Java application that as we saw earlier provides several web services like Booking, Authentication, and Journey.
Our overall goal at easyTravel is to breakout each of these backend services into separate services. This will allow us to have separate Continuous Integration (CI) pipelines to build and test each service independantly. By putting these service into Docker images, we gain the ability to deploy the service into modern platforms like Kubernetes using AWS managed services. By adding Continuous Deployment (CD) to our process, we will vastly increase our ability to delivery features faster to our customers.
For this review, we are going to focus on the JourneyService
.
Referring to the picture above, notice how the INTERMEDIATE STEP show the JourneyService
resulting in two services:
As the lead developer, Henrik knows that within the code the checkDestination is a separate Java method and he would like to understand how often it gets called and the typical response times. This will help establish the Services Levels that will be required for monitoring and sizing.
Dynatrace automatically detects and monitors most server-side services in your environment with no configuration required. If your application doesn’t rely on standard frameworks, you can set up custom services.
With a custom service you can instruct Dynatrace which method, class, or interface it should use to gain access to each of your application’s custom server-side services.
Henrik knows the Java class and method within the JourneyService` and configured this custom service.
During the workshop provisioning we used the Dynatrace API to add this configuration. Navigate to the (Settings –> Server-side service monitoring –> custom service detection) to check it out.
1 . In Dynatrace, open the transactions and services
page from the left side menu.
2 . Use the Management Zones filter to pick the ez-travel
option
During the workshop provisioning we used the Dynatrace Management Zones API to add this configuration. Navigate to (Settings –> Preferences –> Management Zones) to check it out.
3 . Use the Technology
filter choosing the Apache Tomcat
option. From the list, pick the JourneyService
4 . On the Journey service page, click the View service flow button. Go ahead and change the Throughput view and expand the CheckDestination service to see the Request and response time details.
The CheckDestination
service is called nearly each invocation to the JourneyService
and its not a high contributor to overall time. So Henrik now has the informaton he needs to make smarter re-architecture and re-platforming decisions