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.