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, "Do you have any concerns regarding the current state of microservices?" Here's what they told us:
- An area going through interesting and dramatic innovation, solving for how to know if something is going wrong when it’s going wrong – observability. Manage, debug, reason about distributed systems is harder than a single codebase on a single laptop for a single process. Ability to do distributed tracing through the whole system is necessary. Think about up front, not after the fact.
- I was concerned a year ago that the networking view would take longer, but Google pushed ISTIO and its very good now. This has taken care of communication in a highly distributed network. How to make microservices as self-contained as possible. Have to do quite a bit of figuring. Will be taken care of by the big cloud providers.
- Organizations will misapply, misunderstand, and fail to understand the complexity of microservices. Try to do too much without understanding what you are trying to achieve. Be careful biting off more than you can handle. Be realistic and realize microservices are not a magic solution to every problem. You need to be good at monitoring, logging, and diagnostic. Without monitoring, you are not able to see where the problem is.
- The first concern every organization has is around complexity, and the solutions to increased complexity are enhanced automation and operational visibility; however, these product categories in the microservices realm are so bleeding-edge that real-world implementations consist of wiring together volatile open source initiatives using an assortment of random blog posts and sheer force of will. This is not the solid bedrock on which large enterprises would like to rest their mission-critical systems. Successful programs require a deliberate, measured approach.
- From our perspective, developers are just figuring out how to deal with some of the challenges introduced by distributed, decoupled applications. Core business processes that were once cleanly contained within a monolith are now spread across many different microservices. It’s really important to have visibility into these business processes—to know the current state of the business, to see when something has gone wrong, so problems can be quickly addressed—but most microservice monitoring tools were built with single services in mind or concentrate on relatively short call stacks, rather than long-running, cross-microservice flows. Many companies haven’t started to think about the impact microservices are having on the quality of their core business processes, and this is a challenge that’s going to need to be addressed before microservices architectures can move entirely into the mainstream. We’ve observed at a couple of customers that choreographed microservices get a lot of hype, meaning that the microservices use peer-to-peer or event-driven communication and often neglect orchestration completely. That means that workflows emerge out of event chains during runtime. These customers quickly lose sight of their end-to-end flows, making it at least hard to change anything in the flow. It is also very hard to monitor these flows providing a good level of visibility, which can be beneficial during operations as well as to improve your flows. Adding the right level of orchestration into the mix, without violating service autonomy and loose coupling, is highly beneficial but often overlooked.
- A lot of users and customers are past the initial hype and confronting complexities like troubleshooting and understanding performance anomalies. We have glitches and errors we didn’t see in the past with traditional virtual machines. Problems are not easy to pinpoint and identifying the root cause can be hard. This relates to the overall complexity of microservices. Just running an app with microservices in production is more complex than we thought, and we are confronting a lack of maturity in tools to monitor and troubleshoot which delays the ability to put into production.
- When tiny organizations adopt microservices and don’t know why or they’re doing, or they are doing so because Google is. Microservices are natural for any organization trying to build powerful, scalable software. Small shops adopting microservices because of their desire to be on the cutting edge is not beneficial. You don’t need 10 services per employee. Also, the terminology has led people to think they need to be completely independent. We need independent business logic but not technology choices. Make technology choices in a vendor-neutral way so vendors can fight over you. Don’t allow teams too much independence since this can lead to vendor lock-in.
- Because there is nobody overseeing standards, there are different definitions or understanding/interpretation of definitions. Monolithic applications, service should do a discrete function. Lack of standards body has resulted in confusion. There are differences of opinion about how to get there.
- Dogma and factions are the biggest. We are reaching a point where microservices has matured and people are getting strong opinions. Become too strong and forgetting why we went down the path in the first place. Focus on solving business or technical problems rather than semantics. There’s no one right answer for all things.
- Enterprises are still experimenting and learning how to use and adopt microservices. There are not enough best practices developed.
- It's early but we see people going in and struggling. The hype has gone up, people are confronted with difficult decisions about tradeoffs and they need to evaluate if microservices is the right approach. Building applications for cloud platforms with the assumption things will fail is an area where as many architectures as possible should go toward technology. How to go to new technology with different premises.
- People look at service, pick up Kafka – its working, it’s fast. But then they start having performance issues because it won’t scale. Once you push past 500 to 1000 topics you start stressing a Kafka cluster out. To be pervasive those type of problems need to be solved. Kafka helps fulfill a need, but you’ll run into problems. Solve the problem you have for the best way in your business.
- It's easy to put up microservices without realizing security implications. Microservices almost gives you carte blanch because they are disposable, people think about redoing tomorrow and forget about it.
- Do not rush into refactoring your codebase to microservices unless you do it responsibly with the right mindset and understanding of what it entails. Implement in the right approach or you will get a backlash and go back to a monolithic approach.
- A lot of hype. People are realizing the real challenges. Our customers see internal culture is the main challenge. Adapt to business capability oriented teams and agile technology. Too fine-grained services = thousands of microservices. This is a nightmare for small and medium-size organizations.
- Microservices are useful to speed up product development and time to market but there are concerns around operationalizing services. Pushing services out is fun and easy but if they are not run properly with the correct tooling, they fall over, and the impact is exponentially worse with each microservice you add. To try to solve for this, companies have hurried to adopt tens (if not more) of best-of-breed point solutions that don’t talk to each other and cause more confusion. GitLab as a product helps bring some order to the chaos by using the CI/CD pipeline as the gateway to effective DevOps that is all in a single application.
Here’s who we spoke to:
- Heikki Nousiainen, CTO, Aiven.io
- Chase Aucoin, Technical Evangelist, AppDynamics
- Assaf Mizrachi, Head of Software and Amit Ziv-Kenet, Backend Developer, Augury
- Bernd Ruecker, Co-founder and Developer Advocate, Camunda
- Jaime Ryan, Senior Director, Product Management and Strategy, CA Technologies
- Brian Dawson, DevOps Evangelist and Viktor Farcic, Senior Consultant, CloudBees
- Chip Childers, CTO, Cloud Foundry
- Gwen Shapira, Chief Data Architect, Confluent
- Matthew Baier, COO, Contentstack
- Anders Wallgren, CTO, Electric Cloud
- Priyanka Sharma, Director of Alliances and Andrew Newdigate, Infrastructure Architect, GitLab
- Ben Sigelman, CEO, LightStep
- Jim Scott, Director, Enterprise Strategy & Architecture, MapR
- Ariff Kassam, Vice President, Products, NuoDB
- Jim Walker, VP of Product Marketing, OverOps
- Bich Le, Chief Architect, Platform9
- Mike LaFleur, Global Head of Solution Architecture, Provenir
- Christian Posta, Chief Architect, Cloud Application Development, Red Hat
- Setu Kulkarni, V.P. Strategy and Business Development, Whitehat Security
- Asanka Abeysinghe, V.P. of Architecture – CTO Office and Kasun Indrasiri, Director, Integration Architecture, WSO2
- Roman Shaposhnik, Co-founder, Zededa