CA’s Insights on the Current and Future State of Microservices
CA’s Insights on the Current and Future State of Microservices
Matt McLarty talks about how microservices offer legacy enterprises the opportunity to break down entangled monoliths.
Join the DZone community and get the full member experience.Join For Free
Learn how modern cloud architectures use of microservices has many advantages and enables developers to deliver business software in a CI/CD way.
How is your company involved in the creation or use of microservices?
We assist organizations—especially established enterprises—with their digital transformation. CA offers a number of leading solutions that help throughout the lifecycle of microservices adoption, including API Management, Application Performance Management, testing automation, and other capabilities. In the API Academy, we provide training and consulting to help organizations with their strategy, architecture, and design of APIs and microservices.
What do you see as the most important elements of microservices?
We take a big picture approach when helping companies change their practices and architectures. These organizations have many existing monolithic, legacy applications featuring a high degree of entanglement. They also have existing methodologies and process typically tuned for infrequent, large changes. They also often have authority concentrated centrally within their organizational structures. To get the most out of a microservice architecture—and out of digital transformation—all of these areas need to be addressed. Moving to microservices should also mean moving to more automated deployment and operations, and distributing authority and autonomy throughout the organization.
Which programming languages, frameworks, and tools do you, or your company use, to build out microservices?
We approach these projects from a bigger picture perspective and help guide the client in what makes sense based on what they are already using. Obviously, container adoption has a high degree of affinity with microservice adoption, as does the move to public cloud platforms or more cloud-native on-prem approaches (e.g. Kubernetes, Cloud Foundry).
How have microservices changed application development?
Microservices have been liberating for developers. Some of the complexity they’ve had to deal with in monolithic architectures (e.g. dealing with huge code bases, big regression tests) moves to the maintainer of the system, something my colleague Ronnie Mitra talks about. This allows developers to move more quickly, but it also means that someone or some group needs to be very conscious about designing and maintaining that system that results from the sum of all those microservices. This system maintainer role is one that I’ve seen some organizations struggle with as they try and put everything on autonomous, cross-functional, business capability-aligned teams.
What kind of security techniques and tools do you find most effective for securing microservices?
Two of my colleagues—Scott Morrison and Rob Wilson—and I recently published a book on API access control for microservices with O’Reilly. We go through the evolution of web security, web API security, microservices-specific security, and how all of these can be harmonized to provide defense in depth for organizations deploying microservices. Most importantly, we’ve devised a model we call DHARMA that can help organizations address microservice API security appropriately regardless of what technologies they are using.
What are some real-world problems you, or your clients, are solving with microservices?
We’re helping a lot of clients who are just starting to make the transition. For example, we have a number of financial services clients going through the process, recognizing that culture can be a bigger issue than the technology. One of the big items is trying to define service domains and boundaries. This is a very important step in breaking the business down that should affect how teams are organized in addition to determining the software architecture. I’ve published a blog series on this topic, including the introduction of something called the Microservice Design Canvas that provides a summary view of a service that is useful to those building the service, as well as to those using it. A few organizations are experimenting with the canvas, including Capital One.
What do developers need to keep in mind when working on microservices?
Even though languages like Go and Scala are becoming popular for microservices, I think the bigger learnings are around the system concerns. Developers should get to know Kubernetes and its concepts (clusters, pods, nodes, services). They should also explore reactive systems architecture (asynchronous communication, events) and the emerging functions-as-a-service space (e.g. AWS Lambda). As I said before, microservices can be liberating for developers, but it can also obscure the greater context of how their code operates as part of a greater system. Lastly, I think developers should focus on becoming business domain experts for the services they’re working on. That knowledge will transcend whatever tech they’re using.
Is there anything you’d like to know about what software developers are doing with regards to microservices?
How much are developers thinking about security and visibility? Is it top of mind? And who do they feel is responsible for the design of the overall system as well as who is observing runtime day-to-day? I am always interested in the macro concerns.
Do you have any concerns over the current state of microservices?
As with any popular tech trend, people can have a tendency to think it solves every problem, and they can also lose sight of the trend’s context. For microservices, implementers—especially those in big organizations—need to choose their battles. It is much better to take a slice of the system or the monolith and evolve that holistically—changing the architecture, methodologies, supporting org structure—rather than try and take one step across the whole org (e.g. “let’s put every application into containers”). We need to recognize that microservice architecture combines some new technological capabilities with common sense architectural principles. We know the tech will change again, but the principles should stand the test of time.
What’s the future of microservices from your perspective?
I think we’re at a point where people are very much focused on deep technical issues like service discovery and container orchestration. As the industry reaches consensus on these technical issues, I think there will be some disillusionment with the movement as organizations realize they can’t flip a switch and have microservices. They will need to address those system complexities that we as an industry have been trying to overcome for years: integrated ecosystems of people, process, and technology that need to change rapidly but where changes are difficult to implement and cause unpredictable results. I believe that the idea of breaking the system down into smaller parts to facilitate more frequent and less risky changes—the essence of microservice architecture—is the best approach to deal with that complexity, but it requires organizations to change their culture, and that is the hardest change of all.
Opinions expressed by DZone contributors are their own.