0% found this document useful (0 votes)
11 views30 pages

M3 - Overview

Uploaded by

thecloudonfire
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views30 pages

M3 - Overview

Uploaded by

thecloudonfire
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 30

Futurense

Democratizing Tech Talent


to deliver impact at scale
M3. Overview
Introduction

Created by,
Sanju Abraham Binu
● Spring Boot is an open-source Java-based framework designed to simplify

the development of standalone, production-ready Spring applications.

● It is part of the larger Spring ecosystem and provides an easy, opinionated

way to create Spring applications by offering a range of defaults and pre-

configured options, which eliminates much of the boilerplate setup typically

required in traditional Spring projects.


● What is Spring Boot?

○ Definition: Spring Boot simplifies Java development by offering pre-

configured frameworks for building production-ready applications.

○ Main Features:

■ Embedded Servers (Tomcat, Jetty).

■ Minimal Configuration Required: Focus on business logic.


● Spring Boot Configuration

○ In Spring Boot, configuration refers to how you set up and customize your application’s behavior,

such as database connections, server settings, or logging levels.

○ Spring Boot simplifies this by providing default configurations out of the box, but you can easily

override them to fit your needs.

○ Externalized Configuration: Use application.properties or application.yml to define configurations

such as:

■ Database connections.

■ Server ports.

■ Logging levels.
● Auto-configuration in Spring Boot

○ Auto-configuration: Automatically configures beans based on classpath entries and

properties.

○ Example: Including spring-boot-starter-web automatically configures Spring MVC,

embedded Tomcat server, and required dependencies.

○ Benefits of Auto-configuration:

■ Faster development.

■ Reduces boilerplate code.


● ApplicationContext

○ A central interface for configuring the application.

○ Responsibilities:

■ Manage bean lifecycle.

■ Handle dependency injection.

■ Provide configuration metadata.

○ Benefits:

■ Easy to manage dependencies.

■ Centralized configuration for various environments (e.g., test, production).


● Service discovery is a way for different parts of an application (called services) to find and

communicate with each other automatically in a network.

● Imagine you have multiple small services working together, like pieces of a puzzle, to

make an application run. Instead of manually telling each service where the others are,

service discovery helps them "discover" or find each other on their own.

● This is especially useful in microservices architecture, where services are constantly being

added, removed, or moved to different locations.

● Tools like Eureka, Zookeeper, or Consul are often used to manage this discovery process.
● What is Service Discovery?

○ Definition: Mechanism by which services automatically register themselves and discover

other services.

○ Useful in distributed systems where services come and go dynamically.


● Introduction to Eureka

○ Eureka: A service discovery platform developed by Netflix.

○ Service Registry: Central server that maintains service metadata and enables discovery.

○ Heartbeat Mechanism: Services periodically send heartbeats to show they are alive.
● Eureka Workflow

○ How it Works:

■ Registration: Services register themselves with Eureka.

■ Discovery: Services query the Eureka server to find other services.

■ Health Monitoring: Eureka removes services that are unhealthy or have failed.
● Decomposition Guidelines:

○ Focus on the verbs and actions within the business problem as guideline used to identify and decompose a

business problem into microservice candidates

● Service Granularity:

○ Service granularity refers to how much functionality or responsibility a service handles in an application,

especially in microservices architecture.

○ It defines whether a service is broad and handles many tasks (coarse-grained) or focused and handles a

specific, smaller task (fine-grained).

○ The purpose of establishing service granularity in a microservice architecture is to define the scope and

responsibilities of each microservice


● Alternatives to Eureka

○ Zookeeper:

■ Coordination and service discovery platform that also manages distributed configuration.

○ Consul:

■ Provides service discovery, health checking, and KV storage.

○ When to Use: Choose based on your ecosystem, scalability needs, and complexity.

○ Decomposing a Monolith:

■ When decomposing a monolithic application like EagleEye into microservices, you start with

Identify nouns and verbs in the business problem to determine service boundaries
● What is an API Gateway?

○ Definition: A reverse proxy that forwards client requests to appropriate microservices.

○ Single Entry Point: All requests flow through the API Gateway.

○ Example: Netflix’s Zuul or Spring Cloud Gateway.


● Functions of an API Gateway

○ Routing: Routes requests to the correct microservice.

○ Composition: Aggregates responses from multiple services and composes them into a

single output.

○ Protocol Translation: Converts between protocols (e.g., HTTP, WebSockets).


● What is Service Granularity?

○ Granularity: Refers to how small or large a service is.

○ Coarse-grained: A service with broader functionality, handling many tasks.

○ Fine-grained: A service with a narrow focus, handling a single responsibility.


● Determining the Right Granularity

○ Coarse-grained Services: Easier to manage but may lead to too much responsibility in one

service.

○ Fine-grained Services: More modular but introduces complexity with inter-service

communication.
● Coarse-grained Microservices:

○ Starting with coarse-grained microservices and refactoring to finer-grained ones often

recommended as it avoids premature complexity and helps identify proper service

boundaries

● Service Design:

○ To design intuitive service interfaces in a microservices architecture, embrace the REST

philosophy with standard HTTP verbs


● Too Coarse-grained Service:

○ The microservice manages data across a large number of tables can be the primary

indication that a microservice is too coarse-grained.

● Creating a New Microservice:

○ Look for actions (verbs) that suggest separate operations is the best guideline helps

determine if a new microservice should be created while decomposing a business problem


● RESTful Service Design

○ REST (Representational State Transfer): Standard architectural style for designing

networked applications.

○ Use standard HTTP methods (GET, POST, PUT, DELETE).

○ Resources are represented as URIs.


● Best Practices for Service Interfaces

○ Use HTTP Verbs: GET for reading, POST for creating, PUT for updating, DELETE for removing

resources.

○ Status Codes: Use appropriate HTTP status codes (200 OK, 404 Not Found, 500 Server Error).

○ Data Format: Use JSON for request/response bodies for easy parsing and interoperability.

○ REST Guidelines:

■ Use standard HTTP verbs and URIs to represent resources is the strategy should be adopted when

defining service interfaces in a microservice architecture


● Managing Microservice Interdependencies

○ Problem: Services are calling each other frequently, leading to tight coupling and

interdependencies.

○ Impact: Increases complexity and system fragility.

● Identifying Bad Service Design

○ Frequent calls between services indicate bad decomposition.

○ Microservices should be self-contained and loosely coupled.


● Interdependent Microservices:

○ Microservices are heavily interdependent and call each other frequently to complete user

requests indicates that it is too fine-grained

● Recognizing Fine-Grained Service:

○ You can recognize that a microservice might be too fine-grained if it frequently

communicates with other microservices to complete a single request


● When NOT to Use Microservices

○ Small Applications:

■ Microservices introduce overhead.

■ Monolithic design may be simpler and more effective for small-scale apps.

● Avoid Microservices:

○ The complexity and cost of building distributed systems may outweigh the benefits in those

situations an organization avoid using microservices for small, departmental-level applications.


● General Best Practices

○ Decoupling: Keep services independent with well-defined interfaces.

○ Scaling: Scale services independently based on demand.

○ Monitoring: Implement monitoring tools (Prometheus, Grafana) to track service health and

performance.

○ Versioning APIs: Version APIs to manage backward compatibility when updating services.
Summary
● The primary role of an architect in microservices architecture is to provide a working model
of the problem to be solved.
● Centralizing data storage is NOT a key focus for an architect when building a microservices
architecture.
● To decompose a business problem into microservice candidates, focus on the verbs and
actions within the business problem.
● The purpose of establishing service granularity in a microservice architecture is to define
the scope and responsibilities of each microservice.
● Starting with coarse-grained microservices and refactoring to finer-grained ones is
recommended to avoid premature complexity and help identify proper service boundaries.
● If a microservice manages data across a large number of tables, it may be too
coarse-grained.
● When decomposing a monolithic application like EagleEye into microservices, it's
best to identify nouns and verbs in the business problem to determine service
boundaries.
● Designing intuitive service interfaces in microservices should embrace the REST
philosophy with standard HTTP verbs (GET, POST, PUT, DELETE).
● If microservices are heavily interdependent and call each other frequently, it
indicates that the microservices are too fine-grained.
● The complexity and cost of building distributed systems often outweigh the
benefits for small, departmental-level applications, making microservices less
suitable for such scenarios.
● A new microservice should be created by looking for actions (verbs) that suggest
separate operations in the business problem.
● The right strategy for defining service interfaces is to use standard HTTP verbs
and URIs to represent resources.
● Microservices might be too fine-grained if they frequently communicate with other
microservices to complete a single request.

You might also like