Should Every Application Leverage Microservices? Part 2

Here’s Part 2  of my interview with Philippe Guerin (you can find Part 1 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.

Understanding 'As-Is' Architectures

Pete: You spend a lot of time helping people look at their as-is architecture, and it's frequently a manual approach. What are the other ways people can understand what's inside their software and how it's composed?

Philippe: The point is to first read an architecture through the functionality. Because if you have part of the system or an actual layer or module which is autonomous, and it's working fine, and you don't need to enhance it, you don't have to touch it.

So, first, eliminate any areas that don’t need to be touched, put them off to the side. These kinds of already stable system parts and then, maybe on top of those, find a way to expose more services to be sure that those very core and stable modules will be useful for some other layers. One approach is to start from the front, to first revamp the presentation layer, by replacing the presentation layer with a JSP layer, or a rich client layer, for example. And this will help you to identify what the first level of services in your business core is using, and, after starting it up, you can put in some APIs and export services, force your new presentation layer to communicate and leverage the below layers through that specific API layer.

The point is to be sure that as soon as you need to transform the architecture be sure that you're not losing the focus. The idea is not to have to introduce some new technology like a new SQL database, and so on. It's to find a way to identify what kind of technology can accelerate future enhancements or bring some new set of functionalities.

Pete: It’s an interesting challenge, in a way where we're talking about speed and getting functionality out there quickly. But having to do this massive amount of analysis and discovery of older or gigantic systems sounds like a disconnect between what people need to be doing and what they must be doing to meet business needs. 

Philippe: It's a lot of work and people don't appreciate the effort when you transform a system. You need to find a way to balance the system with low risk. For that, I spoke about the presentation layer first, introduced some REST APIs, and so on, but, at the same time, you need to start thinking about the response time. When you think about REST, for example, and its synchronous call, so you need to be sure that, at some point, you will decouple the different layers to have some synchronous calls in their virtual systems. You can do this by leveraging some MQ or another system, in order to be sure that you keep this flexibility on the response side.

Pete: We have all this pressure from the business to move faster, and all this legacy and monolithic, complexity and technical debt. Are businesses equipped to handle this? What shortfalls do you see within businesses that are hindering their ability to act quickly to fix this problem?

Philippe: This new wave of technologies introducing some new challenges. Previously, we used to have a very good developer on one technology. Now we need to have someone very good on four, five, ten different technologies, knowing what kind of frameworks, and who's able to shift from one framework to another one. And it's very difficult. If you don’t have those types of people, you need to find a way to organize a team in an agile way. This shifts the constraints more on the organization of your team.

It puts a lot of pressure on the development team, but, at the same time, it helps to have collective ownership. With an agile approach, we have a manifesto and this helps. So we have the team in charge and make sure that they are accountable and happy when everything is going well.

Pete: So, there's a skill gap, right? And organizations must have individual developers who are proficient in specific technologies who also have a broader full-stack understanding. There is a team component of being able to organize and think about operating as an interface layer, a database layer, we need to be more horizontally oriented. And I'm wondering what came first? Did DevOps come first and then this need to modernize, or was modernization always in the background, but DevOps and Agile maturity were not there yet for people to start tackling the problem?

Philippe: These are all characteristics and they evolve at the same time. So you know that you have a team that's very agile with which to start your microservices approach. You don't need to start from scratch with a new set of technologies. What you need is to be sure that you will accept having to develop the model, develop a set code, and then to revisit it many days later to enhance it, adopt different strategies, to create an interface, split your elements into two in order to reuse your components in other services, and so on. So, it's like life or the body.

Pete: Architecture is like life! What you're saying is, it sounds a lot like agile architecture. There's an incremental architectural approach that fits within the current way that we deliver software today. Do you believe that?

Philippe: I do believe that. And this also adds additional pressure and the need for coordination on the enterprise, in terms of architecture. You need to define the approach, the targeted architecture, and be sure that the architecture you define or design for your system will be compatible with the rest of your ecosystem. Because it's a shift of complexity from something centralized by technology, by the application. And now you will rely on it, which is good for stability, but, at the same time, its complexity will increase, you will rely on a lot of other applications if you want to have a good response time and service provided by your application.

That's all for Part 2! Come back tomorrow when we'll wrap up by doling out advice to aspiring architects.