3.4 Data analysis
3.4.2 Interview response summary
In this section, interview questions will be grouped together by their related research question and then separately discussed.
RQ1: How the MSA and monolithic architecture are generally understood among practitioners?
PO.IQ.1 and DEV.IQ.1: What exactly do you understand under the term Microservice? Do you think it should be large or small?
The initial question for POs and Developers was the same. The most common opinion was that microservices should be rather small applications with limited, well-defined functionality. Several developers, however, stated that size should not determine microservice. Instead, they said that it should be only the business and technical requirements that should determine the size and complexity of a service. Other common answer was that a service should be as much reusable as possible within the system itself, as well as by consumers from other applications in a company.
PO.IQ.2: What is your main motivation when deciding between microservices or monolithic architecture?
The most common answer was that the probability of future changes and new requirements influences their decision. It also depends on maintenance and overall overhead costs that would be required by the system running as MSA. Respondents also decide based on consultation with developers and with regards to the need of stakeholders. One answer was that in reality, the respondent would never choose a strict monolith or microservice design, but would rather oscillate between them. The final hybrid design should then reap as much benefits from both approaches, while limiting their respective drawbacks.
PO.IQ.4: What do you see as the main benefits of each architecture from the perspective of a PO?
Monoliths were recognized for their fast pace of developing completely new products and getting them quickly into production. Every PO respondent had different opinion on the advantages of MSA, shown in the following list:
• better long-term maintainability
• easier module replacement
• stabilized communication
• standardization
• less regression tests and easier to maintain
• reusability
• separation of releases and deployments
• better scalability
DEV.IQ.4: What do you see as the main benefits of each architecture?
Among the developers, monoliths were likewise commended for the quick development of a new product. As another good properties were mention the simplicity of the design, easier integration, deployment, control and code versioning. Single database was also mentioned to be easier to work with as well as changing existing interfaces.
MSA was then most commonly appreciated for generally better scalability, less effort to implement new requirements, and for being more convenient for developers as it offers them more freedom in terms of programming language or design. It was mentioned that MSA allows more people to work effectively on the same product and code in the product is easier to maintain. Technical debts are easier to solve. MSA then supposedly offers less server downtime and an error in one component does not take down other running services.
It was also mentioned that regarding scalability, monolith is better if no independent scaling of logical units is needed. Moreover, independent deployments should be also possible with proper building tools setup.
DEV.IQ.7: Are there any side-effects of the design choice? For example, will it require additional resources to deploy or will it have an impact on development?
The responses about downsides targeted mostly MSA. The most common problem is the large initial costs. Furthermore, even later in the project lifecycle, there are overheads in some areas such as infrastructure and CD/CD. It was also mentioned, however, that well setup CI/CD tools lowers overall additional effort. While being expensive initially, the costs on a growing project do not rise so rapidly. Whereas monolith, although much cheaper initially, tends to rise its costs sometimes even exponentially as the complexity of project grows. There was also a mention that architects should be aware of certain design choices.
No matter what architectural design is chosen, wrong design choices may reduce any of its benefits while bringing unwanted drawbacks.
RQ2: What differences are there in projects when using different architectures according to practitioners?
PO.IQ.3: Based on what do you decide or who provides you with documentation for such decisions?
Asked Product Owners most often decide about architecture based on common agreement with architectural board of their company. Second most important factor is then the functional reusability of any of planned functional unit. If it would bring value to some other company consumer, then they would prefer to expose its API as a microservice. And lastly, their decision most also reflect overall business and stakeholder needs.
PO.IQ.5: What are the main project challenges when developing product on a monolithic architecture and what on a microservices architecture?
The problem with monoliths was said to be their poor flexibility, more pressure on business analysts, and most importantly worse component separation. The result of it being that components have too much impact on each other. An error in one then may take down others as well. For this reason, a good coverage of automated tests is therefore needed as any change can potentially break anything. Another already mentioned problem is that once a monolithic system gets bigger and complex, extendibility gets more difficult and development costs rise sometimes even exponentially.
Microservices then present various different challenges as each respondent mentioned different ideas. As was already mentioned, the first issue is the big initial investment. That includes a lot of planning, such as overview of all existing services and defining architectural decisions of the system. Too large number of services then again increases the project complexity, even if their separate functionality is simple. There are also large requirements on human and technical resources for microservices to work. For deployments, experienced DevOps and sufficient infrastructure is required for sufficient CI/CD tools. For maintenance, well designed logging, monitoring, and operation support is also required.
There also needs to be alignment between services to maintain interface contracts.
PO.IQ.6: For which kind of project is the current project documentation more important?
Most common answer was that documentation plays equally important role for both architectures. With clean code and well written user stories and long-term plans, less overall documentation is required. It is also supposedly a useful source of know-how for newcomers.
Nonetheless, documentation has a slightly different meaning for each architecture.
Monolith uses documentation for better orientation within the application and its sub-components. Whilst, MSA needs it for externals and consumers, as well as for putting features where they belong.
PO.IQ.10: Which architecture is more expensive and during which part of the project lifecycle?
For this question, respondents had more or less the same answer. Monoliths tend to be cheaper solution on small to middle size projects and are cheaper initially on big projects.
Problem with maintainability and extendibility makes monolith much more expensive as a project grows. MSA is then the opposite. It is expensive initially, but as requirements keep coming, it pays off better than a monolith.
PO.IQ.11: With which architecture is it more difficult to make changes of functional and nonfunctional requirements and to implement new features?
Answer to this question already appeared among replies to previous questions. Monoliths are cheaper on smaller projects, but increasing complexity then favors MSA. There was a mention of the necessity to inform consumers when any changes are done in microservices.
That is something project management needs to be aware of.
PO.IQ.12: What are the differences in the structure of project teams on Monolithic and Microservice projects?
For monolith, all respondents similarly mentioned that just a single team is the choice of preference. Closer communication within the team is required, for example in order to prevent changing each other’s code in versioning system.
Respondents said that microservices can accommodate multiple teams. Work in those teams then being more independent, whilst more skill requirements are put on special roles and skills on the project. There needs to be specific alignment roles for inter-team communication, as well as specialists are required, such as DevOps and/or CI/CD specialists, and integration tests specialists.
PO.IQ.13: Is it easier to share knowledge/project know-how on a monolithic project than on a project using microservices?
Responses to this question were diverse and in one case even contradicting. One respondent said that newcomers start easier on a monolith since it is often an easier starting point to grasp. Whereas, another respondent said that starting on a complex monolith is very difficult for newcomers. MSA then allows newcomers to understand more easily its specific functionality, whilst the whole picture of the system is more abstract to them as they do not work on other components. For this reason, cross-trainings were suggested by the respondents as a solution to this how problem. Similarly, information about know-functionalities is more easily shared within a service-specific team, but alignment cross-team meetings are required to share the news with other cross-teams.
PO.IQ.14: Do you think architecture might have some influence on meeting project milestones?
The most common answer to milestone creation as a difference between architectures was that the most important thing to realize is that quality of architectural design determines the milestone creation. With a well-designed system, multiple different types of milestones can be set in place. Whereas with poor design, only a final acceptance milestone can be set.
Monoliths then are assumed to work better on smaller projects and can, therefore, work well with hard deadlines. In contrary, MSA has more external dependencies and works, therefore, better with soft deadlines. Monolith was then said to require more alignment meetings to define lifecycle milestones, whereas MSA is more transparent and less alignment for milestones is needed.
DEV.IQ.5: Are there any trade-offs in the architectures that the project manager needs to be aware of, or that need to be discussed with the project manager?
Developers replied similarly as Product Owners that monolith is worse on a growing project and has worse code maintenance. It also has limitations for long-term planning.
There were plenty of downsides mentioned for MSA. It requires more budget, as it is more expensive initially and there are always overheads at some points, such as the infrastructure. It requires more planning and coordination, including good process analysis and good domain driven design. There is also higher demand on people skills as already mentioned in previous questions. Tests are also more costly as there is higher effort in
end-to-end testing. Automated tests can be, however, implemented more in detail as smaller business logic pieces can be separately tested, making their coverage better.
DEV.IQ.6: How do the design choices affect the work of the teams?
The common answer as that MSA allows teams to work more independently, giving them more freedom in technologies and design. Whereas monolith ties team member closer together, forcing them to know the same technologies.
Monolith was then said to make performance monitoring harder and on a big project a single CPU may not be enough to provide for the whole application. Writing integration tests is also more difficult.
Developers then mentioned similarly as Product Owners that MSA requires more inter-team alignment and communication in general. DevOps have it then easier to assign computing resources where needed and performance monitoring is also easier. Testing smaller business pieces is easier and more detailed in MSA, but end-to-end testing takes more effort.
RQ3: What are the most significant technical differences between architectures according to practitioners?
PO.IQ.7: How do you determine that the company infrastructure and CI/CD are mature enough to use a microservice approach? What are the minimal requirements in your opinion?
The most important part of the infrastructure that respondents mentioned was a well-developed CI/CD tool. Infrastructure for MSA then depends heavily on the size and number of microservices it needs to accommodate. Project also needs a sufficient level of flexibility to allow the microservice approach.
PO.IQ.8: What non-functional requirements do you usually have of the architecture?
Each respondent mentioned different non-functional requirements except for scalability that was mentioned multiple times. The only difference between architectures was mentioned that MSA requires agile environment, architectural flexibility and no redundancy in services and data storages. Whereas monolith was said to require more skills and technical environment. Other mentioned requirements are hereby listed:
maintainability, stability, cohesiveness, performance, accessibility, short delays, local data storage, and prioritization during processing.
PO.IQ.9 and DEV.IQ.2: Which form of architecture has better scalability for the rising of requirements for data volume and performance?
The questions for POs and Developers were similar and for that reason they will be discussed together.
The most common answer was that MSA is better for both. It also allows more detail view on data requirements. However, one respondent mentioned that either approach can be good in certain situations and it sometimes depends heavily on quality of the architectural
design. Containerization was one of the other points, why MSA was considered better. In contrary, scalability in monolith may be difficult if modules have different non-functional requirements.
DEV.IQ.3: What are the differences between architectures when it comes to the future planning of project extendibility and its related scalability?
Previous answers already indicate as how respondents replied to this question. Monoliths were considered better on small projects, as they struggle with new complex requirements that require large assessment of the impact on its parts. And how was already said, monolith struggles on large complex projects in general.
On the other hand, MSA was said to have issues with orchestration and high costs during the project preparation phase, as a lot of planning is needed. However, it gives the developers more technical freedom. And since less services are usually involved in a business requirement, it makes analysis, implementation, and testing activities quite easier.
It was also mentioned that if designed well, both architectures can have the achieve the same level of scalability and extendibility.
DEV.IQ.8: What are differences in testing between architectures, if any?
Respondents said that in monolith, tests all are mostly in one service as the testing cannot be separated. Resulting in test writing being more difficult and more regression testing is needed of the whole product.
The most common answer was that MSA needs a lot of alignments and coordination planning for testing. Tests can be written smaller and faster. Integration tests are very important, as they need to validate the communication between services. Regression tests do not need to cover all services, if only part of them was changed. But when regression tests find a problem, it can be difficult to tract it down to its source. And as was already mentioned in previous question, end-to-end testing is also more difficult in MSA.
DEV.IQ.9: What are the differences regarding deployments and management of infrastructure?
Monoliths were commonly said to have less requirements on their infrastructure, it can be therefore cheaper and smaller. Deployments are also much simpler. On the other hand, even a small change requires redeployment of the whole application. Deployments are also more limited and can happen less often.
MSA then demands more complex infrastructure, making then large costs overhead. The benefit of it is then that DevOps have then more freedom to change infrastructure and less infrastructure alignments are needed. Service discovery and orchestration need to be set up.
Deployments are also more complex, but can happen more often.
DEV.IQ.10: Are there any differences when it comes to database management?
Monoliths generally use single shared database schema, making transaction management much easier.
MSA can have either shared schemas similarly as monolith or each of them have their own separated schemas. Separation of schemas benefits data isolation, data management, and it allows queries to be much smaller benefitting performance. But that comes at the cost of issues in some other areas. With more schemas, database costs are higher. Data propagation among services needs to be managed. Transaction management gets more complicated in cases when business case spans multiple services and rollbacks need to be made in different schemas when an error occurs. MSA was said to also need more data consolidation and need to resolve design issues when there needs to be access to some common shared data.