What's Unresolved With Microservices?
Given that microservices is still a new technology, there are plenty of unresolved issues. These industry executives offered us their insight.
Join the DZone community and get the full member experience.Join For Free
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, "What have I failed to ask you that you think we need to consider with regards to microservices?" Here's what they told us:
- I think everyone needs to think long and hard about how they intend to staff, develop, and maintain their architecture going forward. Microservices allow (and sometimes encourage) variety. This means either retaining a stable of superstar developers, or a rolodex of vendor partners who help with different aspects of your ecosystem. In either case, the sharing of resources across lines of business units is of vital concern, and whether these are paid on the basis of operating expenditure or more of a quarterly cap model. As radically as microservices change our technological landscape, they multiplicatively affect the way we do software work - and we must have a sensible way to align those costs to the revenue they generate.
- Probably a question about the cloud and machinery costs of maintaining microservice infrastructures. Try to create a chain of microservices and to apply whatever autoscaling strategy to it: you can lose control on your architecture size, and then on your costs.
- Think about things as you would with regular app just do development correctly building in security and well-developed APIs.
- Monitoring -- there is a challenge here in making sure everything runs well, even if you have hundreds of containers with microservices: how do you monitor uptime, performance and other metrics in a constantly changing cluster? At GitLab, we believe this will be done with modern monitoring tools, such as Prometheus and tracing tools, including OpenTracing.
- Function as a service and event-driven architecture. Instead of containers, using Lambda. As have event-driven architecture how do you shift identity and architecture best practices? It may be different based on the API gateway. Extensibility for SaaS products.
- Better understand the architectural details. What’s the dividing line for functions? What’s the right size? Microservices enable but require a new approach to deployment – rolling, blue/green. What are the best practices of microservices deployment.
Do you have any additional concerns about microservices?
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.