What is Software Architecture?
Architecture serves as a blueprint for a system. It provides an abstraction to manage
the system complexity and establish a communication and coordination mechanism
among components.
•It defines a structured solution to meet all the technical and operational
requirements, while optimizing the common quality attributes like performance and
security.
These Architecture decisions includes −
• Selection of structural elements and their interfaces by which the system is
composed.
• Behavior as specified in collaborations among those elements.
• Composition of these structural and behavioral elements into large subsystem.
• Architectural decisions align with business objectives.
Event Driven Architecture?
Many programs spend most of their time waiting for something to happen. This is especially
true for computers that work directly with humans, but it’s also common in areas like
networks. Sometimes there’s data that needs processing, and other times there isn’t.
The event-driven architecture helps manage this by building a central unit that accepts all data
and then delegates it to the separate modules that handle the particular type. This handoff is
said to generate an “event,” and it is delegated to the code assigned to that type.
Suitable for Use case:
•Asynchronous systems with asynchronous data flow
•Applications where the individual data blocks interact with only a few of the many modules
•User interfaces
SOA Architecture?
In software engineering, service-oriented architecture (SOA) is an architectural
style that focuses on discrete services instead of a monolithic design. By
consequence, it is also applied in the field of software design where services are
provided to the other components by application components, through
a communication protocol over a network. A service is a discrete unit of functionality
that can be accessed remotely and acted upon and updated independently, such as
retrieving a credit card statement online. SOA is also intended to be independent of
vendors, products and technologies.
Service orientation is a way of thinking in terms of services and service-based
development and the outcomes of services.
SOA is related to the idea of an API (application programming interface), an interface
or communication protocol between different parts of a computer program intended to
simplify the implementation and maintenance of software. An API can be thought of
as the service, and the SOA the architecture that allows the service to operate.
The Main Principles of SOA
Main principles of SOA are:
•Service architecture – The physical layout or design of individual
services that surpass all the resources that were used by a service.
•Service composition architecture – All the services developed using
service-oriented design methods are composition centric, and this is their
main feature. This architecture, therefore, is the composition of individual
architectures of various services.
•Service inventory architecture – This architecture is formed from the
service inventory blueprint where the service inventory is made up of
services that automate the procedures of businesses.
•Service-oriented enterprise architecture – This type constitutes of
composition, service as well as inventory architectures.
Microservice Architecture
•Microservices are small, independent, and loosely coupled. A single small team of
developers can write and maintain a service.
•Each service is a separate codebase, which can be managed by a small development
team.
•Services can be deployed independently. A team can update an existing service
without rebuilding and redeploying the entire application.
•Services are responsible for persisting their own data or external state. This differs
from the traditional model, where a separate data layer handles data persistence.
•Services communicate with each other by using well-defined APIs. Internal
implementation details of each service are hidden from other services.
•Supports polyglot programming. For example, services don't need to share the same
technology stack, libraries, or frameworks.
Serverless Architecture
Serverless architectures are application designs that incorporate third-
party “Backend as a Service” (BaaS) services, and/or that include custom
code run in managed, ephemeral containers on a “Functions as a
Service” (FaaS) platform. By using these ideas, and related ones like
single-page applications, such architectures remove much of the need
for a traditional always-on server component. Serverless architectures
may benefit from significantly reduced operational cost, complexity, and
engineering lead time, at a cost of increased reliance on vendor
dependencies and comparatively immature supporting services.
Serverless Architecture
Serverless is an application delivery model where cloud providers
automatically intercept user requests and computing events to
dynamically allocate and scale compute resources, allowing you to run
applications without having to provision, configure, manage, or maintain
server infrastructure.
Serverless allows applications to be hostless (apps aren’t hosted on a
server), stateless (interactions and data aren’t stored), elastic (resources are
scaled up and down without limits), distributed (multiple services are linked
for seamless functioning), and event-driven (resources are allocated only
when triggered by an event).
Containerized Architecture
A containerized architecture makes it possible to package software and
its dependencies in an isolated unit, called a container, which can run
consistently in any environment. Containers are truly portable, unlike
traditional software deployment, in which software could not be moved to
another environment without errors and incompatibilities.
Containers are similar to virtual machines in a traditional virtualized
architecture, but they are more lightweight – they require less server
resources and are much faster to start up. Technically, a container differs
from a virtual machine because it shares the operating system kernel
with other containers and applications, while a virtual machine runs a full
virtual operating system.
Benefits of Containerized Architecture
1.Lower costs—on infrastructure operations, because you can run many containers
on a single virtual machine.
2.Scalability—at the micro-service level eliminates the need to scale VMs or
instances.
3.Instant replication—of microservices, enabled through deployment sets and
replicas.
4.Flexible routing—you can set this up between services supported natively by
containerization platforms.
5.Resilience—when a container fails, it’s easy to refresh/redeploy with a new
container from the same image.
6.Full portability—between on-premise locations and cloud environments.
7.OS independent—there is no need to run an OS. All you need is to deploy a
container engine on top of a host OS.
8.Fast deployment—of new containers. You can also quickly terminate old
containers using the same environment.
9.Lightweight—since containers run without an OS, they are significantly lightweight