To gather insights on the state of microservices today, we spoke with 19 executives who are familiar with the current state of microservices architecture. We asked them, "Do you have any concerns regarding the current state of microservices?" Here's what they told us:

Integration and Data

• Only about the culture surrounding them. Many junior developers see microservices as a magic bullet and talk as if it will solve all their problems. Well, it also introduces a fair amount of problems of integrating with persistent storage. The temptation in the tech industry is to treat technological improvements as a cure-all. I saw the same thing a decade ago when "cloud computing" was all the buzz only to find out that it usually swaps out intermittent failure problems with latency and noisy-neighbor headaches. There's always a tradeoff. I even had one of my more senior friends ask me if I was converting my base OS firewall rules into a microservice. Well, Host OS configuration is one of those areas that microservices can be much more cumbersome than a config management tool (like Puppet or Ansible). He works for Docker, so I let it slide but containers aren't the best design decision in every use-case. 
• There is a lot I want to see discussed at a more erudite level, perhaps nothing fit to print for this inquiry. For instance, we discuss microservice architecture as subdivided along lines of business units. In practice, though many business units have different needs around aspects of the same data services. How do we provide the right data for the right context, without making every data payload festooned with unnecessary attributes and layered JSON response collections? The ideal patterns for furnishing variations on application data and process flows to different business units is a complex question to answer. In all likelihood, it will remain case-specific. But I would be thrilled to hear more about other microservice implementations. I want to know if they solved this problem with parallel deployments of similar data-providing services drawing from the same underlying libraries and data sources, or with configured layering of API calls that intercept, transform, and route responses, or simply by encompassing the complexity of many needs into one service that responds appropriately given request parameters. These are practical questions that I deal with for each customer. If any of that made sense, feel free to share.

Complexity

• Every night I ask myself if all microservices are doing their job as expected. I see that the proliferation of microservices is up and there can be perceived as a loss of control over things.
• Microservices is not a free lunch. It lets you scale but it comes with its own set of complexities. Need to understand the organization and the architectural changes. Manage those changes within a deployment lifecycle in a decentralized infrastructure and architecture.
• There is still a lot of tooling you need to build out yourself, but this is rapidly changing.
• There is no “one size fits all.” Many languages, tools, and API gateways. Don’t get locked into one way of doing things you always have alternatives.
• I'm afraid the promise won’t be met because people cannot overcome the aforementioned challenges. By breaking up one app managed by one team people move into microservices without keeping their sights on coordination and collaboration. The process fails and they go back to their legacy practices.
  

Governance/Best Practices

• There’s a lot of education required around what microservices can and cannot do. What employees need are Microapps and microflows.
• Our greatest concern is the same concern shared across technology stacks – the implementation of a technology without a full and complete strategy put together for its long-term implementation and use. Microservices, being small, have many moving parts, and the more you have, the trickier it can become to manage and handle those services. Microservices is part of a bigger-picture strategic shift into what is best considered the twelve-factor application model, where there are at least a dozen core tenants you should have or implement as part of your shift into microservices.
• My biggest concern regarding the state of microservices is the possibility that an organization may not properly secure its endpoints. Due to the lightweight nature of microservices, it is not a prescriptive technology. By contrast, SOAP is governed by a standards body that ensures prescriptive security recommendations are provided. Microservices aren’t governed, so the potential roll-out is very “wild west”. 
• It takes a while to adopt best practices with patterns and use cases. How many open source projects? What should I choose from? What do I base my decision on?

Other

•  Most companies using microservices architecture see it as an opportunity to improve their development process. Build security in from the start.
• Pretty good relative to JavaScript framework. No EGB of microservices. Certain things are open source. Finagle is easy to bootstrap. The last 10 years every system has become a large-scale distributed system. Even most mobile apps are large and distributed. How to factor? How to monitor? Debugging large apps is a challenge. Object-oriented programming has become distributed programming.
• No, it’s not really a new concept breaking a larger application into smaller components to be more flexible and scalable. More ops work with ops overhead.
• I think it’s almost too easy to get started with microservices. For most projects, starting out with a monolith will still be the better choice. As you grow, you can always move into microservices, so the risk is the same as it’s always been: premature optimization.

Do you have any concerns with microservices that have not be raised here?

Here’s who we spoke to:

• Thomas Butt, CTO, CardCash
• Matt McLarty, Vice President, API Academy, CA Technologies
• Brian Dawson, DevOps Evangelist, CloudBees
• Lucas Vogel, Founder, Endpoint Systems
• Ali Hodroj, V.P. Products and Strategy, GigaSpaces
• Job van der Voort, VP Product, GitLab
• Kevin Sutter, MicroProfile and Java EE Architect, IBM
• Sandeep Singh Kohli, Director of Marketing, MuleSoft
• Karl McGuinness, Senior Director of Identity, Okta
• Ross Smith, Chief Architect, PITSS America
• Mike LaFleur, Director of Solution Architecture, Provenir
• Gianni Fiore, CTO, Rebrandly
• Peter Yared, CTO, Sapho
• Sha Ma, V.P. Software Engineering, SendGrid
• Keshav Vasudevan, Product Marketing Manager, Swagger/SwaggerHub, SmartBear
• Chris McFadden, V.P. Engineering and Operations, SparkPost
• Christian Beedgen, Co-founder and CTO, Sumo Logic
• Todd Millecam, CEO, SWYM Systems, Inc.
• Tim Jarret, Senior Director of Product Marketing, Veracode