Q&A

Q&A with Alon Fliess: To Microservice or Not to Microservice? (and How?)

• By David Ramel
• 09/02/2022

The microservices architectural style is one of the foundational pillars of today's cloud-native development world, along with modern design, containers, backing services and automation.

Microsoft documentation says microservices -- built as a distributed set of small, independent services that interact through a shared fabric -- share these characteristics:

• Each implements a specific business capability within a larger domain context.
• Each is developed autonomously and can be deployed independently.
• Each is self-contained encapsulating its own data storage technology, dependencies, and programming platform.
• Each runs in its own process and communicates with others using standard communication protocols such as HTTP/HTTPS, gRPC, WebSockets, or AMQP.
• They compose together to form an application.

Microservices also help address a major pain of the modern architect: being increasingly asked to do more with less.

"High cohesion and low coupling, high availability (24/7/365) and scale, ease of deployment and operation with modern DevOps -- our systems need to support all these quality attributes while providing more functionality with fewer resources," says Alon Fliess, chief architect at CodeValue. "We need to be agile, we need to embrace changes, we need to have a better way!"

Fliess should know, with more than 25 years of experience in major software development, design and architecture for global leading- and cutting-edge companies, and having been named a Microsoft MVP every year since 2005.

He's bringing his knowledge and expertise to the Microsoft-centric development world in November in a presentation at the huge Live! 360 developer conference in Orlando, which encompasses five separate conferences in one six-day event spanning Visual Studio, SQL Server, TechMentor, Artificial Intelligence and Cloud & Containers.

It's in that last show that Fliess will be sharing his expertise in a presentation titled To Microservice or Not to Microservice? How? on Nov. 15.

We caught up with Fliess ahead of his presentation on Micro-Service-Architecture (MSA), wherein he promises that attendees will have a better understanding of why, when and how to embrace the MSA approach, specifically learning :

• About microservices
• Dos and don'ts when embracing the microservices approach
• About migrating your solution to microservices -- evolution vs. revolution

Here's what he had to say about MSA and his presentation.

VisualStudioMagazine: How does the Micro-Service-Architecture (MSA) approach help architects who are increasingly asked to do more with less?
Fliess: Most software projects today are big and complex and must be flexible and support new needs. Using one giant monolith solution tends to be hard to maintain, grow and adapt. The microservice architecture approach breaks the monolith into smaller parts. Each part can evolve separately, change and answer new requirements. In addition, using the MSA approach enables better project management allowing the dev team members to work concurrently.

What's the best way to get started with MSA?
Attend my lecture :)

If you already have a software project, you don't need to throw it away and start from scratch. Instead, you can take a small part of the system, a feature that does a single action or is responsible for a separate functionality, and convert it to a microservice. Then, let the old system code call the service, and if there is a need, wrap some of the old code with a service interface to allow the new service to use the old code. Be careful not to create a distributed monolith, which means that a short analysis phase of the system is a must.

If you want to practice before starting a new project, take a simple problem -- a project with few components -- analyze it and break it into self-contained services, each responsible for a specific aspect of the system. Each microservice doesn't fulfill a full feature of the system, instead serving as a reusable building block in many of the system business flows.

What precautions should architects take to ensure they're on the right track when adopting MSA?
Several signs can help; for example, microservices should be small, they need to be version compatible, they are supposed to have their database and their schema, and services define their contracts. You probably have a problem if you have a common component or interface. In addition, if two or more microservices use the same database, it's a bad sign. Finally, if you need to tell someone you changed a service, the service is not backward compatible.

I can look at a system's design and see those problems immediately.

Can you briefly describe here one of the topics that will be covered in your presentation, the CAP theorem and eventual consistency?
The CAP theorem states that you can't ensure availability and consistency in a distributed system. For example, to provide a better quality of services to many users in different geolocations, you decide to deploy your system in two cloud datacenters. If there is no problem with connectivity, the state of those two deployments is synchronized. But when there is a network failure, you must choose whether to continue serving your customer on each site and solve the possible conflicts later. Or you may disable all possible changes, reducing or shutting off your service availability. Choosing to serve first and solve conflict later is, in fact, the eventual consistency approach, while making sure that data is always correct and in sync is the strong consistency approach.

Can you list a few do's and don'ts when embracing the microservices approach?

• Analyze the problem domain before jumping to the solution and breaking the system into small microservices.
• Have a DevOps professional or a DevOps team.
• Break the system into reusable business domain microservices.
• All other software reusable components are cross-cutting concerns and must be available as a reusable versioned software package.
• Make sure there is no dependency between services that force you to deploy services together.
• Don't use a common interface or a base class for all of your microservices.
• Break the usually one big database into per microservice database, and choose the correct type of database and schema according to the specific microservice point of view.

What do you mean by "evolution vs. revolution" in migrating a solution to microservices?
When migrating a system architecture to be based on the MSA, you can decide to start from scratch and have no dependency on the current system. A fresh approach has no constraints on the future solution. However, it is risky, takes time, makes you run the new and old system side by side -- and in most cases, the company management rejects it. In contrast, part by part, migrating the system will take a longer time, with more restrictions coming from the old system's architecture and technology, but let you evolve the solution, add more features along the migration process, and it is much safer. However, sometimes the current system's state is so fragile, the technology is too old, or those who developed the system in the first place have long ago left the company. In such cases, I instead go with the revolution approach.