Microservice architecture is not just a new fashion, but also good, and sometimes the only possible solution for the problems that are found in software development. At conferences microservices are compared with monolithic architecture, the pros and cons and success stories and failures are described.
But, while rock concerts are performed in capitals, in local territories balalaika is played. It is not always clear how to start making system based on microservice architecture. What problems can meet an architect and a developer, which bottlenecks can occur and how to prepare? Does it make sense to start with the monolith or should immediately break a system in microservices? How to determine the boundaries that stand between your microservices?
During development it is possible to save a lot of difficulties for the future due to habits left after work on monolithic architecture. During the talk different scenarios will be considered, which resulted in an increase of the system occurs connectivity. All scenarios are taken from real projects and referenced to work with libraries and integration between microservices.
Selecting of microservices will have a major impact on testing, where QA specialists waiting a number of new problems related to the collection of logs and deployment environment for testing.
The purpose of the talk is not only in reporting problem areas of microservices' development, but also to offer advices and solutions to help fix or avoid problems and, consequently, the loss of time and resources to fix them.
Max Syachin, Luxoft
Maxim works in Luxoft as a Lead Java-developer in the project "Pochta Rossii" ("Russian Post"). In addition to the main objectives he promotes microservice architecture and implementation of Continuous Delivery. During more than ten years career he was able to participate in the development of multiple GIS platforms on C ++ and Java, and then plunged into a bloody enterprise development. He respects Scala, Kotlin and microservices.