Things I Have Learned Adopting a Microservice Strategy (Part 2)
Join the DZone community and get the full member experience.Join For Free
In the initial article of my "Things I Have Learned Adopting a Microservice Strategy" series, I focused on the following pitfalls:
- Monolith -> Microservice Challenge (replacing one huge challenge with an equal challenge)
- The Underlying Database (trying to make things work using an outdated data model)
- Monolith -> Multiple Microservices Challenges (introducing a complex web of services)
In this article, I am going to focus on the following challenges:
- Challenges with a Loose Contract
- Shared Components Between Microservices
- A Session-Free World
- Setting Realistic Client Expectations
Challenges With a Loose Contract
In the original article, I mentioned the front-end client team starting their quest to build something new and exciting. While their code will certainly contain a great deal of aspects related to the presentation of the new solution, there will be some exchange of data required with the API service. In most cases, the client itself is going to maintain a collection of these data objects which may mirror the data on the RESTful API. I stress "may" because that team will structure the data in a manner which best suits their needs.
Of course, if the API team and the front-end team maintain a good relationship and communicate their needs often, the data contact will likely be without issue. However, because this is a loose contract, things can get out of hand as more teams become involved in the project and developers do not have a good understanding of the importance of keeping both sides in sync with each other.
This very situation has become an issue with every large project since 2014, as contract resources are brought on the project for a short-term basis or near the end of the project. In those cases, their goal is to get the required tasks completed as quickly as possible. Because of this situation, having a full understanding of everything cannot be assumed and often is the cause for challenges. In some cases, these challenges are not revealed until after the code has been deployed.
Shared Components Between Microservices
In the original article of the series, I mentioned the potential for duplicated business logic across microservice classes. One way to avoid violating the DRY (don't repeat yourself) principle is to offer a common library that is shared by all teams.
If you are using multiple microservices, this library could be maintained by all teams and included within each service. For Java APIs, this could be as simple as a Maven-based JAR file that is included as a dependency. Even in that single monolithic example, it might make sense to take the same approach, because that logic could be utilized by other systems not directed tied to a single project. Remember, DRY doesn't have to be in reference to a single application.
The takeaway here is to recognize when duplicate code is being allowed to enter the develop branch of a repository. If such a scenario cannot be avoided in the short term, certainly include a // FIXME note in the code, with a link to some form of ticket to make sure any duplication is short-term.
A Session-Free World
In the prior generation of web applications, the service layer often maintained session information for the users currently utilizing the application. As a developer, this was nice, because you had the ability to keep things on the session and reference them as needed. However, when RESTful programming became popular, the concept of maintaining a session was no longer in the specifications.
From an application server perspective, this is nice situation - to no longer have to maintain, synchronize and destroy session information. However, the current approach does lend itself toward the potential of a far more collection of requests that are being made. In fact, I recall one application sending more fifty RESTful API calls during the initial login.
Sound crazy? Maybe, but having teams work in isolation can tend to yield such a design. Something to consider is to figure out what data is truly required on the client side and make sure only that data is requested at the time it is needed. Once retrieved, consideration should be made to maintain a data store on the client - especially if the alternative is to simply re-request the data from the RESTful API again.
Setting Realistic Client Expectations
Understanding that most developers are not developing and testing their application on a subpar machine, I cannot stress enough to have access to a machine which represents the bottom tier on the performance pyramid.
A serious alternative is to consider allowing the service layer handle aspects that will have an impact on the user experience - especially those users not touting the latest hardware.
With each project, each feature and each pull-request, I learn more about microservices and what works well and what doesn't seem to pan out as expected. My hope is that you are able to learn from the examples I have provided and avoid falling into these same pitfalls on your project.
A few additional articles I wanted to reference, are noted below:
- Keep it Simple -> I Want My Code to Be Boring
- Keep it Lean -> When You Don't Want the Whole World Returned to You
- Keep it Focused -> What Is the Value of Your RESTful API?
Have a really great day!
Opinions expressed by DZone contributors are their own.