AgileDomain driven designmicroservicesService oriented architectureSoftware architecture

Microservices Q&A

In September I will run a masterclass on microservices at Luxoft in Moscow, Russia, see In preparation of this masterclass, here’s a short Q & A on microservices.

Is it worth applying microservices?

Q: In your article Microservices. The Good, the Bad, and the Ugly you described different aspects of development. Readers may think that using a microservices architecture would lead to the following:

  • A company will need experts in completely different technologies. This may lead to increased staff numbers or training costs,  so various activities that increase pressure on the budget.
  • Difficulties during interaction and integration setup for separate components may be time-consuming.
  • A company will need an architect experienced in different technologies and practices. It may be hard to find or grow such a person. He or she may be expensive, the company may become dependent on such an expert, there may not be enough workload for the person. If he or she is on a sick leave, for example, the project will face the risks of failing the deadlines.
  • It seems too expensive to apply microservices, and too risky. It can even ruin the project.

So, here’s the question: is it worth applying microservices and why are they the future of architecture?

A: Applying a microservices architecture encompasses much more than “just” software development. It does require a multidisciplinary approach where a lot of different roles work closely together to design, build, test and deploy the systems you build. Not only an architect, but also analysts and designers to break down the domain in bounded contexts, and to design the API’s your components will offer. And it also involves operations, as the systems need to be deployed into the production environments. This is not a one-off event, but a continuous flow of new and updates applications and components. So, going for a microservices architecture requires a lot of different skills, and knowledge and experience on a lot of topics, including modeling, software architecture, automated testing, API discovery and design, domain driven design and continuous delivery. And last but not least, as each component could be built in different languages and technologies, yes, you could end up with a patchwork of technologies. However, due for reasons you mentioned above, I would not recommend this. Using a lot of different languages and technologies is not a mandatory requirement.

Whether moving towards a microservices is worthwhile depends a lot on where you are coming from. One of my clients is trying to get rid of their mainframe. They are slowly rebuilding all the functionality from the mainframe into a new microservices architecture. To them, being able to deliver small parts of the system one by one is highly valuable, and worth the continuous research and costs related to how to actually do this. To another client the most valuable parts of microservices is the strive to break down their unmaintainable 7 million lines-of-code system into a range of much better isolated and maintainable bounded contexts within a single system. They will not move towards the separate deployable components.

Is it better to build a monolith first?

Q: In a recent blog post, Martin Fowler states that it’s better to build a monolith first, and when you start to understand your domain boundaries, you can split your application into microservices better. What do you think about this advice? Have you applied it in your practice?

A: As I mentioned in the answer with the previous question, there are many different situations where a microservices might or might not apply. I don’t think that there is a golden rule to decide whether or not to endeavor into microservices. The client I mentioned who wants to get rid of their mainframe will not be building a monolith first, they tried but the system simply got so big and unmaintainable that the project did not succeed. Also because they failed to recognize bounded contexts during this attempt.

A good thing about microservices is that it forces you to think in small components and bounded contexts. That, in my opinion, is maybe one of the biggest benefits of applying this architectural styles, independent of whether you actually deploy them all individually or use it to modularize your system. I would suggest Martin Fowler doesn’t literally mean to build a monolith first, but that he tried to emphasize that is important to be able to modularize you domain.

Is it still microservices if I just break down my application into small pieces?

Q: If I just break down my application into small parts and it still works, no matter how, but it works – may I call it a microservices architecture? Or is it just a patchwork blanket? What makes a microservices architecture a real architecture?

A: Personally I don’t really care whether something is a microservices architecture or not. Just as I don’t really care whether a project is agile or not. The real question is: can you benefit from the ideas and concepts that are offered. In agile, if using continuous prioritization, short iterations and multidisciplinary teams work for you, does it really matter if it is called Scrum, XP, Smart or Crystal Clear? 

To me, it is worthwhile breaking down large systems into small, independent parts, and defining clear boundaries between, because it helps you to create higher quality and better maintainable and testable code. And it allows choosing difference technologies, such as persistence mechanisms and database types. Independently deployable components facilitate continuous delivery and high scalability, but that’s not for everyone. So, please benefit from the ideas and concepts, but don’t worry to much about whether or not you could call it a microservices architecture.

How valuable it is to use the right tools for the microservices development?

Q: Could you share your vision how valuable it is to use the right tools for the microservices development? Could they help and guide you to proper management and development of a microservices architecture? You know, to avoid a notorious pattern, when probably no one has any idea how its components are interconnected and how this big ball of mug really works? I know that there is no silver bullet, but are the tools capable of helping the developers in the same manner as a good API helps and guides them during the development? I mean Swagger, APIary, name repositories, MQ brokers – I think you get the idea. You can write your code in notepad, but it’s counterproductive. So once again, can the tools guide and help the developers to avoid some dumb mistakes?

A: First of all, there is no tool that will do the work for you. A fool with a tool is still a fool. Implementing a microservices architecture requires a lot of thinking. And a lot of different techniques and technologies. As microservices is a rather new (although some claim it has been around much longer) tools that help you will emerge as vendors will see a possibility to make money. We already see new tools to organize continuous delivery and set up deployment pipelines, such as Go-CD, for API discovery and documentation, such as Swagger. I think vendors will start to set up more and more tooling to fully automate the processes around implementing microservices architecture., mostly cloud-based. IDE’s will offer better support for microservices development. But currently, most organizations are using fairly  traditional development tools that we already know from agile projects.

Why should I attend your training session on microservices architecture?

Q: You are conducting a training session in Moscow in September. Could you explain why I should attend, why it may be useful for me, even if my company is not going to migrate to microservices? Well, I could buy Sam Newman’s book “Building Microservices” and follow the instructions. Will it be enough?
A: I do like Sam’s book a lot, it gives a very good overview on what a company will encounter when it starts implementing a microservices architecture. So it gives you a good start. But it is always good to attend a training course such as the one I’ll be giving to witness everyday examples from all the challenges you will encounter on a microservices journey. During the training course I will introduce the basics of microservices, its benefits and its challenges. We will discuss different scenario’s on when it is worthwhile investigating microservices, and when it is not. I will emphasize designing components and services and building applications that use microservices in enterprise environments, including automating business processes, smart use cases and domain driven design with bounded contexts and how to design and build these. I will also elaborate on API design, and on how to test microservices, including test automation. Last but not least we will discuss setting up deployment pipelines and deploying microservices. All illustrated with real-life examples (and funny anecdotes). So I hope there’s much to learn for you from my training course, even if you are not (yet) delivering microservices.

For more information about my training course for Luxoft in Moscow, see