DevOps Architecture

MONOLITHIC
ARCHITECTURE
Monolithic Architecture

A monolithic architecture is a traditional approach to designing software

where an entire application is built as a single, indivisible unit. In this
architecture, all the different components of the application, such as the user
interface, business logic, and data access layer, are tightly integrated and
deployed together.
Advantages of using a Monolithic Architecture
• Simplicity

• Development Speed

• Deployment

• Debugging
Disadvantages of using a Monolithic Architecture

Complexity

Scalability

Technology Stack

Deployment

Fault Tolerance
Microservice Architecture
In a microservice architecture, an application is built as a collection of small,
independent services, each representing a specific business capability. These
services are loosely coupled and communicate with each other over a
network, often using lightweight protocols like HTTP or messaging queues.
Advantages of using a Microservices Architecture
• Scalability
• Technology Stack
• Resilience – Reduce risk on failure
• Easier Maintenance
Disadvantages of using a Microservices Architecture

• Complexity
• Increased Overhead
• Deployment Complexity
• Monitoring and Debugging
• Cost
• Testing
Architecture Rules of Thumb
1. Use common sense - Dependencies and priorities of related factors forms the

boundaries of a solid solution.

2. Keep it simple - Simple components are easier for reuse, alternation,

enlargement and/or transformation.

3. Assumption is the mother of all failures - Testing patches before going to

production to avoid unwanted performance problems could be a myth if

not experienced before.
4. Devil is in the details – finding some strange behaviour at production
platform. The application behave other than it supposed to.
4. History is recursively evolving - new problems are not new and they are the same
dilemmas only within another shape
5. Fit for purpose but expect the unexpected
6. Each advantage has a disadvantage - what are the pros of cons? Comparing two
different solutions for certain problem.
7. Mark scope territory - The source of the most miscommunications in a discussion is
the scope and meaning of a subject.
8. Don't reinvent the wheel - Making mistakes is in fundament not bad but repeating
same mistake is wrong. The proper question before solving a problem will be, is it a
new problem, if not, what was the solution?
9. Do the right thing
Separation of concerns
• The separation of concerns (SoC) is one of the most fundamental principles
in software development.
• Separation of concerns is a principle used in programming to separate an
application into units, with minimal overlapping between the functions of
the individual units.
• The separation of concerns is achieved using modularization, encapsulation
and arrangement in software layers.
• Each module of your program serves a single purpose.
Database Migration
• In order to describe a database structure change, we issue a command to
change the structure.
• The database structures before and after a change is applied should be seen
as different versions of the database.
• Liquibase is a database migration system that, at its core, uses a tried and
tested method. There are many systems like this, usually at least one for
every programming language. Liquibase is well-known in the Java world
Generally, database migration systems employ some variant of the following
method:
• Add a table to the database where a database version is stored.
• Keep track of database change commands and bunch them together in versioned
changesets. In the case of Liquibase, these changes are stored in XML files.
Flyway employs a slightly different method where the changesets are handled as
separate SQL files or occasionally as separate Java classes for more complex
transitions.
• When Liquibase is being asked to upgrade a database, it looks at the metadata
table and determines which changesets to run in order to make the database up-to-
date with the latest version.
Resilience : an ability to recover from or adjust easily to misfortune or change.
It encompasses a range of characteristics that enable software to maintain its
functionality and integrity even under challenging conditions.
Resilience and failure management in DevOps are not just about building
systems that can survive unexpected failures, but about creating an infrastructure
that learns and adapts from these failures. Promoting a culture of continuous
learning and improvement is crucial for DevOps teams not only to respond to
failures but also to evolve because of them. This approach not only improves the
robustness and reliability of systems but also strengthens teams, making them
more adaptable and prepared for future challenges.