Executive Insights on the Current and Future State of Microservices
Executive Insights on the Current and Future State of Microservices
Our research analyst spoke to 19 industry executives to find out the future of microservices in business, and their relationship to Agile, DevOps, and the SDLC.
Join the DZone community and get the full member experience.Join For Free
How to Transform Your Business in the Digital Age: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.
To gather insights on the state of microservices today, we spoke with 19 executives who are familiar with the current state of microservices architecture. Here’s who we spoke to:
Matt McLarty, Vice President, API Academy, CA Technologies
Brian Dawson, DevOps Evangelist, Cloudbees
Lucas Vogel, Founder, Endpoint Systems
Thomas Butt, CTO, Cardcash
Ali Jodroj, V.P. Products and Strategy, GigaSpaces
Job van der Voort, V.P. 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, Cofounder and CTO, Sumo Logic
Todd Millecam, CEO, Swym Systems, Inc.
Tim Jarret, Senior Director of Product Marketing, Veracode
1) The most important elements of microservices are speed, decentralization, and size. The ability to decouple and deliver application functionality faster, with greater stability and agile methodologies, is a tremendous benefit to the organization and its end users. The speed of new feature development, ongoing maintenance, and the day-to-day work of deployment and testing is very rewarding to everyone involved.
Microservices address the architectural bottleneck with decentralization and the isolation of responsibility and faults, as well as autonomous, local data sources. Breaking code into smaller pieces results in shipping less code more often, with smaller feedback loops. This results in components that are easier to manage, maintain, refactor, and control.
Microservices and DevOps go hand-in-hand. There’s a reciprocal relationship. To deliver microservices as a core part of your architecture, you need the components of DevOps: agile development methodologies, CI, and CD. Likewise, decoupled apps are difficult to deliver without DevOps. Implementing DevOps helps to deliver decoupled apps faster.
2) The most frequently mentioned languages for developing microservices were Java and Node.js. There were more than35 different languages, frameworks, and tools mentioned that demonstrate the multitude of ways developers, engineers, and architects are building microservices architectures.
3) Microservices have improved SDLC best practices, speed, agility, flexibility, and alignment of the software with the business. Microservices are the embodiment of software development best practices: simple code, easy to maintain, easy to train other developers, good habits like encapsulation, isolation of complexity, autonomous development teams, and breaking down silos between applications. They are also symbiotic with DevOps with more frequent deployments, automated testing, zero downtime deployment, and easier rollback.
Legacy enterprises with monolithic apps become more agile to enable digital transformation. Microservices provide faster speed to market and realization of value with cloud scaling. This supports an agile approach to development. Smaller components allow for meaningful changes with leaner teams, resulting in faster responsiveness to the market.
Lastly, microservices align to business objectives and full-stack teams are aligned to customer value. Deployment is aligned with operations and teams are more collaborative because microservices are inherently more collaborative.
4) The most frequently mentioned security techniques for microservices were using APIs and API access controls and gateways. You need to put together standards for access control in the API architecture with certificates and tokens. Require an API gateway key or login. API gateways provide many great out-of-the-box management services in addition to security. APIs are an effective way to build governance into the microservices architecture. SLAs can be managed through API gateways that act as proxies for the microservices. This ensures there is a proper balance of governance for IT and flexibility for the domain teams.
5) A key “real-world” problem solved by microservices is the decoupling of monolithic applications so legacy enterprises can pursue digital transformation. Microservices force you to break your problems down into buildable pieces. Critical components that were previously part of a monolithic application can now be easily extracted and rebuilt in a way that doesn’t interfere with the rest of development. Decoupling = faster development= faster time to market = greater revenue (as demonstrated by Netflix, Google, and Amazon).
Pitney Bowes is making the digital transformation to an open-commerce cloud that’s accessible by APIs. 130-yearoldUnilever has created a large number of microservices to support its continued growth, enabling the company to connect its e-commerce applications to the various legacy systems that support its core operations across a global portfolio of brands. They are pairing their microservices architecture with API-led connectivity to drastically reduce development time for new e-commerce applications.
6) The most common issue affecting the implementation of microservices is the amount of change required. This is yet another operational and developmental paradigm shift. You have to face the initial configuration and driver setup costs to connect your service to different protocols. The architectural maturity of an organization is often the greatest hindrance to adoption and implementation. Clients frequently need new employees, new process models, and a new hosting infrastructure to get the most out of a new microservices architecture. As such, we focus on educating customers on the options that best fit their situation.
7) Concerns over microservices are consistent with those of other new technologies: integration and data challenges, complexity, and lack of governance or best practices. Microservices introduce problems integrating with persistent storage. You need to determine how to provide the right data for the right context without making every data payload overloaded with unnecessary attributes and JSON response collections. Parallel deployments of similar data-providing services drawing from the same underlying libraries and data sources.
There is no “one size fits all.” There are many languages, tools, and API gateways. Microservices let you scale but come with their own set of complexities.
Microservices aren’t governed, so the potential roll-out is very “wild west.” It will take a while to adopt best practices with patterns and use cases. That’s why it’s important for early adopters of microservices to share their experience – both good and bad.
8) Serverless and functions-as-a-service are clearly the future of microservices according to our respondents. Acceleration to the cloud, integration, and greater reuse were also elements of the future. Greenfield apps will be serverless with event-driven programming and progressive web apps. The move to on-demand compute resources and serverless architectures will grow. Lambda is disruptive and microservices will extrapolate to serverless with Lambda.
In addition, microservices will drive the adoption of, and integration into, the cloud. There will be improved integration with microservices, sharing and tying multiple microservices together. There is also greater potential for reuse. Reuse will take a different frame of reference from the production of reusable assets to its consumption.
9) It seems developers need to keep everything, including the kitchen sink, in mind when learning microservices. Given the breadth of answers provided, perhaps the most inclusive suggestion was to look at the twelve-factor application methodology, since there are at least a dozen things to keep in mind and developers would do themselves a huge service to use the twelve factors as guidance in their implementation. In addition to the 12 factors, be open to continuous learning given the breakneck pace at which technology is evolving.
10) Other issues to be considered early in microservices’ development include: 1) Why aren’t there more competitors in the space? 2) How will we staff, develop, and maintain a microservices architecture moving forward? 3) What’s the real cost of maintaining a microservices infrastructure? 4) What’s the best way to monitor hundreds of containers with microservices? 5) Moving to serverless, how do we shift identity and architecture best practices?
Published at DZone with permission of Tom Smith . See the original article here.
Opinions expressed by DZone contributors are their own.