Evolution of the Software Engineering
“Design is where science and art break even.”- Mieke Gerritzen
Software architecture is a critical link between design and requirement engineering, it first identifies and breaks down the system into the component level without the implementation, and its relationships between them, as the final result of the architecting process it describes how the system is organized as a collection of communicating components working together.
Over the past 50 years, software engineering and architectures are kept evolving. all these years the term software engineering appeared was that to build software is maintainable adaptive to the technologies at that time. But with time infrastructure getting more powerful software requirements getting complex this article gives an idea of how it transformed with time.
In software application types there are few types of applications
- Standalone Applications - These types of applications are complete runs on a single computer it has its own databases, runtime environments, libraries installed in that computer itself. and there is no need of communicating with other computers or applications to get their work done.
- Web-based and Distributed Applications - These applications have few different changes when it comes to the architecture but the way they work is somewhat similar, these applications do not have to install or set up complete environments in the computer to get the works done.
Compared to the distributed applications, the standalone application has less area to design and develop and complex problems are less. But with time development of the networks and internet applications become distributed rather than centralized.
Distributed or Web applications can serve multiple PCs knows as clients from where the applications are hosted known as servers. These applications are serving multiple users at the same time and new requirements began to change to keep this application running continuously maintains is needed to however these tasks became difficult with time, to these issues software needed proper engineering and architectural practices.
As a result of that Software Architectural patterns are introduced and with time new patterns keep evolving, from early stages and up to now here’s how the evolution happens
1. Monolith Architecture
This is a traditional unified approach of architecture used to design and develop the software in the early 2000s. The application developed using the monolith architecture is a complete single unit, where all of the components of the system are included.
Monolith architecture results in highly coupled systems. In system updates or new feature add the whole application itself has to modified and, a change of one module might cause issues in other modules. and in case of replacing some module, complete functionality might lead to a complete rewrite of the application, and due to this releases takes more time.
2. Layered Architecture
Due to the complexity of maintaining and feature adding, developers had to move to a bit modularized solution. The main idea of the layered architecture is to independent the layers as much as possible based on the responsibility of the system.
Communication between these layers and extremely loosely coupled, and components inside one layer can interact only with the components in the layer itself and with the layer beneath it.
The layered architecture has not predefined any certain number of layers but there are few common layers depends on the implementation
Presentation Layer - This layer contains the logic related to handling user interactions and the graphical user interface of modern web applications.
Business Layer - This layer contains the actual business functionality, to be applied based on the action,
Data Access Layer / Persistence Layer - This layer directly communicates with the database, of the CRUD operations and queries handled through this layer.
This number of layers is not mandatory in some systems it depends on the architecture,
This architecture brought ease of development compared to the monolith architecture because of the layered approach it’s easy to locate an issue easily and fix it without affecting the layers above and layers below. and also this architecture brought reusability.
3. Service Orietend Architecture
When the software getting widely adapted and businesses started to share and integrate with each other, and the software built on those organizations need a common way of getting to communicate with an application built using different technologies including programming languages and running on different OS.
SOA is an architectural pattern that came up as a solution for this, Instead of building complete applications, SOA creates separate components called
“services” As an example for e-commerce application client management should be there, and a payment gateway should be there rather than implementing these from scratch these modules can be integrated as services for an existing system.
This makes loose coupled and highly cohesion applications, that each service is working on independently without other services knowing how other services work.
In order to communicate with other services each service defines a contract (interfaces), this contract usually defines using Web Service Definition Language(WSDL). and using the underlying protocols such as SOAP and architectures such as REST,
For maintaining communication and keep track of the services SOA uses a middleware ESB(Enterprise Service Bus) this handles all the data routing, the transformation between communication protocols, ESB is the backbone of the SOA, without ESB the rest of the components are just a bunch of services.
4. Microservice Architecture
Microservice architecture also follows a decoupled service approach like the SOA but it has more capabilities than it.
Microservices are based on few important factors.
- Highly maintainable and testable - Due to the small size of the service testing and maintaining is very easy and developers only have to focus on only one specific domain.
- Loosely coupled - Where each service runs independently without having to know about other services or their implementations.
- Independently deployable - A single unit of component mostly build based on a business functionality or domain-specific task. Features and updates can be carried out only for these independent components, in that case without stopping or disturbing the other components only the necessary services can be deployed.
- Organized around business capabilities - When designing the system using Microservices it does focuses on the customer/business aspect, this makes the business functions running smoother at any given time in any situation.
- Owned by a small team - There is no need of having more than 7 members of a microservice team for developing, testing, and maintaining the units, which helps to make decisions effectively with the team and maintain proper communication.
But all those features are the same as SOA, right?.
Microservice came into the industry where few other technologies emerging into the software engineering world. such as Cloud, DevOps, and agile methodology of developing software. microservices are more adaptive to these technologies than SOA.
SOA-based application's main intention is to integrate, though there are some levels of reuse. but when it comes to Microservices it is fully reusable and also can be integrated.
In communication, Microservice has lightweight messaging protocols like HTTP, and architectures like REST, and even with the message brokers microservices can have asynchronous communication, but SOA depends on ESB for all communication and a single point of failure in ESB can affect the complete application.
