These concerns are consistent with other new technologies: integration and data challenges, complexity, and lack of governance and best practices.
Join the DZone community and get the full member experience.Join For Free
Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.
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.
- 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”.
- Most companies using microservices architecture see it as an opportunity to improve their development process. Build security in from the start.
- 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
Opinions expressed by DZone contributors are their own.