Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How We Use Neo4j to Manage Microservices at Veneto Banca

DZone's Guide to

How We Use Neo4j to Manage Microservices at Veneto Banca

Neo4j has revolutionized Veneto Banca's technology over the past couple of years. Read this in depth discussion of what happened.

· Integration Zone
Free Resource

Share, secure, distribute, control, and monetize your APIs with the platform built with performance, time-to-value, and growth in mind. Free 90-day trial of 3Scale by Red Hat

Thinking, designing and implementing an enterprise multi-channel architecture and platform is a challenging opportunity.

For the last couple of years we’ve been involved in this huge project at Veneto Banca, and our mission was the innovation of the bank’s information technology system from the scratch. We wanted to adopt the microservices paradigm exposed by Martin Fowler and to design a brand new object data model for our business needs.

At some point we realized that we needed a tool to govern the landscape of our services composing the application’s business logic.

During the development of the program, it was very hard to take control of the business components that were developed because of the huge number of application teams working on each specific project or functionality.

Learn How the Veneto Banca Team Uses Neo4j to Manage a Multi-Channel Architecture of Microservices

While it is true that a service catalogue is something worthwhile for a healthy government process, in a huge, real-world project this doesn’t always lend itself to a “time-to-market” approach.

But then some interesting questions arise:

  • Can you describe your multi-channel architecture in terms of layers, services, components?
  • What are the impacts on the application if a certain service provider goes down and becomes unreachable?
  • How can I change a service behavior (or its configuration) on the fly?
  • Which are the impacts if we modify the source code of a service?
You may think that it would be nice to have a “smart black box” that could answer these questions simply by pressing a “DO IT” button. We wanted to build “something” that would help us automate some steps of the process.

So we started investigating the best approach to achieve our goals and we built what we call our “service catalogue”.

The first approach was RDBMS-based because our team already has the expertise we needed, and we wanted to cut straight to the point.

A Service Catalogue Built Using an RDBMS

The core solution was the implementation of reader and parser components along with adapters for building the catalogue according to the database schema.

During the testing of our beta version we faced some problems with relationships. It was difficult to write the SQL code to implement the queries we needed in order to extract meaningful information from our repository. Moreover, these queries were difficult to read and understand.

The relationships have lost their semantic meanings and the catalogue was a poor tool to answer some “what if” questions.

Thanks to LARUS and their #1 Neo4j evangelist Lorenzo Speranzoni we discovered the power of graph databases and Neo4j in particular.

We were impressed by the way Neo4j treats relationships; they become first-class citizens of the domain model, and they take a central role in the definition of the information handled by the system.

So we’ve moved forward and refactored our components (except the catalogue builder components) in order to build a graph-based data model for our services. And we got something like this:

A Data Model for Managing Microservices

A Sample of Our Data Model

If you’re wondering why Neo4j, well, these are some of the key features we love:

    • Natural: A graph is the most natural way to represent entities (nodes) that have connections (relationships).
    • Schema-less: We can add new types of nodes, relationships and properties easily, so the model can evolve in a simple way (for example, refactoring properties to nodes with no pain).
    • Intuitive: The whiteboard model is the physical model (what we draw on a paper is what we get on the database).
    • Powerful: It offers an expressive, declarative query language (Cypher), that let you write concise queries.
    • Easy to integrate: It is supported by a rich ecosystem of libraries, tools, drivers and guides provided by partners, users and community contributors.
In this way we obtained what we wanted: a deep knowledge of our system and a clear dependency management picture of all our components. Plus we got the chance to have an updated snapshot of our system.

Take a look on how the process flow looks like when we have to face a software change, and we must discover all the impacts in order to run all the test suites to avoid regressions.

Using Neo4j for Impact Analysis of Software Change

This is only a brief example of the impact analysis that we can do with our service catalogue.

In conclusion, implementing an IT government tool based on Neo4j has been the right choice because:


    • Standard DBMSs do not manage relationships in a strict manner for us, but Neo4j does!
    • Neo4j is whiteboard friendly; what you draw on your paper is what you get on Neo4j
    • It’s powerful and easy. It’s powerful because it’s easy!
    • …and last but not least… we like it!
Attend our upcoming talk at GraphConnect Europe, and we will explore how Neo4j can help you monitoring and governing your multi-channel architecture of microservices. 

Explore the core elements of owning an API strategy and best practices for effective API programs. Download the API Owner's Manual, brought to you by 3Scale by Red Hat

Topics:
microservices ,neo4j

Published at DZone with permission of William Lyon, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}