{{announcement.body}}
{{announcement.title}}

Things I Have Learned Adopting a Microservice Strategy (Part 2)

DZone 's Guide to

Things I Have Learned Adopting a Microservice Strategy (Part 2)

Let's examine some of the pitfalls, challenges, and solutions to adopting a microservices strategy with a focus on RESTful APIs and shared components.

· Microservices Zone ·
Free Resource

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

When adopting a microservices strategy, there is often a JavaScript-based client running to serve as the presentation layer.  There are certainly some really nice frameworks to help the client developer create powerful applications.  However, the biggest challenge is keeping in mind that the application will ultimately run in a browser - which often includes older systems or even Chromebooks.

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.

JavaScript is great.  It is powerful.  There are so many modules that can easily be plugged-in to a JavaScript framework to provide additional functionality.  However, it is important to keep in mind the impact on the CPU, memory and performance that will be compromised with each feature that lives inside the JavaScript code base.

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.

Conclusion

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:

Have a really great day!

Topics:
lessons learned ,microservice architecture ,microservices ,monolith architecture ,restful api

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}