When Breaking Up a Monolith, Consider Data as Much as Code
When Breaking Up a Monolith, Consider Data as Much as Code
One of the most challenging aspects of migrating to a microservice architecture is deciding which pieces of the monolith to break off first into separate services. Architects must understand the business objectives, how the services function and how they will relate to the rest of the whole. Then, the team faces more challenges once the services are up and running. Operational complexity increases because each service may have its own languages, toolsets and infrastructure.
To help solve these and other problems that arise when moving to microservices, a new set of commercial monitoring solutions, from companies such as Dynatrace, have emerged on top of existing open source tools like Prometheus. By pulling in data from multiple sources via an API, such monitoring tools can provide a complete view of an application, from its traffic patterns on the network and the database statements it executes, to which container, platform and host a service runs on.
“Once you install Dynatrace, we’re monitoring and tracking every single service, process, host, log, and also end user,” said Andreas Grabner, DevOps activist, Dynatrace. “We have a complete live dependency map from your complete environment.”
This comprehensive view can help architects determine how best to further break apart the codebase, for example. It can also help identify the technical root cause of a particular problem and provide additional context, such as how many users are impacted and in what regions to help remediate the problem faster, Grabner said.
“Commercial offerings on top of open source tools give you confidence that these tools will last, and are not just supported by a small community that may no longer exist in a year,” Grabner said. “They also give you the best practices to support the services.”
One emerging best practice for breaking up a monolith into microservices that Dynatrace has observed among its customers is to give each service its own data store. If an application was supported by a big monolithic relational database, then an organization must first decide how to extract the data that is relevant for that service into its own data store.
“Sometimes when people talk about breaking the monolith into services, they only think about the code,” Grabner said. “But, it’s important also where the data lives that this service is depending on. You have to treat your current data store just as another monolith.”
Learn about use cases for cloud native monitoring tools, best practices for breaking down the database monolith, and how to tap into old and new systems to get the information teams need to make business-critical changes to an application.
During the interview, Grabner referenced how to deploy voice-enabled monitoring with Amazon Web Services’ Alexa. More info here:
In this Edition:
1:48: How do you think of the DevOps evolution in the context of Dynatrace and its goals?
6:35: What are organizations doing in the background to make these jobs easier for the people who are building these services and may have different skill levels?
12:29: Exploring what these experienced people have been a part of developing over the last several years in open source
15:15: What are some of the ways you’re hoping to improve upon your support for particular platforms and services going forward?
22:16: Can you tell us more about the Dynatrace architecture?
29:40: Can you tell us about Dynatrace University?