CA Technologies, which focuses on helping enterprises transform for the application economy, has delved into the DevOps and Agile development spaces with product and services support. The company also has amassed some serious microservices expertise with its API Academy, as it works to help empower developers to more easily build software, perhaps even leading to software factories. In this Q&A, Matt McLarty, software architect and vice president of the API Academy at CA, explains microservices, the API economy and where the technology is taking us. McLarty is the co-author of O'Reilly's Microservice Architecture: Aligning Principles, Practices, and Culture.
What is your definition of microservices?
That can be answered in one sentence, or in an entire book. Here's as succinct a definition as we could come up with for the book we wrote: "A microservice is an independently deployable component of bounded scope that supports interoperability through message-based communication. Microservice architecture is a style of engineering highly-automated, evolvable software systems made up of capability-aligned microservices."
But that just scratches the surface. There are many associated factors. The best description of those is in a blog post from James Lewis and Martin Fowler. I see "microservices" as a software architecture movement that has come out of the Agile software development movement by way of DevOps. It has similarities and differences with the SOA [software-oriented architecture] movement. Lastly, maybe the best way of describing microservices is through what it intends to deliver: speed of delivery in harmony with system safety at scale.
How did you folks get into microservices?
A couple years ago being in the API space heavily, I saw this trend starting to emerge. Everybody started talking about microservices. We were quite experienced in the service-oriented architecture domain and we were like this sounds kind of like service-oriented architecture. But the more we got into it we realized there were similarities but this is a new thing. Because it really came off the back of Agile and DevOps and continuous delivery and that kind of movement that started with Agile and kept looking towards delivering software in a very fast way. There was a continual removal of roadblocks. Agile removes the roadblocks around developing software. And then continuous delivery removes roadblocks from deployment, DevOps removes cultural roadblocks. That's where the microservices movement came in, with the removal of the architectural bottlenecks.
So because APIs are so central to microservices, we just collided with that. For the last couple of years we've just been getting deeper and deeper into microservices. And we just wrote this book for O'Reilly on microservice architecture.
I think the industry is now at a point with microservices where now it's a shiny new thing and everybody is looking at it as a silver bullet that can now solve all their problems. And now we've got enough maturity around the movement to see companies that know what works, what doesn't work, what prerequisites are required and what are some of the associated things you need.
What are some of the industries that are adopting microservices? Who is ahead on this?
I would say that web-based businesses, period, are ahead on this. If you're a company that is managing web-based infrastructure, it's easier to adopt cloud-based infrastructure. You're more likely to be doing continuous delivery practices and frequent deployments. And it just so happens that retailers like Amazon —though Amazon is not even just a retailer anymore—are on the forefront of it. So I think e-commerce is big in there, but pretty much any cloud-native or web-native company is ripe for it.
I've seen banks or financial services institutions come later to the game. What happens with banks is nobody wants to be first. A lot of the folks from the financial services industry that are looking at this were very invested in service-oriented architecture. That's where we get a lot of the skepticism around it as people ask, "Well, how is this different from SOA?"
The answer is that you could make all the same mistakes that were made in the SOA movement, but what we're trying to do here is promote really good cultural, organizational aspects that are just as important as the technological pieces.