Recently, Andrei Gordienkov , trainer at Luxoft Training, interviewed Sander Hugendorn about microservice architecture.

" SANDER HUGENDORN (NETHERLANDS) - mentor, trainer, software architect, programmer, speaker and writer. Sander has been working in software development for over 30 years; he wrote his first commercial program at age 18 on Pascal.

Collaborates with major IT consulting companies for 20 years. Currently working in Capgemini. Numerous clients from different countries highly appreciate it as an “activator” of innovations in software development.
')
Sander was a trainer for organizations, teams, projects and individuals. Introduced more than 300 training courses over the past 15 years on various topics such as Agile, Scrum, Kanban, software evaluation, software architecture, microservices, design patterns, modeling and UML, writing code and testing.

The original interview in English is published on Sander's blog .

Should I use microservices?

Andrei Gordienkov: In your article “Microservices. Good, bad, evil ” you described various aspects of development. Readers might get the impression that using microservice architecture would lead to the following:

• Companies will need experts on various technologies. This can lead to an increase in the number of employees or an increase in the cost of training, that is, it will affect the budget;
• Difficulties in setting up the interaction and integration of individual components can lead to time consuming.
• The company will need an architect with experience in various technologies and practices. That is, there will be a need to find or “grow” such a specialist. Such a specialist may be expensive, the company will become dependent on him, and the burden for such a specialist may not be enough. Also, there is a danger of disrupting the terms of the project, if he leaves, for example, on sick leave. Using microservices seems too expensive and too risky. It may even destroy the project.

So, the question is: should microservices be used and why are they the future of architecture?

Sander Hugendorn: The use of microservice architecture covers much more than “just” software development. It requires an interdisciplinary approach, in which many different roles work closely together to develop, build, test, and deploy the system you are building. This involves not only the architect, but also analysts, designers, whose task is to break up the domain into limited contexts and design an API that will offer your components. This also includes the job of deploying the system in a production environment. This is not a one-time event, but a continuous stream of new and updated applications and components. So in order to arrive at a microservice architecture, a lot of different skills, knowledge and experience are required in many topics, including modeling, software architecture, automated testing, API design and deployment, subject-oriented design and continuous delivery. And last but not least: since each component can be built using different languages ​​and technologies, you may end up with a patchwork of technologies. However, due to the considerations mentioned above, I would not recommend it. The use of many different languages ​​and technologies is not a requirement.
The expediency of moving to microservices largely depends on where you yourself go to them. One of my clients is trying to get rid of his mainframe. They are slowly rebuilding all the functionality from the mainframe to a new microservice architecture. For them, the ability to supply small parts of the system one by one is very valuable and justifies the continuous research and costs associated with how to do it. For another client, the most valuable part of microservices is the ability to break their difficult-to-maintain system, consisting of 7 million lines of code, into a number of much better isolated and easy-to-maintain limited contexts within a single system. They will not move in the direction of the individual components being deployed.

Isn't it better to build a monolithic system first?

A.G .: In a recent post on his blog, Martin Fowler (Martin Fowler) stated that it is better to first build a monolith, and when you begin to understand the boundaries of your domain, you can divide your application into microservices in the best way. What do you think of this advice? Did you use it in your practice?
S.Kh .: As I said in the answer to the previous question, there are many different situations in which microservices are applicable or not applicable. I do not think that there is a golden rule that will help decide whether to strive for microservices. The client I mentioned - the one who wants to get rid of his mainframe - will not build a monolith at first: they tried, but the system was so large and difficult to maintain that the project failed. Also because they could not recognize the limited contexts in this attempt.
In microservices, it's good that they make you think in categories of small components and limited contexts. This, in my opinion, is one of the biggest advantages of applying this architectural style, regardless of whether you deploy them all separately or use them to break the system into modules. I assume that Martin Fowler did not mean the literal construction of the monolith at the beginning; rather, he tried to emphasize that it was important to be able to split your domain into modules.

If you break the application into small parts, will it be a microservice architecture?

A.G .: If I break my application into small parts and at the same time it will function - no matter how, but I will, can I call it microservice architecture? Or is it just a patchwork quilt? What makes microservice architecture a real architecture?

S.Kh .: Personally, I don’t really care if something is a microservice architecture or not. Just as I really do not care, "flexible" project or not. The question is whether you can benefit from the proposed ideas and concepts. If Agile uses continuous prioritization, short iterations and multidisciplinary commands for you, does it really matter if they are called Scrum, XP, Smart or Crystal Clear?
In my opinion, it is worth dividing large systems into small independent parts and defining clear boundaries between them, because it helps to create a higher-quality, more maintainable, verifiable code. And it allows you to choose different technologies, such as resilience mechanisms and database types. In any case, the deployable components facilitate continuous delivery and provide high scalability, but not for all. So please benefit from ideas and concepts, regardless of whether you can call it microservice architecture or not.

How valuable is the use of the right tools when developing microservices?

A.G .: Could you share your vision of how valuable it is to use the right tools when developing microservices? Can they help and direct to the proper management and development of microservice architecture? To avoid the notorious pattern, when probably no one has any idea how the components are interconnected and how this big ball of dirt really works, you understand? I know that there is no “silver bullet”, but the tools can help developers as much as a good API helps and guides them during development. I mean Swagger, APIary, name store, MQ brokers - I think you get the idea. You can write your code in notepad, but this is counterproductive. So again, can the tools guide the developers and help them avoid some silly mistakes?

S.Kh .: First of all, there is no such tool that will do the work for you. When implementing a microservice architecture, you have to think a lot and use a large number of different methods and technologies. Since microservices are fairly new (although some claim that they exist much longer), the tools that will help you will appear when manufacturers see the opportunity to make money. We are already seeing new tools for organizing continuous delivery and customization of deployment pipelines, such as Go-CDs; for opening API and documentation, such as Swagger. I think that manufacturers will begin to create more and more tools to fully automate processes around the implementation of microservice architecture, mainly based on the cloud. Integrated Development Environments (IDEs) will offer better support for the development of microservices. But now most organizations use fairly traditional development tools that we already know from “flexible” projects.

Why is it worth visiting a microservice architecture training?

A.G .: On September 25 in Moscow you conduct the training “Design, development, testing and deployment of microservice architecture” . Could you explain why it is worth visiting it, how can it be useful for companies that are not even going to switch to microservices? After all, you can simply buy a book by Sam Newman "Building Microservices" and follow the instructions. Will this be enough?

S.Kh .: I really like Sam’s book, he gives a very good overview of what the company will encounter when it starts implementing microservice architecture. So the book is a good start. But it is always useful to attend a training course, like mine, to see real examples of problems you will encounter on the way to microservices. During the training course, I will present the basics of microservices, their advantages and disadvantages. We will discuss various scenarios of when to think about the use of microservices, and when not. I will focus on designing components and services, building applications that use microservices in corporate environments, including automating business processes, “smart” use scenarios and subject-oriented design with limited contexts, and how design and build. I will talk in detail about the design of the API and how to test microservices, including using automated testing. We will discuss the setup of deployment pipelines and the deployment of microservices. All this will be illustrated with examples from real life (and funny jokes). So I hope that you will learn a lot from my training course, even if you (as yet) do not create microservices.