What are common pitfalls with microservices


Submitted by Storage Consortium on April 29, 2021 - 17:01

Munich, Starnberg, April 29, 2021 - The changeover to a new database is a complex process with imponderables; Couchbase comments on the most common hurdles ...

To the background: The requirements for modern IT infrastructures are clearly defined: They have to be fast, agile, highly scalable and highly available. Legacy systems such as relational database management systems (RDBMS) are often too rigid and limited to be able to provide the data and information required for modern, distributed applications in hybrid IT and multi-cloud scenarios. The migration to a flexible database platform that masters the advantages of RDBMS, NoSQL and cloud with edge computing therefore seems logical. Behind this, however, there are sub-aspects that require a great deal of attention in order to carry out such a modern change as cleanly and with as little risk as possible. Couchbase specialist - provider of a modern data management platform - names the five most important points for you from his point of view below:

  1. "The migration of the data. It is fatal when switching to a new database (such as NoSQL) to adopt the data model of the old relational database management system 1: 1. In order to properly use the advantages of modern databases and to be able to support new use cases and SLAs (Service Level Agreements), a new data model is required - just like a sports car needs adequate tires in order to develop its full potential.

  2. The migration of the app framework. The same applies to the application logic. The programming framework must be adapted to the possibilities of the new database. This applies, for example, to the adaptation of the programming libraries (SDKs) to the new database. If that is not enough because the framework in the legacy system is no longer up-to-date (e.g. Cobol), the entire framework must be replaced.

  3. The migration of the apps. A common mistake is the big bang approach. Just as it makes little sense to try to chase times on the Nürburgring with a freshly purchased sports car immediately, the risk of migration should also be minimized through successive procedures. A step-by-step migration with a bi-directional data connector between the old and the new world takes the time pressure off and ensures that regular operations can continue uninterrupted from the user's point of view.

  4. The importance of migration partners. Pure in-house solutions are often regarded as supposed proof of qualification, but are usually illusory. The inclusion of external advice with valuable knowledge of best practices and typical sources of error can protect against wrong turns, shorten the migration process and ultimately also help to keep costs under control. This experience can be contributed by IT system partners or the database manufacturer.

  5. The organizational changes. The technical migration of the database system alone is usually not enough to achieve the desired support for the corporate goals. This also requires internal operational changes, such as a more DevOps-driven organization. This also changes the classic role of database administrators, who are more closely involved in app development with microservices and CI / CD automation. "

Fig. 1 N1QL: SQL-like queries and the flexibility of JSON (image source: Couch base)

Cross reference: