Issues With the Creation and Management of Microservices

DZone 's Guide to

Issues With the Creation and Management of Microservices

The most common issues with microservices are data, complexity, monitoring, skills, and security.

· Microservices Zone ·
Free Resource

To understand the current and future state of microservices, we spoke to 25 IT executives from 21 organizations. Consistent with the early adoption of the technology, the answers to our questions were diverse. We asked them, "What are the most common issues you see affecting the creation and management of microservices?" Here's what they told us:


  • If you don’t slice and dice responsibilities correctly you run into problems. Make any application into a distributed system. Think about the potential problems you will encounter. Managing data and managing states is where a lot of people have problems managing stateful and stateless data. Think about event-driven to communicate commands and data to build the best architecture. 
  • 1) Management of state and defining the components. If crash and burn, you can just replace if it's stateless. 2) Be mindful of the architecture. How to split different components. You could be adding complexity rather than reducing it.


  • Any group or team considering should not jump in if they don’t have clarity on the domain of the problem they are trying to solve. Microservices brings a lot of overhead. It pays out over time as you have more components. From the start, it’s all about overhead. Avoid microservices until you are sure you need them. When you choose the stack, languages, databases for every language you adopt you need to develop boilerplate code and orchestration administration. Think carefully if you’re willing to put in the effort to make it production ready. The same goes for eventual consistency with data. Simplicity is the most fundamental thing to keep in mind. Clean and simple APIs and logic that is easy to wrap your head around to construct more complex apps and behaviors. 
  • Most traditional organizations have to move legacy apps. That’s a multi-year journey. You cannot stop supporting the monolith. Carve the monolith out one service at a time. You need a platform to run the monolith and carve functionality out of it. We aim at being a platform to run microservices on the edge. We use a hypervisor for lift and shift a monolith to a VM knowing the same platform can support Docker and VM. K8s is much less amenable to gradual transition. 
  • One issue with containers is this complexity around having to build container images and post to a repository. This was a hassle developers didn’t worry about in past. Microservices are more difficult to debug and troubleshoot. There are so many microservices, a lot of moving parts. The ability to troubleshoot a single microservice is not as easy as troubleshooting a traditional monolithic app. No tools currently exist to inspect the entire application. You don’t have direct access to a microservice. There may be many replicas. It’s a steep learning curve for developers.


  • Three categories: 1) Desire for visibility and observability of systems they’re building. The ability to make the systems transparent when you want them to be out of the box in development and production; 2) Larger enterprises and the migration of engineering organization have a strong desire to understand best practices, need more about how to get there, pitfalls, and anxiety – standardize where can, air on the side of documenting success and failure; 3) Cross-pollination of engineers – engineers doing the work, having to think too hard and build from scratch things that have already been built. Need for more education of the market by vendors and open source leaders. More documentation of how things are done. 
  • Trying to do microservices when they are not appropriate. How do we get the automation and the observability in place? How do we instrument our app and get data back to interrogate the platform and the app, and when going well to compare when they start to degrade? Visibility and exposing to the people who have responsibility for the applications – developers. 
  • We surveyed 354 respondents in July 2018 to ask our users what challenges they encounter with microservices architectures. Lack of visibility into end-to-end processes that span multiple microservices: 59% of respondents. Ambiguous error handling, leading to unaddressed errors at the boundaries between microservices: 50% of respondents. Cross-team communication among teams working on different microservices: 46% of respondents. Complexity supporting services written in many different programming languages/using different data stores: 38%. Difficulty hiring developers who have the right skill set: 35%. Security issues due to a large number of services: 30%. The issues are both technical and organizational. The right tools don’t yet exist to gain visibility long-running flows that span multiple microservices and to handle errors in an automated way, ensuring that a flow always finishes once it’s started. Teams are still figuring out how to communicate effectively in a new organizational structure and are trying to find the right people who have experience with a microservices architecture.


  • Most people don’t understand the gravity of building services as fine grain and collectively using as a single application. When you break the ESB (enterprise service bus) into multiple services there’s a set of challenges. The main challenge is building the inter-service communication and making them resilient. Guaranteed delivery is implemented as part of the selected code. You must think about how to manage data with decentralized data management. How to create data compositions. Overall monitoring and observability with autonomous services disbursed across the entire network. Need to use observability tools. Tracing standards. If you don’t have a platform and your culture is not aligned properly it’s difficult to get microservices into the product. Whatever new project you are pursuing try to do as a microservice rather than changing legacy apps. Start slowly and gradually move into the architecture. 
  • There’s a large skills gap when it comes to building, delivering, and managing microservices. Few developers have the skills necessary to understand the domain, code the services from data to API, understand the overall architecture, integrate with a CI/CD pipeline, and deliver a running service. Tools for low-code microservice creation and simplified management can be a great lift for “okay” developers, bringing them safely up to speed with very little training, while turning “good” developers into rock stars.


  • Discovery is the biggest. How to discover microservices from a security perspective. It's gone through all the governance you expect it to go through. Catalog microservices and higher order APIs. Creating microservices is a commodity. Look at Google, "10 steps to create a microservice in 10 minutes." 
  • 1) Could become the wild west without proper governance leveraging a service that exposes data that should not be exposed. 2) Security around the data. 3) Management of discovery. Swagger is supposed to help with Microservices management.


  • What is the interface? Make sure you are not breaking dependencies. What services are out there and how to access them? Kubernetes (K8s) helps as does Istio. It's not easy to find the answer people are looking for. Not sure what question to ask to solve the problem. Too early stage.
  • Customers partner with IBM and Pivotal don’t see issues directly. Capgemini and Accenture are seeing business opportunity around replatforming and rearchitecting. A lot of support structure is being built up for the enterprise to go through the process of change. The art and science of creating software. Understand how software with digital capabilities can augment your product to deliver a better experience.
  • The biggest is communication and ownership because everything runs on its own schedule. Automation is next. Without automation, if you are having a hard time deploying large things deploying hundreds or thousands of smaller things can’t be done without automation. Put automation in place before breaking down systems.
  • I think the biggest issue affecting microservices will be around maintaining API compatibility. APIs become a “one-way” contract. Once they are released, they may need to be supported indefinitely since anyone within or outside the organization may use them.
  • Service registry and discovery. What does it mean to deploy an app today? How do you maintain a recipe for everything involved in a business “application”?

Here’s who we spoke to:

microservices ,monitoring ,security ,data ,software architecture ,enterprise

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}