An Example of Microservices and Legacy

The goal of a project was to modernize an existing Java e-commerce application. This involved the introduction of new technologies, for example new frameworks, to improve future software development productivity. After some time, it transpired that the effort required to integrate the new and old technologies would be huge. The new code had to be able to call the old one—and vice versa. This required technology integration in both directions. Transactions and database connections had to be shared, and security mechanisms had to be integrated. This integration would render the development of the new software more complicated and endanger the entire project.

Figure 4.1 shows the solution: the new system was developed completely independent of the old system. The only integration was provided by links that call certain behaviors in the old software—for instance, the addition of items to the shopping cart. The new system also had access to the same database as the old system. In hindsight, a shared database is not a good idea, as the database is an internal representation of the data of the old system. When this representation is placed at the disposal of another application, the principle of encapsulation1 is violated (see section 9.1). The data structures will be difficult to change now that both the old system and the new system depend on them.

Example of Legacy Integration

Figure 4.1 Example of Legacy Integration

The approach to develop the system separately solved the integration- related problems to a large extent. Developers could use new technological approaches without having to consider the old code and the old approaches. This enabled much more elegant solutions.


Continuous Delivery Pipeline

Figure 4.2 Continuous Delivery Pipeline

< Prev   CONTENTS   Source   Next >