In this sub-chapter, we will discuss the differences regarding architectures when it comes to project planning and project milestones. The project planning part will also include breaking of requirements into features and how project milestones relate to successful implementation of these features in Sprints.
When it comes to setting up and keeping the project milestones, in some parts the architectures tend to be the same and in some very different as we can see from the interviews. In the following problems, we will talk about the different areas, where the architectures diverge.
4.7.1 General project phase differences
There are multiple definitions related to project phase separation. The author of this work chose the following one, as it covers all the steps, he deems imperative (Smith, 2020). This definition is related to a general project lifecycle that is very common in classic software development methodologies such as waterfall:
1) Requirement gathering – understanding of business objectives and scope of work.
List ff requirements that we want our system to fulfill.
2) Technical validation of requirements – Assessment, whether we are able to implement the requirements and specifications of how the developers are going to do it.
3) Predevelopment planning – Refinement of all the upcoming aspects that will be implemented in the project into more concrete details. Includes Architectural and technical Design planning, Project management planning, and Quality Assurance planning.
4) Implementation – Development cycles with iterations each presenting a steadily upgraded deliverable.
5) Quality Assurance – Testing phase.
6) User acceptance testing 7) Deployment
8) Support
Nonetheless, a microservice projects adjust some of these steps, as the emphasis on some steps is higher than on some other ones (Cowart, 2018):
1) Define Business Boundaries
2) Select a Business Boundary for the First Microservice a. Feature Roadmap
b. Team Size
c. Performance Issues d. Complexity
3) Create the Development Backlog 4) Develop and Test the Microservice 5) Deploy the Microservice
6) Lessons Learned
These microservice milestones might resemble the steps in the Agile methodology (Lucid Content Team, 2021) and that is of no coincidence, as also in the interviews several experts replied that Microservice approach is better in environments that offer more flexibility and that do not have so strict deadlines. This is also implicated by the Conway’s law (chapter 2.3.1) as teams following more loose agile approach tend to develop their products more in the way of microservices. Whereas, teams bound by less flexible methodologies, such as waterfall, tend to develop more tight monolithic products.
4.7.2 Differences in keeping up with milestones
Even greater difference than the milestone objectives is how these milestones can be planned within a project. In monoliths, since everything is built in one large package and parts are coupled with each other, milestones must be planned and reached together for all parts of the project. Releases that push the new versions of prototypes are equally bound in terms of dependencies.
In contrary, microservices can be developed and deployed independently, alignments required only on topics that influence other services; or, when a new requirement for a specific service requires some new API behavior from another service(s). This sounds similar to CI/CD and deployment issues discussed in the preceding architectural problem
in chapter 4.3, as both topics are closely related. The dependencies between components are what distinguishes what comes through the pipeline and, therefore, define how the different milestones can be planned and reached.
Regarding types of milestones defined in the work of Sunmola (chapter 2.1.5), the tight coupling of monoliths makes defining milestones more difficult. For that reason, it can be assumed that mostly hard milestone deadlines can be set in place for some feature blocks to be delivered. Whereas with microservices, hard milestones can be planned together with soft milestones thanks to more flexible and frequent deployments. The soft milestones would then serve as a motivation checkpoint after each Sprint (chapter 2.6.2).
4.7.3 Summary
In the other research problems that are discussed in this work, we often mention that the additional costs in effort and skill requirements for project team members pays back in the form of increased flexibility. That flexibility is what makes microservices in terms of project milestones far superior over monoliths.
The initial costs overhead of setting up a project with all the requirements of microservices is initially very high. But their flexibility pays back in the long run, as long as the project is still in development. For projects that do not really need this kind of flexibility though, making simple milestones in a monolith would then surely be the better choice.
5 Discussion
The analytical research (chapter 2) provided theoretical background for setting up research questions in this thesis. This background was further strengthened by interview responses of professionals with many years of experience in chapter 3 together with answered research questions that were defined before the interviews took place. Then together with practical architectural problem examination in chapter 4, all these materials will now serve in this chapter for answering the goal of this work defined in the introduction of this work (chapter 1).
The answer to the goal of this thesis is composed of three following sub-chapters in the form of discussion about facts that were in previous chapters. These discussions in sub-chapters extend the research questions answered in chapter 3.4.3. The first section will cover the common understanding of monolith and MSA and will describe general use cases where each of them is more suitable. The other two sections will then examine more thoroughly findings from the project and technical perspectives. Implications of the discussion for researchers, practitioners, and everybody else reading this work will then be discussed in the conclusion of this thesis (chapter 6).