It’s a Microservice World for Us Too
We here at LendingTree have been creating websites for a long time, having gone though various forms of websites, frameworks and technologies. Our current implementation is based on AngularJS on the front end and .NET APIs in the back end.
Over time through our iterations, we noticed how multiple areas of the company shared the same types of needs. For instance, the need to be able to post data to a 3rd party so teams can act on that data. Historically at LendingTree, individual teams have done their “own thing” in regards to this type of integration. Sometimes using code other teams have written. Other times just writing their own.
The Problem: Growth
This independent process seemed to work fine for a while, but as we started to grow and the as the company wanted to move faster, we started having some issues. We had new engineers that didn’t know what services existed and/or why some services existed. This led to engineers calling the incorrect ones or needing to extend existing services, making those extended more brittle.
When it was time to make changes, code existed all over the place, with different coding styles and levels of testing done on them. For example, if we needed to update our business logic for how we call a 3rd party, it was difficult to determine where the code exactly lived and in what structure.
Another problem we ran into was our APIs requiring certain pieces of information to call them, such as GUIDs. This meant you had to enter data into a specific database before calling the service, making it very hard to leverage these APIs as you had to tie yourself to certain databases even if you weren’t using them at all for your project. This issue caused much of our code to end up getting far too coupled with each other.
The Solution: Enter Microservices
We knew these were issues that needed to be addressed. As we worked towards solving these issues, a few things quickly became apparent to us. We needed to consolidate our services to one place where all parts of the company could go to communicate with a 3rd party. Simultaneously, we also needed a better way of communicating and sharing our project plan, endpoint and status.
It became obvious that we needed to move to a microservice architecture yet this came with it’s own concerns, especially around the registration and discovery of these microservices. Some questions came up:
- Should they be allowed to talk to each other?
- Where should the path for each microservice live?
- What if we update the endpoint URL of a microservice?
These concerns and how to resolve them are major questions to microservice architecture in general. There is no right or wrong way to resolve them. You just want to ensure you do resolve them. At Netflix, their solution uses a common API that calls all of their microservices. Meanwhile, Uber leverages Thrift and some other internal services to allow their microservices to call each other. However you choose to answer your needs for your environment, be sure to take time and carefully think through your solution as this is a very important decision in the process.
At LendingTree we decided on implementing a model that uses the Application Load Balancer from Amazon. This would allow us to have a common location for all our APIs and allow mapping to the actual service in the back end.
The Microservice Way
There are a few helpful things that I have figured out in regards to implementing microservices. One of the bigger concepts is that of breaking things down into modules, organizing logically related services together into interchangeable blocks so they can be easily upgraded in the future. For example, storing and retrieving data should be in one module.
Once you have things broken down into modules, you can then decide which modules need further development around them and would warrant promoting to a service. For example, if we have a call to a 3rd party that limits the number of requests you can make in a time period, then it would make sense to create a service as you need to make sure you are keeping track of all calls to that 3rd party. But, the data module probably doesn’t need to be promoted to a service as the code can live in a module and just be included into the project.
Creating a New Microservice
At LendingTree, we want to have some visibility into the services that were being created. We are looking at posting new service RFCs (Request For Comments) to Slack for review and historical tracking purposes.
Personally, I love the process that Uber has where they send out a document before creating a new microservice. This process allows everyone to see a new microservice before it is built and allows team members to have a conversation on it’s function, design, or the building process. Members can take project documents and host them for others to see. Documents are also centralized so everyone can see all of the microservices available and what each one does. This is very powerful for new developers!
As LendingTree continues to grow and learn, our microservice needs will undoubtedly grow and evolve as well. It’s a big world of micro possibilities!
Join Us
Thanks for reading about how we are doing things here at LendingTree. If you would like to join and help shape our company, please visit careers.lendingtree.com and contact us. Follow us on Twitter: @Careers_LT
