Intro Software Architecture
Intro Software Architecture
The architecture helps define a solution to meet all the technical and operational
requirements, with the common goal of optimizing for performance and security.
Designing the architecture involves the intersection of the organization’s needs
and the needs of the development team. Each decision can have a considerable
impact on quality, maintainability, performance, etc.
It’s the decisions you wish you could get right early in a project.
Why is Software Architecture Important ?
Constructing a building or making a pizza — to successfully create
anything, you need to get the base right. If you don’t get the base
right and something goes wrong, you just have to start over — there's
no way around it.
Building a SW application is no different. The architecture is the base.
It should be carefully thought out to avoid major design changes and
code refactoring later.
Why is Software Architecture Important ?
Many engineers will tell you that: You don’t want to have to re-design
stuff. It eats up your time like a black hole. It has the potential to push
your shipping date by months, if not longer. And that’s not even counting
the waste of engineering and financial resources.
• Hasty decisions taken during the initial design phases can cause an impasse
at any stage in the development process. So, before we even get our hands
dirty with the code, we must make the underlying architecture right.
• Software development is an iterative and evolutionary process — we don’t
always get things perfect first go. But this is no excuse for not doing our
homework.
The Difference Between Software Architecture
and Software Design
Software architecture is used to define the skeleton Software design is responsible for the
and the high-level components of a system and how code-level design — what each module is
they will all work together. For example, do you doing, the classes scope, and the functions,
need a serverless architecture that splits the purposes, etc. When used strategically,
application into two components: BaaS (backend-as- they can make a programmer more
a-service) and FaaS (functions-as-a-service)? Or do efficient, giving them methods that have
you need something like a microservice architecture already been refined by others, so they
where the different features/tasks are split into don’t have to keep reinventing the wheel.
separate respective modules/codebases? Also, when discussing with others or
managing code in larger teams, they
provide a useful common language to
Choosing an architecture will determine how you conceptualize repeated problems and
deal with performance, fault tolerance, scalability,
solutions.
and reliability.
Tier
Think of a tier as a logical separation of components in an
application or a service.
And when I say separation, I mean physical separation at the
component level, not the code level.
The main upside of single-tier applications is they have no network latency since every
component is located on the same machine. This adds up to the performance of the software.
There are no data requests to the backend server every now and then, which would make the
user experience slow. In single-tier apps, the data is easily & quickly available since it is
located in the same machine.
Though it largely depends on how powerful the machine is & the hardware requirements of
the software, to gauge the real performance of a single-tier app.
Also, the data of the user stays in his machine & doesn’t need to be transmitted over a
network. This ensures data safety at the highest level.
Two Tier
A Two-tier application involves a client
and a server. The client would contain
the user interface & the business logic in
one machine. And the backend server
would be the database running on a
different machine.
The database server is hosted by the
business & has control over it.
Two Tier
Need ?
There are use cases where two-tier applications come in handy, for
instance, a to-do list app or a similar planner or a productivity app.
The application makes a call to the database server, only when the
user has finished creating his to-do list & wants to persist the
changes.
Another good example of this is the online browser & app-based
games. The game files are pretty heavy, they get downloaded on the
client just once when the user uses the application for the first time.
Moreover, they make the network calls only to keep the game state
persistent.
Also, fewer server calls mean less money to be spent on the servers
which is naturally economical.
Though, it largely depends on our business requirements & the use
case if we want to pick this type of tier when writing our service.
Three Tier
Three-tier applications are pretty popular & largely
used in the industry. Almost all of the simple websites
like blogs, news websites etc. are part of this category.
In a three-tier application the user interface,
application logic & the database all lie on different
machines & thus have different tiers. They are
physically separated.
So, if we take the example of a simple blog, the user
interface would be written using Html, JavaScript,
CSS, the backend application logic would run on a
server like Apache & the database would be MySQL.
A three-tier architecture works best for simple use
cases.
N Tier
An N-tier application is an application which has more than
three components involved.
What are those components?
Cache
Message queues for asynchronous behavior
Load balancers
Search servers for searching through massive amounts of data
Components involved in processing massive amounts of data
Components running heterogeneous tech commonly known as web
services
etc.
Single Responsibility Principle simply means giving one, just one responsibility to a component & letting it execute it
with perfection.
Be it saving data, running the application logic or ensuring the delivery of the messages throughout the system. This
approach gives us a lot of flexibility & makes management easier.
For instance, when upgrading a database server. Like when installing a new OS or a patch, it wouldn’t impact the other
components of the service running & even if something amiss happens during the OS installation process, just the
database component would go down. The application as a whole would still be up & would only impact the features
requiring the database.
We can also have dedicated teams & code repositories for every component, thus keeping things cleaner.
Single responsibility principle is a reason, why most people are against stored procedures. Stored procedures enable us
to add business logic to the database, which is a big no for most of the people.
What if in future we want to plug in a different database? Where do we take the business logic? To the new database? Or
do we try to refactor the application code & squeeze in the stored procedure logic somewhere? A database should not
hold business logic, it should only take care of persisting the data. This is what the single responsibility principle is. And
this is why we have separate tiers for separate components.
Why The Need For So Many Tiers?
Two software design principles that are key to explaining this are the Single Responsibility Principle &
the Separation of Concerns.
Separation of concerns kind of means the same thing, be concerned about your work only & stop worrying about
the rest of the stuff.
These principles act at all the levels of the service, be it at the tier level or the code level.
Keeping the components separate makes them reusable. Different services can use the same database, the messaging
server or any component as long as they are not tightly coupled with each other.
Having loosely coupled components is the way to go. The approach makes scaling the service easy in future when
things grow beyond a certain level.