eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
CA: Microservices Could Lead to Software Factories
The thing about banks is there is a lot of centralized power because it is a centralized industry. Microservices and Agile are part of this decentralized movement to split things out. That is important to empower teams and allow them to make mistakes. But banking is a cultural control thing.
I talked to one bank that just got a new CTO who came in and said we’re going to do everything microservices. We’re going to write all of our applications in Node.js, we’re going to do APIs everywhere. That just isn’t going to work. You really need to focus on why you want to do these things and what are the goals you want to accomplish. I think an iterative approach is as much a part of this whole microservices movement as are small services.
I noticed that when you talk about microservices you bring up the old Ford Model T automobile. What is that all about?
In the technology world we always feel like we’re on the cutting edge. But if you take a broad view, software engineering as a discipline is pretty young. And we spend so much time trying to solve requirements that we spend not enough time thinking about the craft of how we build and architect software. So I was likening where we are in the software engineering evolution with where the transportation industry was 100 years ago.
I was comparing the monolithic systems to trains, where there are a lot of dependencies and you have to wait for other people to get on the train. You’ve got to lay down a lot of expensive infrastructure. And then cars came along and changed that. You can have your own car, you can drive where you want to go and you’re not dependent on anyone else. That’s like microservices. Then with Docker you’ve got a container technology that is like an assembly line for software.
So we’re kind of there, but there is a lot more we have to do in the software engineering field to mature in the way that the automotive industry matured 100 years ago.
I think it’s good to keep people humble and thinking about the craft. When I get the opportunity to drop down and do code myself, I’m always amazed at how many cumbersome, manual steps are still required to do things—like command line stuff and compiling. It would be nice if things were a lot more out of the box.
So do you see the world moving anywhere closer to the “software factory” capability we used to hear about?
I think that if we as an industry are to scale software to meet growing requirements of the internet of things, we need to scale out the software engineering job market so we can be able to handle this. Right now there’s a lot of power with developers. People that can code get to call a lot of shots. It’s a very exclusive community in some respects. If we can make things more accessible for software engineering overall, it will benefit the economy because not only will we be creating all these new things that will be helpful in a digital economy, but we also will be creating jobs.
So are we on a trajectory to make that software factory? Not necessarily, because the coders themselves are quite comfortable writing that code. They like to have knowledge that nobody else has, but I think it’s going to take a lot of force and energy from leaders in the industry to push down a path where we are more accessible and we do create software factories.
What do you mean by accessible? More citizen developers?
Yes, more citizen developers, but if we look across a cross-section of society there’s a whole lot of creativity. Right now, the software developer gets stereotyped as this person who thinks in algorithms. You shouldn’t necessarily have to think in algorithms to be able to contribute to developing software. If you’re a creator, if you’re a maker, you should be able to be given tools that don’t require you to go in and start doing algorithmic development.
CA: Microservices Could Lead to Software Factories
A big area I’m researching is around visualization. Software developers like to whiteboard and draw, but there’s a big disconnect from moving from the whiteboard to a mental model into code. It would be great if we could make that a more immediate thing, where we could craft something visually and then that actually generates the digital piece—whether in code or whatever it is. Then you have this more immediate back and forth where you can change the code by changing the visualization.
That sounds like an advancement of the old software modeling play?
I think it’s a much healthier model for everybody, rather than trying to figure out how we can make an individual developer 100 times more productive. For instance, there are software developers now that have agents like they are rock stars. So instead of trying to get more of them, we can broaden the scope of jobs so we can get everybody involved. Everyone’s scared about losing their jobs to computers, but we need to think about how we can create more computer jobs for people.
In the software community there is more affinity between developers, or especially architects and artists. I meet illustrators or musicians that can adapt to the software world. That creative thread is just as important as the technical thread. The problem is it’s table stakes right now to have that whole technical, mathematical mind, whereas it would be great to just level the playing field.
Who do you view as competition?
On the software product side, we have competitors. But the type of stuff we do is similar to what consulting companies do. But we collaborate with those companies. We’ll work with big Sis where they might be starting up an API management practice. We’re a small group. There are only four of us and there are some alumni and community.
Our goal as the API Academy is to help educate the industry and help share. And anyone who’s in the same domain is helping our cause. What makes us different as part of CA is that our mission is mutually exclusive from the software mission. Some of our software competitors might do what we do by talking about APIs and the digital economy, except it’s much more tightly coupled to their product business. What we say is here are the things you need to do regardless of what technology you use. We try and do something that’s a little bit more consultative.
So you do have consulting projects that you work on?
We have engagements where we work with companies and do these boot camps where we come in and get a bunch of stakeholders in a company—software architects, business people, developers and operations people—together and go through all the areas that are important when you’re employing APIs or microservices. And we do that in a condensed session.
We try to use the community concept. We know we can’t scale to meet everybody’s needs, but we try to partner and endorse and connect the dots with companies we know are really good.
How big of a deal is it to get microservices adopted into the culture of an organization?
It’s both really important and really hard. I think that culture change is really hard to do. I’ve seen it time and again where people can’t deal with culture change. We try to bring the stakeholders together so they can break down barriers. Trying to do big-bang culture change never works.