Unit 11: Future trends in Secure Software Development
Artefact: Monolithic vs Microservices
Debate between Monolithic and Microservice architecture
Monolithic architecture is a traditional approach where an application is built as a single, self-contained unit. It typically consists of a single codebase, a single executable, and a single database. All the components of the application are interconnected making it difficult to modify or scale individual parts of the system.
Microservices architecture is an approach where an application is built as a collection of loosely-coupled services. Each service is a separate, independently deployable component that can be scaled and modified without affecting the other services. The services communicate with each other using APIs and can be built using different programming languages, databases and frameworks. (Konrad & Zabierowski, 2020)
Monolithic architecture has the advantages of being easy to develop and deploy as well as being simple to test. However, it has several disadvantages, such as difficult to scale individual components, high coupling between components, limited flexibility when it comes to using different programming languages and frameworks. (Konrad & Zabierowski, 2020) Microservices architecture has the benefits of being easy to scale individual components, loosely-coupled components, greater flexibility when it comes to using different programming languages, databases and frameworks. It does still have drawbacks such as higher complexity to develop and deploy, more difficult to test and debug and overall a higher overhead from communication between services.
In conclusion, monolithic architecture is simpler and easier to manage, but it can be difficult to scale and modify. Microservices architecture is more flexible and resilient, but it requires more effort to develop and deploy. The choice between the two architectures depends on the specific needs of the application and the trade-offs that need to be made between simplicity and flexibility.
My personal stance is with support for microservices. It seems that the futures tends to favour microservices due to its flexibility and scalability. With the development of more larger scale multifaceted businesses the need for architecture to be customized and readily built upon, heavily favours microservices.
References:
Reflection / Evaluation: Coding Output
The second summative assignment was a continuation of the first assignment of making a design document for a for the development of an application that provides a secure repository for an organisation. My team decided on The International Space Station (ISS) as our organization. Our primary object was to facilitate and securely store the constant stream of mission data coming from the ISS, we needed to develop and deploy a software system that will provide a secure repository for data transmitted from the International Space Station, the team chose to make a data archive or IDA.
IDA, or ISS Data Archive, is a secure repository software that offers secure storage and access to information. Encrypted information is processed, decrypted on-premises, and stored in a secure local database. Authenticated users can access and optionally manipulate the data via a locally hosted web interface.
Development process went mostly as I expected it, we worked well together as a team with good communication throughout and made good progress early on. However as a time went on we did start to slow down mid-way through which made the final stages of the development tough.
The challenges of having members from all different continents around the world as well as jobs and other responsibilities made proper meeting impossible for us. So chose to communicate frequently through team chat and had a shared GitHub repository where we would make amendments to the to do lists. As well as this we would update each other on our progress with teams chat. This proved to be an effective working system but did create some areas where progress was slow due to outside conditions.
We made an extremely late change from the bottle framework to flask due to problems with the functionality. This change allowed for proper input of data values into the SQL database which the bottle framework was preventing. However, the drawback to this was the added stress and work for the team to complete which took time away from our testing processes. The flask framework is generally had much better documentation and was much easier to use. This allowed for much faster progress from this point.
We decided not to include the data service aspect from our original design due to time constrains as well as the functionality that it would have brought was already being completed via the ISS microservice which was sending requests to the IDA endpoint to create a record with the logic for which already being present at the endpoint. Most of the omissions made from our design to the implementation were due to a lack of proper time management and organization of tasks amongst the group in a stepwise, logical way.
One of the most important aspects of the project personally was the development of the user and admin systems. The implementation of the different priority levels, having access to more function in the system such as admin being able to delete users and records from the system. The user logging in system was also a tougher task than I expected as that was not something I was previously familiar with before this project.
Due to the amount of files and the possible complexity of our program we thought it would be best to prepared a video tutorial which was something we decided on very late into development. This was not something we originally were planning to do but this did prove to be very useful task for professional development, in the purpose of showing to theoretical stakeholders.
The system in its totality does have several security flaws, and a few lax design choices due to time constrains. Overall, I am happy with the project as a whole the functionality of the system is near what we wanted from the original design of the system. We did make many major changes throughout development, as specified earlier. We did believe as a group that although these did hurt the level of security in our system, it would be worse for the overall product to try to implement these the functions of the design and run out of time and have ultimately even less security as there would be little to no time left for further testing. The whole process me a deeper understanding of challenges involved with making truly secure software as a product for a third party.