Third, the increasing complexity of IT projects, such as digital transformation and support for IoT, led to the need for tighter integration within the enterprise architecture.

Some of the obstacles that he sees organizations running into when trying to undergo the transformation from older monolithic architecture are the data volume and integrity, autonomous service management, and the ability to run diagnostics.

Christ explained that the volume of data can cause major stress on an enterprise’s network, resulting in latency. There may be hundreds of services running within a single application, and requests could span multiple services. In addition, when taking a decentralized approach, such as with microservices, high-quality data becomes more complex, especially when each microservice has a different database and each database might use a different technology. This can lead to issues when services are referencing data in other services, Christ said.

Management of autonomous services also becomes more complex when teams are dealing with hundreds of interdependent services rather than just one deployment, he explained.

Finally, managing performance on microservice-based applications requires more effort than it would on a monolithic application. Applications may produce large numbers of logs that need analysis, which means debugging and running diagnostics becomes a laborious process, Christ said.  

In order to overcome these challenges, it’s important to remember that this transition will not happen all at once, but the monolith with decrease every day. Monolithic code will live on in the system for years after making the switch. He explained that companies need to decide when and where these microservices can be integrated into existing applications.

Christ lists these six rules that a microservices adoption plan should follow:

  1. Services should be designed and responsible for only a single business capability.
  2. Each microservice should have its own datastore.
  3. Code should have similar levels of maturity.
  4. Deploy microservices in containers.
  5. Treat servers as replaceable members of a group that all have the same functionality.
  6. Monitor microservices with mechanisms such as response time notifications, service error notifications, and dashboards.

He also explained that when coming up with a plan, it’s important to think about how the application will be used. “Identify the goals in the context of the user’s environment, task or work flow and let the needs inform the design,” he said.