Should Every Application Leverage Microservices? Part 1

Here’s Part 1 of my interview with Philippe Guerin, 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.

Pete: What we're going to talk about today is the question around software architecture: Should every application leverage microservices? There's a lot of buzz around microservices. So, I want to bring you into the studio today to talk about what you think and what you are seeing regarding microservices. But before we go there, let's bring everybody along here, so maybe that'll help us with our conversation. In your view, what's an easy way to describe microservices?

Philippe: If I have to simplify the definition of microservices, it's a way to redefine a very small scope of service, which includes an interface, business rules which will process data, and, ideally, to also be autonomous in terms of storing the information. And then after, based on the interface and communication with other services around this guide, this will help to serve the actual functionality.

Pete: So it's a way of designing and thinking about the construction of applications and systems. Why is this fundamentally different than what we've done before?

Philippe: Because, before, it was really a question of global architecture, i.e. a global set of elements to serve a specific functionality. It's a bit like object-oriented but to an extreme. So you need to think, a microservice is like an object, but the not-elements object. So this one can run on its own and doesn't especially rely on the others. If you need specific information or services, it can ask a third-party for the specific action, or it can do the action on its own.

Microservices and Service-Oriented Architecture

Pete: It sounds a lot like the service-oriented architecture, SOA, that was popular, I don't know, ten years ago. Is it just really kind of the SOA on steroids?

Philippe: Not really, it's more of an evolution. The concepts are the same, but the idea of having microservices is not just to delegate the actual action to someone else and that's it. It's really about how to reuse those elements and to find a way to not be locked into a specific technology. For example, you can have one microservice in JEE, one in C++, one in Java, and one in .NET. The goal is to find the way they best fit, e.g. the best technology stack, in order to serve the app's specific needs. And once you have this service, it can also be delegated to a third-party platform. This way the app can provide more resources, have more memory and CPU, resecure the response time, and be sure that it will be optimal.

Pete: Evolution is a good way to think about it when it comes to continuing our thinking about reusability and the distributed architecture. But why now? What's driving everybody to think and talk about microservices today?

Philippe: I think there are two main things. The first one is due to the pressure from the business to be more agile, more flexible, and to increase the productivity and response time of the team. And it's for that reason we now have development which is closer to operations in order to push a lot of releases every week or every other day. The second driver is the need to be able to move applications or a part of an application to the cloud. And since applications or systems can be huge, sometimes it's good to maybe take part of the system and put this specific part of the system into the cloud, but the rest can stay in your network.

Obstacles to Adopting Microservices

Pete: DevOps, continuous integration, and deployment are driving some of these things because people want to have some more modularity to get functionality quicker, so obviously you need to be able to work on small groupings of functionality and then cloud, of course, everybody rushing to the cloud and trying to figure out how best to leverage that. I get that as a business owner, I think that makes a lot of sense, getting things out quicker and reducing my overhead. So why aren't applications today automatically microservice-based or leveraging microservices? What are some of the obstacles that you're seeing people run into?

Philippe: The first obstacle is not really the fact that it's working fine, it's working fine, that's not the problem. The challenge people have now is addressing the core systems, and these are huge, aged, and composed of various technologies/frameworks. It's very difficult to address this system as a whole. The struggle at different organizations is to break these monolithic applications into different pieces and to accelerate the release schedule. So, to be able to deliver faster, as well as delegate some modules, some services to some third-party system and the cloud.

Pete: So, net new, greenfield development, and cloud-native companies have the luxury of leveraging microservices because they have a blank canvas, per se. But there's a lot of legacy in our marketplace, a lot of customers that are dealing with not only legacy but monolithic systems that have been built over many years. And if they want to move those systems, decouple them or modernize how do people start doing that?

Philippe: You need to take baby steps. I want to clarify one thing; these types of decisions are not solely an issue for mainframe or legacy systems. It can be a monolithic Java or .NET applications. It's really any application which is difficult to segment. So then after their struggle on how to start, and because these applications are mission-critical, you need to enhance and you need to transform that application, but you need to be sure that this system will not collapse, or still provide services and value.

So for that you need to understand the as-is architecture, how it's structured, to be sure that if you don't know a specific layer or specific aspect, you will be able to investigate, define a plan, and then execute this plan. It doesn’t have to be a long approach, to rewrite from scratch into a microservice. Maybe begin by defining specific baby steps in a way to transform the presentation, as an example, and then after decouple different sections or modules.

That's all for Part 1! Tune back in tomorrow when we'll cover 'as-is' architectures.