Should Every Application Leverage Microservices? Part 3

Here’s Part 3 of my interview with Philippe Guerin (you can find Part 1 here and Part 2 here). He's a super smart guy and well-rounded technologist with many years' experience helping organizations with software architecture and helping technologists within large corporations. He works with industry bodies to develop and educate the market on software standards around sizing and measuring software. He's an accomplished author and speaker, and he's a fine baker of baguettes. You can listen to the full interview here.

The Role of Operations and Microservices Architecture

Pete: What about the role of operations? You mentioned the cloud as a driver. Do you see that there's greater participation from the Ops side of the house that's saying, 'look, this is what we need,' or this is what we see being successful? Microsoft publishes the blockers and the benefits for how applications should be structured to operate in the cloud. Microsoft has a perspective on how the application should behave somewhat. Do you see the operations side getting a say in some of the architecture?

Philippe: I think the operations side helps to translate these constraints, because it should be viewed as a constraint, and not as some rules to apply. So, for example, the business or the need of the development team will try to maybe introduce a specific concept or push an application into a specific platform, and then after the actual best practices or constraints of the ecosystem need to be viewed as something you need to handle with your code. But it should not be the driver of your development.

Pete: That's a great distinction. So operations brings the limits of their environment and the opportunity within their environment and shares that back with the development side to help them make better decisions.

Philippe: Because it is, at least, the layer and liaison with the actual end-users. Because Ops will have a look at the actual performance, the actual number of user connections, and so on. So it's good feedback to them, I mean, listen to what's going on, and then react very quickly.

Advice for Young Architects

Pete: I want to go back to your point about the skills issue around a full-stack developer. So you're a lifelong engineer, developer, software engineer, what would be your advice to a 25-year-old kid who wants to grow in this capacity? How can they understand it better, how does learning another language help, or are there more ways to kind of enrich their understanding of architecture and these principles?

Philippe: For me, it's really a language. Like a language, we need to translate a specific message and technology language should be viewed like that. So the concepts are the same. What you need is to start from the actual use case that you need to implement, what you need to provide at the end in terms of services, and then, after that, look at the frameworks and languages like a catalog, a catalog of software, to see what is good, what is not good, the different constraints. And then pick the right one. And if you make a mistake, it's fine. As soon as you control and you know why you picked that framework or language it's just a question of rewriting. So if you make a mistake on microservices there is a scope of rewriting that will be small because it's relatively distant and you have some API, some interface.

You can rewrite very quickly, so you can do a sort of prototype in, I don't know, in Python, and then after if you need to have some other languages, like .NET, you need to rewrite that, so at least you have a prototype, you know what the business rules and everything are, and you can start implementing that. So don't be afraid, the most important thing is that you don't go too fast to start. And then, if you do make a mistake, you can just learn from your mistake and it's okay.

Pete: You mentioned a couple of ways to get started throughout, in terms of breaking it down, but just to bring this home, I know you have spoken at the O'Reilly Software Architecture event on this topic. Let's give the audience your high-level view of how do you start breaking down these components. What are the key steps that you see?

Philippe: The key step is to not start to break the monolith directly — it's to understand the beast. So first, attack the frontier, the boundary of your application by revamping, by studying, by exposing services to see what's going on and how we can do what we want to do. And then start to decouple a little bit, the layers, and address those issues. Maybe by putting in some specific interface, forcing you to introduce something the taxes layer, for example, or to start introducing some messaging sometimes too, it can help at the beginning. And then, once you have that, you should start to review your application more vertically or transactionally if you want. By functionality, I mean looking at the code in order to really see what kinds/groups of elements should belong together. And then you can start to evaluate the amount of interface you need to put in place in order to make one functionality relatively autonomous.

And for that, you need to start based on the actual usage of those transactions. If it's critical or not, how do you use or not, so those kinds of metrics will help you to define a priority list. And once you have that, you can start also within your system, how to define the core competence which is highly used by a lot of transactions, for example, to secure them, maybe to start putting some interface before and after these guys and start to rewriting that small component. And maybe this will be your first microservices. And you can delegate this kind of core competency to some other platform in order to increase the stability of your system.

Pete: So that was a lot. But let me go back to our original question. So clearly, not every application should leverage microservices. But do you think in five years all systems will be microservice architected?

Philippe: All systems will be driven through services and by exposing elements. The next challenge is to reuse those services. Because I see a lot of clients who are more focused on publishing UPIs, publishing microservices, but every team is rewriting the same kind of service on their own boundary when there is no coordination or enforcement for using a third-party service and not rewriting your own service. So this needs the big picture of the system, and I think this is the next challenge.

Pete: Who owns the service after it's published? And who maintains that service? Is it a collective agreement?

Philippe: It's a collective, it's a DevOps thing. It's the team. The team needs to continue to enhance, to increase performance, adding functionality, so it's definitely the entire team, it's collective ownership.

Pete: Can you envision someday where we have a bunch of micro legacy applications? Just think about the blooming of all the microservices out there. And over five years, people move, ten years, people forget, you know, fifteen years, people have no idea. It's just an interesting kind of dynamic. Will we set ourselves up for a huge legacy problem, small albeit, but multiplied a billion is a pretty big problem, someday?

Philippe: The journey will be exactly like the journey for microservice. You have a baby step, the next step, you have a challenge, and you try to resist one, right now our challenge, to increase the activity and the response time is to be more agile, more flexible with the team, so it's to go and use DevOps, and for that, you need to be also able to leverage different technology, different element of platform and microservices for that.

Pete: But I'm going to coin the phrase microlegacy. So ten years from now we'll get back here and talk about it. I just want to recap. We spent a lot of time kind of talking about what microservices are, what's driving them in the marketplace in terms of DevOps, and moving to the cloud, and then recapping all the challenges out there, moving from core systems that are large monolithic systems, and understanding your as-is architecture. And then carefully taking baby steps to define what to be architectures are and then starting to slowly pull those things apart and get them into a form that really gives you the ability to be more responsive to the market, improves the productivity of your individual development and your delivery teams, and also being able to be more agile and flexible in the cloud.