Python & Microservices

Section 1
HI M I CROSERVICES!

PURYA BEHZ ADPUR

Introduction
 Evolution of Software Development

- Computer programming is less than

100 years old

- Continuous improvement through

technology, design, and philosophy
Introduction: - Rapid evolution to enhance tools
and applications

Note: In this section, I introduced the

idea of constant improvement in
software development and highlights
the advancements made in a
relatively short span of time.
 Revolution of Microservices

- Microservices have transformed

software products
- Improved readability and scalability
of services

Introduction: - Speeded up release cycles and

responsiveness to customer needs

Note: In this section, I emphasized the

impact of microservices in
revolutionizing software development,
focusing on the benefits they bring in
terms of service quality and agility.
 The Need for Speed
- Desire to ship new products and
features quickly
- Agile approach with frequent
iterations
- Pushing experimental features to
production and removing if necessary
Introduction: Note: In this section, I highlighted the
importance of speed in software
delivery, emphasizing the need for
agile practices and the benefits of
quickly releasing and iterating on
features.
 Continuous Delivery and Automation
- Companies like Netflix promoting
continuous delivery
- Small changes made often in production
and tested on a subset of users
- Automation tools like Spinnaker to update

Introduction: production and ship features as

microservices
Note: In this section, I focused on the
adoption of continuous delivery and the use
of automation tools to streamline software
delivery, with Netflix as an example.
 Continuous Delivery and Automation
- Companies like Netflix promoting
continuous delivery
- Small changes made often in production
and tested on a subset of users
- Automation tools like Spinnaker to update

Introduction: production and ship features as

microservices
Note: In this section, I focused on the
adoption of continuous delivery and the use
of automation tools to streamline software
delivery, with Netflix as an example.
What is SOA?
 Point 0 of Microservices
- No official standard for microservices
- Microservices discussed in the context of
historical software design
- Service-Oriented Architecture (SOA) as a
starting point
- SOA encourages reusable software
components with well-defined interfaces

What is SOA? - Components can be reused and applied to

new situations

Note: In this section, I provided an overview

of microservices and their relation to SOA. It
emphasizes the absence of an official
standard for microservices and the historical
context of their development.
 Flexibility in Communication Protocols
- SOA does not enforce specific protocols for
service interaction
- Vagueness in deployment and organization
of applications
- Services can communicate via IPC, shared
memory, message queues, or RPC
- Extensive options for communication
What is SOA? protocols in SOA
Note: In this section, I discussed the flexibility
in communication protocols within SOA,
highlighting the absence of strict enforcement
and the various options available for service
interaction.
 Microservices as a Specialization of SOA
- Microservices focus on organization
needs, safety, scaling, and separation
- Microservices allow for the scaling and
separation of software
- Commonly considered a specialization
of SOA

What is SOA? - Enables a specific focus on the

organization's requirements
Note: In this section, I emphasized the
specialization of microservices within
the broader framework of SOA,
highlighting their benefits in terms of
organization needs, safety, and
scalability.
A Bit about Monolithic!
 A B IT A B OUT
MONOL IT H IC !

Introduction to Monolithic Architecture

- Monolithic architecture: API, database, and

tools managed in one code base

- Example: Hotel booking website with a

booking feature

- Steps involved in the search and booking

process

- Interactions with the database and external

services

Note: In this section, I introduced the concept of

a monolithic architecture using the example of a
hotel booking website. It describes the structure
of a monolith and the steps involved in the
search and booking process.
 Benefits of Monolithic Architecture
- Simplified development and test
coverage
- Clean and structured code
organization
- Single database for data storage
- Straightforward deployment and
A BIT scaling
ABOUT MONOLITHIC! Note: In this section, I highlighted the
benefits of a monolithic architecture,
including simplified development,
organized code structure, and
straightforward deployment and scaling
options. It also mentions the advantages
of having a single database for data
storage.
 Challenges of Monolithic Architecture
- Impact of large-scope changes on the entire
application(changing billing service or
database layer)
- Collateral damage from small changes
affecting different parts of the system
- Uncontrolled growth leading to messy code
and complex database migrations(spaghetti
code)
A BIT - Difficulty in managing capacity and scaling
specific features
ABOUT MONOLITHIC! (fewer people fully understand the
implications of every small change they
make.)
Note: In this section, I discussed the
challenges associated with monolithic
architecture, including the impact of large
scope changes, collateral damage from small
changes, uncontrolled growth, and
challenges in managing capacity and scaling
specific features.
 How To Solve them?
- Splitting the application into separate pieces
- Use of external libraries and frameworks
- Focus on business logic while externalizing
code into framework extensions and
packages
A BIT - Benefits of controlling application growth
through small packages
ABOUT MONOLITHIC!
Note: In this section, I introduced the concept
of microservices as a solution to the
challenges of monolithic architecture. It
emphasizes the idea of splitting the
application into separate pieces and utilizing
external libraries and frameworks to control
growth and focus on business logic.
 Bumps on this path
- Difficulty in scaling parts of the application
differently
- Dependency management and potential
dependency hell
A BIT - Accumulation of problems over time
ABOUT MONOLITHIC! Note: In this section, I discussed the
challenges, including the difficulty in scaling
different parts of the application
independently, dependency management
issues, and the accumulation of problems
over time.
Wow! microservices!
 WO W!
M IC ROS E RV ICE S!

The Microservice Approach

- The microservice approach involves organizing

code into separate components that run in separate
processes.

- A microservice is a lightweight application that

provides a narrow list of features with a well-defined
contract.

- It is a component with a single responsibility that

can be developed and deployed independently.

- This diagram illustrates a sample microservice

architecture.

Note: In this section, I Introduced the concept of the

microservice approach and highlight the benefits of
modularity and scalability.
 Components of the Microservice Architecture
1. Booking UI: A frontend service that generates the
web user interface and interacts with other
microservices.
2. PDF reports: A service that creates PDFs for
receipts or other documents.
3. Search: A service that provides a list of hotels
based on location.

Wow! 4. Payments: A service that interacts with a third-

party bank service and manages a billing database.
microservices! 5. Reservations: A service that manages
reservations and changes to bookings.
6. Users: A service that stores user information and
interacts with users via emails.
7. Authentication: An OAuth 2-based service that
provides authentication tokens for microservice
communication.
Note: In this section, I Described each microservice
and its specific role within the application.
 Communication and Data Handling
- Microservices can communicate using
different protocols, such as HTTP, JSON,
UDP, or gRPC.
- There is no centralized database, as each
Wow! microservice deals with its own data
structures.
microservices! - Data is exchanged in a language-agnostic
format like JSON, XML, or YAML through
HTTP requests and responses.
Note: In this section, I Explained the
communication protocol and data format
used in microservice architecture.
 Microservice Benefits
- The microservices architecture offers
several advantages over the monolithic
approach.
- In this presentation, we will discuss the
Wow! following benefits in detail:

microservices! - Separation of concerns

- Smaller projects to deal with
- More scaling and deployment options
Note: In this section, I Introduced the topic of
microservice benefits and outline the three
main advantages to be discussed.
 Separation of Concerns
- Each microservice can be developed
independently by a separate team.
- Evolution of the application is more
Wow! controlled, as changes in one microservice
have localized impact.
microservices! - Loose coupling improves project velocity
and follows the single responsibility principle.
Note: In this section, I Explained how
microservices enable independent
development and better control over
application evolution.
 Smaller Projects
- Microservices break down the complexity of
the project.
- Adding features as separate microservices
avoids increasing codebase complexity.
Wow! - Smaller projects enable faster iteration,
microservices! shorter release cycles, and easier refactoring.
- Risks are reduced when experimenting with
new technologies or frameworks.
Note: In this section, I Discussed how smaller
projects in microservices architecture
facilitate faster iteration and reduce risks.
 Scaling and Deployment
- Microservices allow for easier scaling based
on specific constraints.
- Each microservice can be deployed on
Wow! servers with suitable resources for its
requirements.
microservices! - Fine control over deployments enables
efficient scaling and resource allocation.
Note: In this section, I Highlighted the
scalability and deployment advantages
offered by microservices architecture.
 Pitfalls of Microservices
Wow! - Introduction to the topic and the importance
microservices! of being aware of the challenges when
coding microservices.
 Pitfall 1 - Illogical Splitting
- The first issue of a microservice architecture is how it gets
designed.

- There's no way a team can come up with the perfect

microservice architecture on their first shot.

- Some microservices, like the PDF generator, are an obvious use

case.

- However, when dealing with business logic, it's common for code
to move around before finding the right set of microservices.

Wow! - The design needs to mature with try-and-fail cycles.

- Adding and removing microservices can be more painful than

microservices! refactoring a monolithic application.

- Avoid splitting the app into microservices if the split is not

evident.

- If there's any doubt that the split makes sense, keeping the code
in the same app is the safe bet.

- It's easier to split apart some of the code into a new microservice
later than to merge two microservices back into the same code
base because the decision turned out to be wrong.

- For instance, if you always have to deploy two microservices

together or if one change in a microservice impacts the data
model of the other one, the odds are that you did not split the
application correctly and those two services should be reunited.
 Pitfall 2 - More Network Interactions
- The second problem is the number of
network interactions added to build the same
application.
- In the monolithic version, even if the code
gets messy, everything happens in the same
process.
- You can send back the result without having
Wow! to call too many backend services to build the
actual response.
microservices! - Questions raised:
- What happens when the Booking UI
cannot reach the PDF reporting service
because of a network split or a laggy service?
- Does the Booking UI call the other
services synchronously or asynchronously?
- How will that impact the response time?
- A solid strategy is needed to be able to
answer all those questions.
 Pitfall 3 - Data Storing and Sharing
- Another problem is data storage and
sharing.
- An effective microservice needs to be
independent of other microservices and
ideally should not share a database.
- Questions raised:

Wow! - Do we use the same users' IDs across all

databases, or do we have independent IDs in
each service and keep it as a hidden
microservices! implementation detail?
- Once a user is added to the system, do we
replicate some of her information in other
services' databases via strategies like data
pumping, or is that overkill?
- How do we deal with data removal?
- These are hard questions to answer, and
there are many different ways to solve those
problems, as we'll learn throughout the book.
 Pitfall 4 - Compatibility Issues
- Another problem happens when a feature
change impacts several microservices.
- If a change affects the data that travels
between services in a backward-incompatible
way, it can cause trouble.

Wow! - Questions raised:

- Can you deploy your new service, and will
microservices! it work with older versions of other services?
- Do you need to change and deploy several
services at once?
- Does it mean you've just stumbled on
some services that should probably be
merged back together?
- Good versioning and API design hygiene
help mitigate those issues.
 Pitfall 5 - Testing
- Lastly, when you want to do some end-to-end
tests and deploy your whole app, you have to
deal with many components.
- Need for a robust and agile deployment
process to be efficient.
- Importance of being able to play with your
whole application during development.

Wow! - Can't fully test things out with just one piece of
the puzzle, although having a clean and well-
defined interface does help.
microservices! - Many recent developments in cloud
orchestration tools, such as Kubernetes,
Terraform, and CloudFormation, make life much
easier when deploying an application that
consists of several components.
- They can be used to create test and staging
environments as well as production and
customer-facing deployments.
- The popularity of these tools has helped in the
success and adoption of microservices.
W OW !
M I CROSE RVICE S!

Identify domain-model boundaries for each

microservice
W OW !
M I CROSE RVICE S!

decomposing a traditional data model into

multiple domain models one domain
model per microservice or bounded
context
 What challenges will you have for us in separating and
crushing subsystems and databases?
Maintaining data integrity between multiple microservices:
Wow! • Integration events
microservices! How to read information from multiple microservices
• API gateway
• Read the database
 CAP Theory:
• Consistency:
When the client makes a request, we
must show the most up-to-date data to the
user or return an error
Wow! • Availability :
microservices! always Available!
• Partition Tolerance:
When microservices encounter problems.
The rest of the system should work
properly.
W OW !
M I CROSE RVICE S!

Sync communication between

microservices
W OW !
M I CROSE RVICE S!

Async communication between

microservices
THE END