12- Factor Apps

Jargons in cloud applications

• Elasticity
• Scalability
• Volatility
• Microservices
 12 factor Methodology
• Proposed by Heroku teams based on feedbacks
• A manifesto describing guidelines and best practices to follow when
designing a cloud-native application
• Goal was to synthesize best practices for deploying an app on Heroku and
provide developers who are new to the cloud with a framework for discussing
the challenges of cloud-native applications.
• Use declarative formats for setup automation, which minimizes time and cost for
new developers joining the project
• Have a clean contract with the underlying operating system, offering maximum
portability between execution environments
• Are suitable for deployment on modern cloud platforms
The 12 factors

The methodology includes twelve factors developers should think about when building native
cloud apps. The twelve factors are the following:
1. One code repository per application for multiple deployments
▪ A codebase is a versioned code repository (thanks to tools like Git, Mercurial, or SVN). From a codebase, you can
build immutable releases that can be deployed in different execution environments.
▪ A deployment is a running instance of the application.
▪ There are two simple anti-patterns. First, multiple applications must be split up and placed in separate codebases
if there are multiple applications from the same code base.
▪ Secondly, if several applications share a codebase, it would make sense to factor the code into a library (with its
own codebase) that will be used by the other applications.
2. Dependency isolation and declaration
▪ A cloud application does not assume the implicit existence of packages and dependencies at the system level
during its deployment.
▪ To work properly, the idea is to deploy the application with its dependencies. They form a “whole,” a kind of bundle. The
work to be done is to declare the dependencies explicitly and precisely upstream of the construction and isolate these
dependencies at runtime.
▪ This is possible thanks to tools such as Maven (Java), NuGet (.NET), Npm (Javascript), or Bundler (Ruby). They
allow you to define dependencies with precise versions in manifests and then ensure that the dependencies
are satisfied.
3. Store the configuration in the environment
▪ The idea is to separate the code from the configuration.
▪ The configuration concerns everything that can vary from one deployment to another: the URL of an SMTP
server, a database endpoint, the credentials to connect to an API like Twitter or Google Maps.
▪ They should not be confused with the application’s internal settings, which remain unchanged from one
deployment to another.
▪ To be able to deploy an application on several environments, you can’t define the configurations in the code.
We sometimes tend to put all this in an XML file, but this limits flexibility. This file will not be modified so that
the configurations will be the same for each deployment.
4. External services as attachable and detachable resources
▪ A Cloud application usually depends on external services (databases, file storage, SMTP server, …)
and connects to them via resources, usually a URL and credentials for authentication.
▪ We have seen below that these resources should not be hardcoded but rather set using external
configurations.
▪ Therefore, we have foreseen in the code that the environment’s configuration will allow connection
with any external service.
▪ The idea is to be able to detach and attach an external resource at any time. If one of the external
services fails, we simply modify the resource in the Cloud environment. You don’t need to touch
the code to change the external service for another one.
5. Build, Release and Run
Strictly separate built and run stages.
• The deployment of your application must be properly separated into
three non-overlapping non-dependent phases namely build, release and
run.
• The build phase constitutes the compilation of the code which in the end
generates the artifact like a JAr or WAR file.
• The second phase, release, take the artifact file generated at the end of
the previous phase and adds the configurations for a particular
environment to it.
• The last phase includes the running of the instance of the application.
6. Processes
Execute the application as one or more stateless processes.
• An application is said to follow this principle if its instances can be
created and destroyed any time without making any effect on the overall
functionality of our application.
• To achieve and fulfill this principle, our application must store any type of
data generated by it in any persistent (stateful) datastore. But it doesn’t
mean that we can’t use the in-memory of the processes of our
application. We can use it to store as temporary storage.
• In simple terms, the usage of sticky sessions must be avoided. Sticky
sessions, in simple terms, refers to catching the logged-in user’s session
data in the local memory of the process and then directing each
subsequent request from that particular user to the same process.
• The problem with sticky sessions is that it causes uneven load balancing
among the instances of the application.
7. Port Binding
Export services via port binding.
• Any application that follows this principle is completely self-contained
and standalone. It exports HTTP as a service and doesn’t require any
server like a tomcat to listen to requests.
• It binds itself to some particular port and listens to all the requests hitting
on that port.
• You must also have observed it while designing an application or a
microservice which runs on a particular port and you hit requests on that
particular port using postman to get a response.
• This information that to which port our service will be listening to is also
stored in the configuration file itself.
8. Concurrency
Scale out via the process model.
• An application that follows this principle must be divided into
smaller different processes instead of a single large
application.
• Each such process must be able to start, terminate and
replicate itself independently and at any time. This principle
allows scaling our application very easily.
• By scaling out we refer to horizontal scaling in which we run
multiple instances of our processes. It adds concurrency to our
application in a very simpler way due to the existence of
independent horizontally scalable processes.
9. Disposability
Maximize robustness with fast startup and graceful shutdown.
• Robustness of an application refers to the graceful starting and
termination of its processes without affecting the overall
application’s functionality.
• For example one of the processes of our application is storing
the details of a newly added employee to the company into a
database.
• But while doing so, in between an unexpected error occurs
which causes the process to terminate in between
unexpectedly.
• However, the state of our application or database must not be
affected by it and the process must fail-safe. Also, it must start
quickly whenever required.
10. Development/Production Parity
Keep development, staging, and production as similar as
possible.
• It simply means that the development and production
environment must be as similar as possible.
• The processes being used, technologies and the infrastructure
must be the same.
• This will help you in a way that whatever error that can happen
over time will happen at the development stage itself instead
of surprisingly occurring in the production.
• This helps in the continuous deployment of our application and
reduces the development time and efforts also.
11. Logs
Treat logs as event streams.
• Logs are very essential to understand the internal working of
the application and it can be of different levels and are
generally stored in a file named “logFile” in the storage. Ideally,
our twelve-factor application must not be worried about the
storage of the logs.
• Whenever a request enters into the system, corresponding
logs are made and they are treated as a sequence of events
that can be used to debug when some problem occurs.
12. Admin Processes
Run admin/management tasks as one-off processes.
• Most of the applications require a few one-off tasks to be
executed before the actual flow of the application starts.
• These tasks are not required very often and hence, we
generally create a script for it which we run from some other
environment.
• On the other hand, the twelve-factor methodology says that
such scripts must be made a part of our codebase itself
managed in the version control system.
• These tasks should also follow twelve-factor principles.
Application Integration Process
• Process of enabling the communication
• Low code/No code
• This process is divided into 4 parts
• Protocol(HTTP, Files, XML, AMQP
• Formats (EDI-B2B, HL7-Helathcare, Swift
• SaaS Connectors (RestAPIs – Create, Update, Read, Delete)
• Data operations (Routing and Transformation, Filtering, publications/subscriptions)
12- Factor Apps
Jargons in cloud applications
• Elasticity
• Scalability
• Volatility
• Microservices
 12 factor Methodology
• Proposed by Heroku teams based on feedbacks
• A manifesto describing guidelines and best practices to
follow when designing a cloud-native application
• Goal was to synthesize best practices for deploying an
app on Heroku and provide developers who are new to the
cloud with a framework for discussing the challenges
of cloud-native applications.
• Use declarative formats for setup automation, which minimizes time and
cost for new developers joining the project
• Have a clean contract with the underlying operating system, offering
maximum portability between execution environments
• Are suitable for deployment on modern cloud platforms
The 12 factors

The methodology includes twelve factors developers should think about when building native
cloud apps. The twelve factors are the following:
1. One code repository per application for multiple deployments
 A codebase is a versioned code repository (thanks to tools like Git, Mercurial, or SVN). From a codebase, you can
build immutable releases that can be deployed in different execution environments.
 A deployment is a running instance of the application.
 There are two simple anti-patterns. First, multiple applications must be split up and placed in separate codebases
if there are multiple applications from the same code base.
 Secondly, if several applications share a codebase, it would make sense to factor the code into a library (with its
own codebase) that will be used by the other applications.
2. Dependency isolation and declaration
 A cloud application does not assume the implicit existence of packages and dependencies at the system level
during its deployment.
 To work properly, the idea is to deploy the application with its dependencies. They
form a “whole,” a kind of bundle. The work to be done is to declare the dependencies
explicitly and precisely upstream of the construction and isolate these dependencies
at runtime.
 This is possible thanks to tools such as Maven (Java), NuGet (.NET), Npm
(Javascript), or Bundler (Ruby). They allow you to define dependencies with
precise versions in manifests and then ensure that the dependencies are
satisfied.
3. Store the configuration in the environment
 The idea is to separate the code from the configuration.
 The configuration concerns everything that can vary from one deployment to
another: the URL of an SMTP server, a database endpoint, the credentials to
connect to an API like Twitter or Google Maps.
 They should not be confused with the application’s internal settings, which
remain unchanged from one deployment to another.
 To be able to deploy an application on several environments, you can’t define
the configurations in the code. We sometimes tend to put all this in an XML
file, but this limits flexibility. This file will not be modified so that the
configurations will be the same for each deployment.
4. External services as attachable and detachable resources
 A Cloud application usually depends on external services (databases,
file storage, SMTP server, …) and connects to them via resources,
usually a URL and credentials for authentication.
 We have seen below that these resources should not be hardcoded but
rather set using external configurations.
 Therefore, we have foreseen in the code that the environment’s
configuration will allow connection with any external service.
 The idea is to be able to detach and attach an external resource at
any time. If one of the external services fails, we simply modify the
resource in the Cloud environment. You don’t need to touch the code to
change the external service for another one.
5. Build, Release and Run
Strictly separate built and run stages.
• The deployment of your application must be properly separated into three
non-overlapping non-dependent phases namely build, release and run.
• The build phase constitutes the compilation of the code which in the end
generates the artifact like a JAr or WAR file.
• The second phase, release, take the artifact file generated at the end of the
previous phase and adds the configurations for a particular environment to
it.
• The last phase includes the running of the instance of the application.
6. Processes
Execute the application as one or more stateless processes.
• An application is said to follow this principle if its instances can be created
and destroyed any time without making any effect on the overall
functionality of our application.
• To achieve and fulfill this principle, our application must store any type of
data generated by it in any persistent (stateful) datastore. But it doesn’t
mean that we can’t use the in-memory of the processes of our application.
We can use it to store as temporary storage.
• In simple terms, the usage of sticky sessions must be avoided. Sticky
sessions, in simple terms, refers to catching the logged-in user’s session
data in the local memory of the process and then directing each
subsequent request from that particular user to the same process.
• The problem with sticky sessions is that it causes uneven load balancing
among the instances of the application.
7. Port Binding
Export services via port binding.
• Any application that follows this principle is completely self-contained and
standalone. It exports HTTP as a service and doesn’t require any server like
a tomcat to listen to requests.
• It binds itself to some particular port and listens to all the requests hitting
on that port.
• You must also have observed it while designing an application or a
microservice which runs on a particular port and you hit requests on that
particular port using postman to get a response.
• This information that to which port our service will be listening to is also
stored in the configuration file itself.
8. Concurrency
Scale out via the process model.
• An application that follows this principle must be divided into
smaller different processes instead of a single large application.
• Each such process must be able to start, terminate and replicate
itself independently and at any time. This principle allows
scaling our application very easily.
• By scaling out we refer to horizontal scaling in which we run
multiple instances of our processes. It adds concurrency to our
application in a very simpler way due to the existence of
independent horizontally scalable processes.
9. Disposability
Maximize robustness with fast startup and graceful shutdown.
• Robustness of an application refers to the graceful starting and
termination of its processes without affecting the overall
application’s functionality.
• For example one of the processes of our application is storing
the details of a newly added employee to the company into a
database.
• But while doing so, in between an unexpected error occurs
which causes the process to terminate in between unexpectedly.
• However, the state of our application or database must not be
affected by it and the process must fail-safe. Also, it must start
quickly whenever required.
10. Development/Production Parity
Keep development, staging, and production as similar as possible.
• It simply means that the development and production
environment must be as similar as possible.
• The processes being used, technologies and the infrastructure
must be the same.
• This will help you in a way that whatever error that can happen
over time will happen at the development stage itself instead of
surprisingly occurring in the production.
• This helps in the continuous deployment of our application and
reduces the development time and efforts also.
11. Logs
Treat logs as event streams.
• Logs are very essential to understand the internal working of the
application and it can be of different levels and are generally
stored in a file named “logFile” in the storage. Ideally, our
twelve-factor application must not be worried about the storage
of the logs.
• Whenever a request enters into the system, corresponding logs
are made and they are treated as a sequence of events that can
be used to debug when some problem occurs.
12. Admin Processes
Run admin/management tasks as one-off processes.
• Most of the applications require a few one-off tasks to be
executed before the actual flow of the application starts.
• These tasks are not required very often and hence, we generally
create a script for it which we run from some other environment.
• On the other hand, the twelve-factor methodology says that
such scripts must be made a part of our codebase itself
managed in the version control system.
• These tasks should also follow twelve-factor principles.
Application Integration
Process
• Process of enabling the communication
• Low code/No code
• This process is divided into 4 parts
• Protocol(HTTP, Files, XML, AMQP
• Formats (EDI-B2B, HL7-Helathcare, Swift
• SaaS Connectors (RestAPIs – Create, Update, Read, Delete)
• Data operations (Routing and Transformation, Filtering,
publications/subscriptions)
API FUNDAMENTAL
What's an API?

• API stands for application programming interface.

• An API is basically a set of definitions and protocols that enable two applications
to talk to one another.
• APIs are the connectors that enable most of the communications between the
web applications, or apps, that we use today.
• APIs work by communicating with, and exchanging data between, other systems.
• They act as the messengers between us, the users, and the backend systems,
allowing us to retrieve the data we want, when we want it.
API basics

• In software terms, APIs are a set of functions and procedures that

allow application developers to create apps that use the data and
features of other services and applications.
• There are three main types of APIs:
• Open APIs, which are publicly available with minimal restrictions to access them.
• Partner APIs, which need specific access rights to be able to use them and are
typically exposed via an API developer portal.
• Internal APIs, which are hidden from external users and only exposed by internal
systems. Typically, these are exposed via an internal API developer portal to
enable authorization to the right set of APIs.
 Open APIs
•Open APIs (also called public APIs) are application programming interfaces that are
publicly available to developers and other users.
•They allow external developers to access specific features or data from an application, service,
•or platform.
•Unlike private or partner APIs, open APIs can be used without a strict relationship with the provider.

•Often RESTful (using HTTP methods like GET, POST)

•Publicly accessible, usually with documentation
•Can have authentication (like API keys) but often easy to obtain
•Encourage third-party developers to build on top of the API’s platform
•Typically used for integrations, mashups, or building new applications
Partner APIs
• Partner APIs are APIs that are not fully public but are made available to specific, authorized
partners or developers under certain agreements or conditions.
• Unlike open APIs, partner APIs are restricted to trusted partners.
• Access usually requires authentication, agreements, or contracts.
• They often provide more sensitive or powerful functionality/data than open APIs.
• They help companies create strategic partnerships and control how their APIs are used.
• Access is limited to select partners (not open to everyone)
• Often more comprehensive or sensitive data/functionality
• Require authentication and authorization (API keys, OAuth tokens)
• May include service-level agreements (SLAs) for reliability or support
• Used to create deeper integrations and collaborations
Internal APIs
• Internal APIs (also called private APIs) are APIs used within an organization to enable
communication and integration between different internal systems, teams, or services.
• They are not exposed to external developers or partners.
• Designed to improve internal software architecture by enabling modularity and reusable
components.
• Help different teams within a company build on each other’s work smoothly and securely.
• Strictly for internal use only
• Not publicly documented or accessible outside the organization
• Focus on security, performance, and internal workflow
• Can be rapidly changed or updated since they don’t need external backward compatibility
• Often part of a microservices architecture or used to connect backend systems
• Encourage code reuse and modular system design
• Allow different teams to work independently yet stay integrated
• Improve security by limiting API exposure
• Enable rapid iteration without worrying about breaking external users
• There are also two different ways that APIs can be implemented:
• Simple APIs, which are available separately.

• Composite APIs, where multiple data or service APIs are combined together,
allowing developers to access several APIs at a time.
Types of API protocols
• To be able to use APIs effectively, developers must adhere to a common
set of rules, or protocols, when making API calls.
• The term API call simply refers to the process of communicating with an
API; in other words, an API call is when data is sent to and retrieved
from an API endpoint.
• There are three main types of API protocols:
• REST. REST is short for Representational State Transfer and is a web
services API.
• It provides a uniform interface, where a client and server communicate with
one another via Hypertext Transfer Protocol ( HTTP) , by using Uniform
Resource Identifiers ( URIs) , the common Create, Read, Update, and
Delete ( CRUD) operations, and most often JavaScript Object Notation
( JSON) conventions for data exchange.
• SOAP. SOAP is short for Simple Object Access Protocol and is another
type of web services API.
• SOAP APIs have been used since the 1990s, but the protocol is stricter
and more heavyweight than REST, so it isn’t used as much in modern API
development.
• RPC. RPC is short for Remote Procedural Call and is the oldest and
simplest type of API protocol.
• RPC is a request- response protocol, where a client sends a request to
a remote server to execute a specific procedure, and then the client
receives a response back.
• However, RPC APIs are much more difficult to maintain and update than
REST APIs, so again RPC APIs aren’t used as much in modern API
development.
 Styles of API development
• Here are the five main styles of API development:
I. Tunnel.
1. In this style, the API is a collection of functions that can be called remotely.
2. A common technology used in this style is Remote Procedure Call method.
3. The tunnel style is focused on making specific computer functions available.
4. This is a popular style; for example, gRPC is an open source remote procedure call framework you can
use to develop APIs.
II. Resource
1. In this style, the API is a collection of resources that can be interacted with.
2. This style is likely the most popular style for public APIs, enabling resources like products,
customers, and other data to be accessed.
3. A common technology that’s used for this API style is HTTP that calls an API that’s been written
following the OpenAPI specification.
III. Hypermedia.
I. This style is an enhancement of the Resource style. In this style, the API is a collection of interlinked
resources, which is very much how web apps are delivered.
II. Similarly, this style often uses HTTP calls to an OpenAPI-described service, with the difference being
that the data also includes controls to link the resources together.
IV. Query.
I. In this style, the API exposes a structured data model that can be queried and updated
by using a generic query language.
II. This style is usually used when you have a large amount of data, where the API needs
to query the dataset and return just the data needed for that query.
III. A very popular example of a technology that uses this style is GraphQL, as noted
previously.
IV. GraphQL is a very flexible query language that allows you to ask for specific sections
of a large data model, thereby enabling API developers to interrogate large amounts of
data much more efficiently.
V. Event.
I. In this style, the communication pattern is reversed, and the API listens for events
instead of asking for information.
II. In most cases with event style APIs, the API works in what is called a
publish/subscribe (pub/sub) model, where API consumers listen out for events that they’ve
subscribed to.
III. For example, your API might listen out for when a particular product is bought, and
then take an action based on that. One of the most popular event style technologies
is Kafka.
Benefits of API development
Speed. Having a library of reusable APIs speeds up application
development and ongoing app evolution.

Security. APIs enable you to securely expose systems of record and

business logic to mobile, web, and cloud apps.

Socialize. Publishing APIs expands your brand reach and enables you to
tap into broader developer and partner ecosystems to drive innovation.

Monetize. Enable new business channels by charging money for the use of,
or rate of use of, the APIs that can access your data and algorithms.
API Management
• How do I ?
• FIND
• SECURE
• PROTECT
• UNDERSTAND
• CONTROL
• GOVERNANCE
Control Plane
• Create API
• Define API Policies

All requests for control plane operations are sent to the Azure Resource Manager URL. That URL varies by the
Azure environment.

 For Azure global, the URL is [Link]

 For Azure Government, the URL is [Link]

 For Azure Germany, the URL is [Link]

 For Microsoft Azure operated by 21Vianet, the URL is [Link]

API
•
Gateway
An API gateway acts as a single entry point for handling client requests to various backend
services, especially in microservices architectures. It manages traffic, enforces security
policies, and can perform tasks like authentication, authorization, routing, and protocol
translation. Essentially, it simplifies interactions between clients and complex backend
systems.

• Single Entry Point: The API gateway sits between clients and backend services, acting as a reverse
proxy. Clients interact with this single point, rather than directly with multiple microservices.
• Request Routing: It intelligently routes incoming requests to the appropriate backend services based on
defined rules and configurations.
• Authentication and Authorization: API gateways handle authentication (verifying the identity of the
client) and authorization (determining what resources the client has permission to access).
• Security Policies:They enforce security rules, such as rate limiting (controlling the number of requests
from a client), and ensure secure communication (e.g., SSL/TLS offloading).
• Request Transformation: API gateways can translate requests and responses between
different formats or protocols used by clients and backend services.

• API Composition: They can combine responses from multiple backend services into a single,
coherent response for the client.

• Caching: API gateways can cache frequently accessed data to improve performance and
reduce load on backend services.
Scaling of Managed Gateway’s
• Number of units allocated to each Region
• According to the subscription mode ( e.g. Premium 10 units)

API Region 1
URL1 GW
scale

API Region 2
URL2 GW
scale
• Naming – provided
Traffic manager <Service>-<Region>-01-<Region>-02-…-[Link]
1. Vertical Scaling (Scaling Up):
• Involves increasing the CPU, memory, or other resources of individual gateway instances.
• Suitable when a single gateway instance is nearing its capacity, but the overall number of
concurrent requests is manageable.
• May be a simpler option initially, but has limits on how much capacity can be added.
2. Horizontal Scaling (Scaling Out):
• Involves adding more gateway instances to the cluster, distributing the load across
multiple machines.
• Allows for greater scalability and capacity, as more instances can be added as needed.
• Requires proper load balancing and potentially more complex management of the cluster.
• As each API gateway is enabled to provide resource those can be used individually
by the other application directly through the URLs
• Each Customer need to rely on the traffic manager
• API Gateway communicates with the APIs with Private Ips or Public Ips
• It must have IP path for Public IP
• For Private IP it should have VNET.
• API Gateway going to INJECT itself to VNET subnet
• Firewall rules are applied to IP path avoid direct connection between Application
and APIs
 Unit - 2 API
Testing Tools
SoapUI is a specialized tool designed for testing REST, SOAP, and GraphQL APIs.
It offers a comprehensive API testing solution with a strong emphasis on convenience
for developers and testers through its user-friendly graphical interface.
The tool enables the execution of automated functional, regression, and load tests,
making it suitable for various testing scenarios.
• Functional Testing: It allows you to Create and
manage test cases and suites for comprehensive API
validation.
• Mock Services: You can Simulate API responses with
mock services for development and testing.
• Security Testing: Identify and test for security
vulnerabilities in APIs.
• Load Testing: Evaluate API performance under
various load conditions.
• Cross-Platform Support: Available on Windows,
macOS, and Linux.
• Service Inspection: Discover and inspect WSDLs and
OpenAPI specifications.
• Mock Services: Simulate API behavior with mock
services to test without relying on the actual
API.
Advantages of SOAPUI
SoapUI offers several key benefits that make it a preferred choice for API testing:
 Thorough API Testing: SoapUI provides a wide range of tools and features that enable
comprehensive API testing. It supports testing for REST, SOAP, and GraphQL APIs,
allowing testers to evaluate various types of APIs in one platform.
 Open-Source Code Methodology: Being based on an open-source code methodology,
SoapUI allows users to access and modify its source code. This offers greater flexibility
and customization options to tailor the tool according to specific testing requirements.
 One-Stop Solution: SoapUI’s versatility and various functionalities make it a complete
and all-inclusive solution for API testing. Whether it’s functional, regression, or load
testing, the tool covers all essential aspects of API evaluation, eliminating the need for
multiple testing tools.
Disadvantages
• Lower Stability: Some users have reported that
SoapUI may have occasional stability issues,
leading to crashes or unexpected behavior during
testing. While the tool is generally reliable,
these instances of instability can be frustrating
for users.
• Steep Learning Curve: SoapUI’s interface and
features can be overwhelming for first-time users,
especially those new to API testing. Navigating
through the tool and understanding its
capabilities may require some initial effort and
training.
• Dependency on WSDL for Web Service Testing: SoapUI
heavily relies on Web Services Description
Language (WSDL) files for testing web services.
While WSDL is a standard way to describe web
services, some APIs might not have well-defined or
• Test Studio by Progress Telerik provides a
user-friendly and easy-to-maintain testing
solution for users. It offers seamless
integration of RESTful APIs into various
environments, enabling efficient API testing.
• With Test Studio, users can automate API
testing without the need for coding, ensuring
thorough validation of the model’s integrity
and reliability.
• In summary, Test Studio streamlines the API
testing process by offering a simple and code-
free approach, making it accessible to a
broader range of users while ensuring the
accuracy and dependability of the tested APIs.
• API Functional Testing: Create and execute
tests to verify API functionality and
responses.
• Assertions: Validate API responses with built-
in assertions or custom conditions for precise
verification.
• Mock Services: Simulate API behavior with mock
services to test interactions without relying
on live endpoints.
• Automated Test Execution: Schedule and run API
tests automatically as part of a CI/CD
pipeline.
• Performance Testing: Assess API performance
with built-in tools for load and stress
testing.
Advantages of Test Studio

• User-Friendly Interface: Test Studio provides a user-

friendly and intuitive interface, making it easy for
both technical and non-technical users to create and
manage test cases effectively. Its visually-driven
testing approach reduces the learning curve and
enhances productivity.
• Codeless Automation: One of the standout features of
Test Studio is its codeless automation capabilities.
Users can automate test scenarios without writing
extensive code, which accelerates the testing process
and allows testers with limited coding knowledge to
contribute effectively.
• End-to-End Testing: Test Studio supports end-to-end
testing, covering various aspects of the application,
including APIs, web, desktop, and mobile. This all-in-
one testing solution simplifies the testing process and
Limitations of Test Studio

• Cost: Test Studio is a commercial testing tool,

and its licensing cost may be a significant factor
for small teams or individual testers with limited
budgets. The pricing structure may not be feasible
for all organizations, especially those looking
for free or open-source alternatives.
• Learning Curve: Despite its user-friendly
interface, Test Studio may still have a learning
curve, especially for users who are new to
automated testing tools or those with limited
technical background. Training and getting
accustomed to the tool’s features may take some
time.
• Limited Platform Support: Test Studio may have
limitations in terms of supporting certain
platforms or technologies, which could be a
concern for organizations working with specific
• Postman is a leading API testing tool that is
compatible with Linux, MacOS, and Windows
operating systems. It offers a wide range of
features, allowing users to create functional,
integration, and regression tests efficiently.
• Users can choose between using the Command Line
Interface (CLI) or a Graphical User Interface
(GUI) that is easy to navigate.
• User-Friendly Interface: Postman provides an
interface that caters to users of all levels.
Experienced testers can leverage its scripting
capabilities, while beginners can achieve good
results without much complexity using the GUI.
• Automated Testing: Postman supports automated
testing, enabling users to monitor APIs and
execute various requests for testing and
debugging purposes. This automation streamlines
the testing process and improves efficiency.
• Runtime Support for Popular Patterns and
Libraries: Postman’s runtime supports widely
used patterns and libraries, facilitating quick
testing and debugging of APIs with familiar
Advantages of Postman
• User-Friendly Interface: Postman’s intuitive and user-
friendly interface makes it accessible to users of all
levels, including beginners and experienced testers.
• Cross-Platform Compatibility: Postman is compatible with
Linux, MacOS, and Windows, allowing users to access and
utilize the tool on different operating systems.
• Versatile Testing Capabilities: Postman supports various
testing types, including functional, integration,
and regression testing, enabling comprehensive API
evaluation.
Limitations
• Dependency on Cloud Features: Some advanced features in
Postman, such as API monitoring, require a cloud
subscription, which may involve additional costs for
organizations.
• Limited Offline Capabilities: While Postman offers some
offline functionality, certain features may require an
internet connection, which can be restrictive in certain
testing environments.
• Learning Curve for Advanced Features: Although Postman’s
basic functionalities are easy to grasp, leveraging more
• OWASP ZAP (Zed Attack Proxy) is a widely used
open-source security testing tool designed to
help identify and prevent security
vulnerabilities in web applications.
• It is one of the projects maintained by the
Open Web Application Security Project (OWASP),
an organization focused on improving the
security of software.
• Web Application Security Testing: OWASP ZAP is
primarily used for security testing of web
applications. It can assess and identify common
security vulnerabilities like cross-site scripting
(XSS), SQL injection, cross-site request forgery
(CSRF), and more.
• Intercepting Proxy: OWASP ZAP acts as an
intercepting proxy, allowing testers to monitor
and modify requests and responses between the
client and the web server. This enables users to
inspect and manipulate the application’s traffic
for security testing purposes.
• Automated Scanning: The tool offers automated
scanning capabilities to identify security
vulnerabilities in web applications quickly. Users
• REST Assured is a popular testing framework for RESTful
APIs that caters to developers familiar with the Java
programming language.
• It simplifies API testing by providing a convenient
syntax, allowing testers to create requests without the
need to write code from scratch.

• No Need to Understand HTTP: Users of REST Assured do

not require an in-depth understanding of the HTTP
protocol, as the framework abstracts the complexity and
provides a user-friendly interface for API testing.
• Java Compatibility: REST Assured is designed for Java
developers and can be easily integrated into Java
projects. Users need Java version 8.0 or higher to
utilize the tool effectively.
• Integration Testing: REST Assured supports integration
testing, enabling users to test API endpoints and
Fundamental technology shift
 Mainframe computing
 Client/Server
 Cloud Computing
Microservices
 Current prevailing approach for large scale globally distributed
applications
 Common choice for new development projects for business software
 Many organizations are also evolving existing monolithic applications
to Microservices
What are microservices?
 A model of technical architecture
 Smallindependent functional applications
 Each microservices built on appropriate technical components

 A software development pattern

 Decentralization of technical components
 Distributed programming

 Responsibility to deploy, operate, and maintain services

From apps to systems
 Many microservices are assembled to create a complex business
application
 Separate independent components
 Brought together via middleware or API gateway
An internal architecture
 Not necessarily apparent to users whether the application is based on
microservices
 Needed for fast performance, high availability, extreme transaction
loads
 Decentralized architecture does not imply fragmented user
experience
Who uses Microservices
 Uber
 Netflix
 Amazon
 Ebay
 Twitter
 PayPal
Netflix microservice architecture
Building a microservice
 Small unit of functionality
 Complete and independent technology stack
 Separate data stores
 Synchronization with other services as needed through persistence layers
 Invoked through API Request / Response
 Usually: REST, HTTP, JSON
 Self-contained components
 Inner workings not exposed externally
 Developers have free to select tech components
Microservice conceptual model
Request Response
REST / HTTPS

Web service

Service components

Microservice
Application
software
Run time libraries

Data Store
Assembling an application
 Each microservice performs a small limited task
 Not intended to be standalone applications
 Surrounded by specialized infrastructure
 Manage communications
 Orchestrate services into complex chains of tasks
 Load balancing
 API Gateway
 User Interface layer
 Externally exposed APIs
 Multiple instances of any microservice launched as needed
 Microservices-based Application
Scripts/
User Third Party Systems
Interfaces API endpoints

Presentation Layer / UI Toolkit

API Gateway

Web service

Service
component
s
Web service Web service
Web service
Service Service Web service
component Service component
component Microservice
s s Service
s
component
Web service s
Web service Web service Application
Microservice Microservice Web service
Microservice Web service Service software
Service Service component
component Service
component
Service s Microservice
s s component
Application component Application s Run time libraries
software Application s
software
software Application
Microservice
Microservice Microservice software
Microservice
Run time libraries Microservice Run time libraries
Run time libraries
Application Data Store
Application Application Run time libraries
Application software
software software Application software
software
Data Store Data Store Run time libraries
Run time libraries Run time libraries Data Store
Run time libraries
Run time libraries Data Store

Data Store
Data Store Data Store
Data Store
Data Store

Persistence / System
Layer
Beyond Virtual Machines to Containers
 Virtual machines are a common technology for optimizing use of
computing hardware
 Most applications use a small portion of computing and storage
capacity
 VM managers enable multiple instances of operating environments to
co-exist on each physical server
Virtual Machine Environment
 Multiple Virtual Machines can
VM-1 VM-2 VM-3 VM-4
share a single physical server
 VMs allocated via a Virtual
Apps Apps Apps Apps
Machine Monitor or Hypervisor
Code
libraries
Code
libraries
Code
libraries
Code
libraries
 Each VM contains its own
operating system, code
Guest
OS
Guest
OS
Guest
OS
Guest
OS libraries, applications, web
services, and other components
Virtual Machine Monitor
 Each VM independent: can host
Host operating system
any OS, libraries, apps
Server Hardware
Containers
 Server hardware provides OS Kernel to any
container
 Code libraries and binaries, memory, disk
m m m m m m m m
storage, and other resources residing on the
i i i i i i i i server can be provisioned to any container
c c c c c c c c
r r r r r r r r  Containers can be rapidly deployed based on
o
s
o
s
o
s
o
s
o
s
o
s
o
s
o
s
pre-defined configuration sets
e
r
e
r
e
r
e
r
e
r
e
r
e
r
e
r
 Containers require fewer resources: do not run
v v v v v v v v an entire copy of OS and support services
i i i i i i i i
c c c c c c c c  Containers can differ or replicate
e e e e e e e e
 High demand microservices may require many
Binaries / Libraries set A Bins / Libs B
instances
Container Engine (eg: Docker)  Containers share resources but are designed
Host operating system
to be rigidly independent
 Container engine ensures against resource
collisions
Server Hardware
API Gateway
 Requests to microservices usually not made directly from external agents
 Need a layer to manage access to Microservices to enable flexible
deployment
 Multiple microservices may be required to perform a complex task, usually
many instances of each microservice
 API Gateways provide a single entry point for all requests into the
application.
 Developers do not need to know physical address of each service (nothing
should be hardwired)
 Manage authentication, protocol conversions, communications, routing, load
balancing
DevOps
 Merges development with operations
 A single team takes responsibility for development, deployment,
operations, and maintenance of a microservice
 Make independent technology decisions
 Programming language
 Databases

 (probably limited to contain technical overhead for the organization)

 No need to understand all aspects of the application
Contracts
 Any given microservice will not necessarily be aware of all the ways
in which it is consumed
 Microservices must be persistent to avoid failures in the broader
application / ecosystem
 Agreement to provide specific requests/responses
 Versioning is an essential characteristic
 Any deprecation must be (technically) negotiated and propagated
through the microservice ecosystem
 Functionality cannot be withdrawn until it is no longer required
Docker
 Leading technical environment for the management of containers
 Supported in most infrastructure environments
 Amazon Web Services
Containers
 Allocate computing resources in even smaller increments than Virtual
Machines
 Share low-level components
 Self-contained pre-configured operating environment
 Container management environments provide fast and easy approach
to deploy microservices or other computing components
 Used in all types of computing environments, but especially well suited
to microservices.
Container orchestration
 In a complex environment tools are needed to manage the
deployment of containers
 Components need to be allocated and deallocated dynamically
based on load and demand
 Examples:
 DockerSwarm
 Kubernentes (developed by Google)

 Apache Mesos
Benefits of Microservices
 Rapid development
 Quick path to MVP (minimal viable product)
 Distributed teams
 Modularity
 Scalability
Spring Boot Fundamentals
• What is Spring Boot:
“It’s a framework for building applications in the Java programming
language”
In otherwards It is collection of different tools.

While spring does simplify many tasks

• Creating web applications
• Working with databases
• Managing databases
• And more
• --- But required more configurations
Spring boot provides:
• Auto-configuration
• Not required any specific tools to execute the special programs
• Independent of external environment
• Standalone application
• We no longer need to explicitly create an application context
• It uses [Link]() to start the application, and Spring
boot takes care of configuring the embedded web server and other
necessary components.
• The “@SpringBootApplication” annotation alone brings lot of pre-
configured features including automatic component scanning and
embedded server configuration which would have required more
steps in a traditional Spring Setup
 Structure of Spring Boot Program
• Project Structure
• When you create a Spring Boot application, either through Spring Initializer or manually, you'll
generally see a structure like this:
Key Components

• src/main/java

 Base Package: Your main application class typically resides here. It usually follows a naming convention
based on your project name (e.g., [Link]).

 Controllers: Classes annotated with @RestController to handle HTTP requests (e.g., [Link]).

 Services: Classes annotated with @Service that contain the business logic (e.g., [Link]).

 Repositories: Interfaces annotated with @Repository for data access (e.g., [Link]).
• src/main/resources
 [Link] or [Link]: Configuration files for your application
settings.
 static/: Contains static files like CSS, JavaScript, and images that will be served directly.
 templates/: Holds server-side templates (if using a templating engine like Thymeleaf).
 public/: Similar to static/, but files in this directory can be accessed publicly.
• src/test/java
• Contains your test cases, typically following the same package structure as src/main/java.
It includes unit tests and integration tests for your application.
Build File

 [Link] (for Maven): Defines project dependencies, plugins, and configurations.

 [Link] (for Gradle): Similar to [Link], it specifies dependencies and tasks for building your project.
1. Build Configuration

• The build file defines how your project is built and packaged.

 Maven:
o Specifies build plugins and their configurations.
o Defines the packaging type (e.g., jar, war).
o Handles the build lifecycle phases (compile, test, package).

 Gradle:
o Uses a Groovy or Kotlin DSL to define tasks for compiling, testing, and
packaging.
o You can create custom tasks to suit your project needs.
2. Version Management

• Both build tools help manage the versions of your dependencies and plugins, ensuring compatibility and
stability.

• In Maven, you can define properties to centralize version management:

• In Gradle, you can use a similar approach with a version property:

3. Plugins

• Build files allow you to configure plugins that extend functionality.

 Maven Plugins: For example, the Spring Boot Maven Plugin can be used to create an executable JAR:

 Gradle Plugins: Similarly, you can apply the Spring Boot Gradle Plugin: