 Enable Scalability

 Automate Environment – Amazon Cloudwatch automatically detects Server crash->Alerts

scaling to automatically launch and configure identical server ->automatically logs action to a
change management solution ->automatically notifies admin
 Use disposable resources
 Loosely couple components
 Design services not servers
 Choose right database solutions
 Avoid single points of failure
 Optimise for cost -eliminate unnecessary expenses
 Use caching
 Secure infrastructure everywhere -protect and monitor systems

Secure Infrastructure

1. Isolate parts of Infrastructure

2. Encrypt data in transit and at rest
3. Enforce access control granularity using principle of least priviledges
4. Use multi factor authentication
5. Leverage managed service
6. Log access to resources
7. Automate deployment keeping security consistent

Well Architected Design Principles

1. Stop guessing capacity needs

2. Test system at production scale
3. Lower risk of architectural change
4. Automate to make experimentation easier
5. Allow for evolutionary architectures
 An API is a contract between application and service
 
 Consumer Vs Providers
 
 A Software application is often consumer of API
 When an API is offered over a network for such consumption, the service that offers the API
is said to provider or API Provider
 
 The app may outsource requirements for data or functionality through API by calling that API
 Patient record
 Location represented as pin on map
 The execution of financial transaction
 
 It is  a technical contract
 Like a legal contract, it represents an understanding by all parties involved
 The contract also represents agreed upon standards (including de jure standards)
 
Example Contract
 
 120 v
 15 to 20 amp
 Alternating current
 Socket
 Tall = Neutral (White Wire)
 Short = Hot (Black Wire)
 ~Round = Ground (Green Wire)
 
Inter model Shipping Company
 
Example Contract
 
 L:40’ X H 8.6’ X W 8’
 Twist lock casting on all 8 corners
 Twist lock assembly
 Double sided
 Trailer mounted
 Rail Car mounted
 Ship-mounted
 
How API deliver flexibility ?
 
Say Mainframe is delivering API to all consumer…desktop, server app, web app, android app,
mobile app, server…..rebuild same application in linux server and then provide same API
conform to contracts…consumers wont know or care who is providing underlying service
 
How API can drive Organizational culture?
 
 
Amazon took this step in 2002
 
 All teams will henceforth expose their data and service through service interfaces
 Teams must communicate with each other through these interfaces
 There will be no other form of intercommunication allowed, no direct linking, no direct reads
of another team’s data store, no shared memory model, no backdoors whatsoever. The only
communication allowed via service interface calls over the network.
 It doesnot matter what technology they use
 All service interfaces must be designed from ground up to be externalizable. That is to say,
the team must plan and design to be able to expose the interfaces to developers in the outside
world. No exceptions
 
Microservice Architecture
 
 Build applications that scale with your success
 Patterns that allow software to be developed into relatively small, distinct components. Each
component is abstracted by API and provides a distinct subset of functionality of the entire
application
 
Take all the APIs out there…internal api catalog…some APIs may cost money and some
free…..the value that is shared by consumers by consumers and producers
 
How proliferation of APIs has created an anything to anything world that is often
viewed as API Economy
 
What are the different types of APIs?
 
 Web/Network
 Product
 Browser
 Standard (Example)
 System embedded
 
API Scopes
 
 Single purpose API
 Aggregate API
 Microservice API
 
Addressing IT Concerns
 
 Efficiency/Reusability
 Productivity
 Developers write 1 line of code vs 10000 lines of code
 Cost Savings
  Less wastage
 Agility
 Shortened turn around time on internal/partner/customer integrations
 
 Flexibility
 Language independence
 Scalability
 Performance
 
 Simplification
 Standardisation
 
 M&A
 
How can API’s drive business
 
 Agility & Cost Savings
 1st to Market
 
 Driving Innovation (Consumerization of IT)
 
 Driving additional revenue channels
 Partnerships
 Mobile Apps
 Integrations
 
 Driving customer loyalty & engagement
 360 customer view
 Reduced transactional friction

API Lifecycle

1. Planning and Analysis : Creating the vision

a. Understanding of undertaking
b. Capture internal API requirements
i. Developer community requirements (APIs, SDK, sample code)
ii. User stories (architectural styles within requirments)
c. Market/Competitor analysis
d. Planning for long term: infrequent versioning
e. Assess organization impact
f. Business/identity/price model considerations
i. Public vs private vs semi private, LSUD Vs SSKD
ii. Service Tiers (integrate, orchestrate)
iii. SLAs
g. Security requirements
2. Design

a. Codify Requirements
b. Define developer experience
c. Design API
i. Lean API first if applicable
d. Validate & Collect Feedback
i. Tooling for testing /collaboration
e. Documentation drafts

3. Development

a. Taking the output of design phase and making it real

i. Integration
ii. System architecture i.e. on-prem vs cloud
iii. Vendor implementation
iv. Procedure creation for API operation and maintenance
b. Building
c. Enforcement points
d. Keep measurement top of mind
e. Testing procedures/Technologies

4. API Operation
a. Stack Security
b. Orchestration and microservices
c. Scaling
i. Tier and SLA monitoring
ii. DevOps
d. User Management
i. Managing client Ids
e. Billing and commerce considerations

5. Governance
a. Policy Application
b. Policy Layering
c. Managing API Access
d. Enforcement Points
i. API Key
ii. Rate Limiting /throttling
iii. User-level security
iv. App Security
v. Access Control

6. Measurement and Testing

 a. API Analytics
i. KPI Context and business objectives
b. Scaling Up
i. Thresholds of dynamic scaling
ii. Thresholds for rip/replace
c. Transperency
d. Ongoing Testing
i. Performance
ii. Regression

7. Engagement and Developer Experience

a. Dev Marketing
i. LSUD VS SSKD, Internal vs Extrernal
ii. Gamification
iii. Hackathons
iv. Intellectual property
b. Onboarding
i. Credential acquisition
ii. Tier Assessment
c. Dashboard
i. Performance
ii. Availability
d. Beta Access
e. SDKs
f. Documentation
i. Code samples
ii. Tutorials
iii. App Showcase
iv. Interactive console
v. Mock APIs
vi. Discoverability
vii. Changelog
viii. Security primer
ix. Great status, codes, support and documentation
g. Evangelism & Constant dialogue
i. RSS
ii. Blogs
iii. Forums
iv. Emails
v. Social Media

8. Versioning & Retirement

a. Beta
b. Production
 c. Migration
d. Support
e. Backward compatibility
f. Deprecation
g. Shut-down

What does it mean to Secure API?

Client Security Vs Backend Security Vs Network Security

 Client Security risks

I. App Code exposure
II. Shared Password
 Backend Security risks
I. Database exposure, SQL injection
II. Rate Limiting (no of times and how fast API consumer can come and hit your API)
III. Improperly secured endpoints (URLs are not properly secured)
IV. Phishing/Social networking attacks
V. Clear test data at rest (OAuth token stored )

 Network Security risks

I. Credential theft

Keeping end users credentials secure

 Early days = basic authentication

I. Username and password
 Security Risk : Gives application devs (an potentially hackers )access to private account info
 Open Authentication (OAuth) introduced as token based authentication
I. Prevents API clients from accessing user credentials
II. Tokens can expire

Why API First design so important ?

APIs are business drivers

 Go mobile
 Discover new revenue streams and model
 Innovate
  Digital Transformation

APIs led connectivity

 Reusable /composite enterprise

 Modern API

Developer first Design

 Prioritize developers experience with API

 Don’t reinvent the wheel
 Go for the greenfield: Ignore the legacy

Microservices

 Bill Payments
 Transaction History
 Fund Transfer
 Intra Bank Transfers
 Transfer Money between customers own wallet (POST)
 Transfer Money to a Paylah Wallet (POST)
 Transfer Money to external wallet( POST)
 Retrieve status of fund transfer (GET)
 Inter Bank Transfers
 Transfer money to pre registered payee account (POST)
 Adhoc transfer (POST)
 Retrieve status of fund transfer (GET)
 Scheduled Transfers
 Retrieve List of scheduled transfer (GET)
 Cancel a schedule transfer request (POST)
 Limits
 Payees
 Real time payments
 Transaction Analytics
 Rewards
 Retrieve List of Reward Accounts (GET)
 Retrieve Reward Point Balance (GET)
 Retrieve Rewards points Transaction history (GET)
  Redeem Rewards as vouchers (POST)
 Redeem Rewards as miles (POST)

 LOANS
 Mortgage Loan Application
 Retrieve List of Mortgage Loan Application (GET)
 Retrieve Mortgage Application Details (GET)
 Retrieve List of Mortgage Loan Applicants (GET)
 Search for Mortgage Applications (GET)
 Initiate New Mortgage Loan Application (POST)
 Cancel Mortgage Loan Application (POST)
 Declare Applicants Credit Facilities (POST)
 Update Mortgage Loan Application Details (POST)

 Mortgage Pricing Packages

 (GET) Retrieve List of Mortgage pricing packages
 Mortgage Calculator
 Calculate Loan Amount and Tenor for Home Loan (POST)
 Calculate Loan Amount and Tenor for HDB Flat (POST)
 Calculate Loan Amount and Tenor for Private Property (POST)

Response Status Codes

1XX : Informational

2xx: Success : Client request are accepted

o :200 :OK
o :201 : Created
o :202 : Accepted
o :204: No Content

3xx: Redirectional . Clients requests are redirected to different server to the different endpoints to
fulfil client request.

4xx: Client Error: Errors at client side

o :400: Bad request

o : 401 : unauthosirsed
o :403: Forbidden
o :404: Not Found
 o :405 : Method not allowed
o :406: Not acceptable
o :409:Conflict
o :412: Precondition failed
o :415:Unsupported Media Type

5xx:: Server Error

o 500: Internal Server Error

Throttling limit is considered as cumulative at API level. Administrators and publishers of

API manager can use throttling to limit the number of API requests per day/week/month.
For example, you can limit the number of total API requests as 10000/day.

Microservices are independently deployable, horizontally scalable, composable, interoperable,

public discoverable, network accessible, technology agnostic, modular, fine grained, containerised
What Spring boot is not!

Zero Code generation

Spring boot neither App Server nor Web Server

Spring boot is not code generation product

Features

Quick Starter Projects with Auto Configuration

-Web

-JPA

-Embedded servers – Tomcat, Jetty or Undertow

Production -ready features

-metrics and health checks

-externalized configuration

In earlier days, For deploying a web application say in a Linux box, the way it used to work is forst I
would need to install the Linux box, then install java on it and then I would need to install a web
server , So I would need to install either tomcat, weblogic or websphere and then I would take my
application WAR and deploy it. This is the usual way we used to deploy stuff.

With Sping boot comes a concept called embedded server, what we do now is we package our
server, so we can package tomcat along with our application JAR, So I can include Tomcat server in
my application JAR. So I don’t need to install it on the Linux box.

So all that I need to do, on the Linux box is if I have java installed that’s sufficient. I can go ahead and
run my application. I don’t need any other server installed on the Linux box.

In the world of Micro Services this makes a huge difference. And also, Spring boot provides a number
of production ready features. Spring boot provides monitoring for your application through
something called Spring Boot Actuator.

For example, we can find out how many times a particular service is called. We can find out how
many times a particular service failed and also can check whether the application is up and running
or not.

All these features comes built in. And another important feature that Spring Boot provide is
externalised configuration. The configuration of applications varies between different environments.
Our configuration from dev different from our config in production. Spring boot provides these
features built in. You can simply create property files matching a simple naming convention and
that’s it and you are ready with externalised configuration. Spring boot also provides support for
different profiles.

These are some of the important goals and features of Spring boot.

The idea behind this step is to understand the big picture of Sping boot. What is it? And What it is
not and what are the important features

Earlier,

We needed to decide, what frameworks and versions to use. I would want to use Sprint MVC and
Spring Security web, Spring Security Config. I would want to use Jackson databind because I want to
do some binding and validation.

I would want to use JSTL and I would want to use Hibernate validator and also for logging I would
use want to add in log4j. We had to decide what dependencies to add in to our projects. Not only
that we needed to decide the versions of them as well.

Sometimes this 5.0.2 final version might not be compatible with some other version of Spring MVC.
So we needed to decide what are the comparable versions and start using them. Choosing the
frameworks to use and which version to use is a major decision that we needed to make when we
were not using Spring Boot.

We needed to implement default exception handling and we needed to create a complete spring
configuration file.

We needed to define the component scan and then we would need to configure a view resolver to
redirect the views to a JSP. To implement internationalization, we needed to implement a message
source and also a locale resolver and in addition to that we needed to configure our web.xml as well.

We needed to configure the dispatcher servlet in web.xml so that it can handle all the requests and
act as a front controller, we needed to configure the Context configuration location in here and we
also needed to configure the Spring Security. We needed to configure the filter for it and make sure
it intercepts all the requests.

There is a lot of work that we would need to fo to get a simple web application up and running. We
configured dependencies, dependency version, Spring Configuration for internationalization, logging
and a lot of other stuff. All these stuff which we looked at in this specific step is the kind of stuff
which we don’t need to do with Spring Boot. Spring Boot would automatically provide all that stuff
for you, so that you can really concentrate on developing your business logic.

All the infrastructure would come free for me.

All these stuff we saw in this specific ex would be replaced by a simple starter project called Sprint
Boot startup Web in combination with Sprint Boot Starter Security. Just the combination of these
two starters would eliminate the need for a lot of configuration that we looked at these specific
steps earlier.
For creating Spring boot project go to Start.spring.io

For creating a simple restcontroller with a URI like \books and I would want to return a few hard
coded books…Since Tomcat runs on port 8080 by default…URI would be something like
http://localhost: 8080/books

Create a simple bean with new class “Book”

RestController…create class rest controller …map URI to it

Understanding AutoConfiguration

We have the spring boot application where we have the @SpringBootApplication annotation. The
annotation at SpringBootApplication indicates that this is a Spring context file. That No 1.

No 2, it enables something called autoconfiguration.

No 3, it enables something called component scan

Component Scan is one of the important features of Spring where it would start automatically
scanning these classes in this package (com.in28minutes.springboot.basics.springbootin10steps) and
in this subpackage for any beans. So we have added in an annotation @RestController. This is one of
the annotations which is scanned for. So this would be registered as a component. So the
bookcontroller would be registered as a bean and it would be managed by the Sping Framework.

There are three things that are essentially done by @SpingBootApplication as explained earlier.

Now if we want to look at auto configuration in depth, SpingApplication.run method is used to run is
used to run a Spring Context. So we are giving Spring context as an input to it and it would be able
to run that. The run method also returns a application context and we can have it run through loop
of beans avl.

Springboot looks at

a. Frameworks available at classpath

b. Existing configuration for the applications

Based on these, Spring boot provides Springboot provides basic configuration needed to configure
the application with these frameworks. This is called AutoConfiguration

SPRING BOOT Vs SPRING MVC VS SPRING

They have different roles…they arenot competing for same space

They Solve really different problems and they solve them really well.

Whats the core problem that Spring Framework solves?

The core problem Spring framework solves is testability, if you don’t define proper dependencies
then your applications are not testable. The most important feature is dependency injection. The
Core of Spring Framework is the IOC – Inversion of control

Spring framework takes control of all the beans and their dependencies. That’s basically what the
Spring framework cares about. Spring framework is all about defining beans, putting your
@component, putting your @service and things like that and also defining your dependencies
@autowired and things like that and also defining how to find your beans.

Component scan for example. That’s basically the core problem that Spring framework solves the
problem of dependency injection.

It helps you to build loosely coupled applications. Loosely coupled applications can be easily unit
tested.

Other than that Spring framework also solves problems like plumbing code….say if you needed to
use jdbc….u need to write boiler plate code and exception handling..which is not required in spring
framework

Spring MVC is concerned with developing web applications. Spring MVC provides a simple way of
developing web applications. One of the great thing about spring MVC is the separation of concerns.
Dispatcher Servlet is concerned with just the basic front controller part. There is a model and view.
There is a view resolver which is concerned just with resolving a view name to the physical view.
With these kind of simple concepts, Spring MVC makes it very easy to develop your web applications
as well as your restful services.

Whether you are developing web applications or REST services with Spring Boot you are using Spring
MVC framework. That’s the spring web MVC framework.

Why do we need Spring Boot?

Can we bring more intelligence into this? When a spring mvc jar is added into an application, can we
auto configure some beans automatically?

How about auto configuring a data source if hibernate jar is on the classpath?

How about auto configuring a dispatcher servlet if spring MVC jar is on the classpath?

Spring Boot looks at

a) Frameworks available on the classpath

b) Existing configuration for the application
 Based on these, Spring Boot provides a basic configuration needed to configure the
application with these frameworks. This is called auto-configuration.
The Strarter projects are all built around well known patterns.
Other than starters the important goals of Spring Boot is to provide a few monitoring
features.

 Sping-boot-starter-actuator- To use advanced features like monitoring & tracing to

your application out of the box
 Spring-boot-starter-undertow, spring-boot-starter-jetty, sring-boot-starter-tomcat –
To pick your specific choice of embedded servlet container
 Spring-boot-starter-logging – For Logging using logback
 Spring-boot-starter-log4j2-logging using Log4j2

Spring Boot aims to enable production ready applications in quick time

 Actuator: Enables advanced monitoring and tracing of applications

 Embedded Server Integrations – Since Server is integrated into the application, I wouldnot
need to have a separate application server installed on the server
 Default Error handling

Sping-boot-starter-web is the preferred starter for Spring Boot to develop web applications as well
as Restful web services.

It contains dependency on Spring-boot-starter-tomcat - that’s how application is automatically

running in Tomcat

The other things which we would see are

Spring- web and Spring-webmvc

When I add in spring-boot-starter-web I automatically get spring mvc, I automatically get validation.
Validation the default implementation for Java validation API is hibernate validator. So I get that as
well and I get Tomcat and also I get starter-json. Starter JSON is more for RESTFUL webservices.

We saw that when we actually invoke the RESTFUL web service the conversion to JSON
automatically happen.

If we look at the code, we just returned bean back. So in the bookscontroller, what we are doing is
we are just returning a list of beans back. Hoe does it automatically convert to JSON? That’s done
through the starter. The starter JSON brings in JSON binding into the picture.

Basically when you look at all starter projects, they have a set of dependencies that are already
defined. And these dependencies are automatically provided to our project.

So when I add in Sping-boot-starter-web, I get all these dependencies. So you’d see that I am getting
Jackson for handling all the JSON stuff, you’s see that I am getting Tomcat so that I can run the
application in Tomcat. I’m getting hibernate validator and validation API for doing the validation. I
am getting this spring framework because I have a dependency on Spring Web and that could have
dependency on Spring framework.

And also I would get logging frameworks as well because the logging frameworks are by default
defined in the spring boot starter. So Spring-boot-starter is one of the dependencies in Spring Boot
Starter Web.

So if you open pom.xml for it, you will find that this the default starter and this is where everything
inherits from. So any starter that you would use in spring boot, it inherits from Spring-Boot-Starter
and you would see that these are the dependency and Spring Boot framework. This has a
dependency on Spring Boot auto configure. That’s how we get autoconfiguration…dependency on
logging…spring core….YML is one of the configuration languages that Spring Boot supports…so we
have snake YML in here…..

Spring-boot-starter-test enables you to write unit test and integration tests as well….In pm.xml..it
has a denation on the auto configured for Spring Boot test and it ahs dependencies on Junit
framework, Assert J…Also Mockito…Mockito is the default mocking framework that comes along
with Spring Boot.

A combination of Assert J and Hamcrest are awesome to write great matchers..

And also have a dependency on the spring-test-framework which is useful in writing unit tests for
spring

Another important starter which is frequently used is spring- boot-starter-data- JPA. JPA is kind of
interface for hibernate. So JPA defines how ORM applications or ORM frameworks should work.
ORM is object relational mapping. Lets now add ina dependency on Spring Boot Starter JPA.

You would now see that there would be a lot more Maven dependence which would come in.

JPA – Java Persistence API

Before JPA

JDBC

 Jdbc stands for java database connectivity

 It used concepts like statement, PreparedStatement and ResultSet
 Ex the query used is Update todo set user=?. Desc =?, target_date=?, is_done=? Where id=?
 The values needed to execute the query are set into the query using different set methods
on the prepared statement
  Results from the query are populated into the ResultSet. We had to write code to liquidate
the Resultset into objects.

Spring JDBC

 Spring jdbc provides a layer on top of jdbc

 It used concepts like jdbc template
 Typically needs lesser number of lines compared to JDBC as following are simplified
o Mapping parameters to queries
o Liquidating resultsets to beans

myBatis

MyBatis removes the need for manually writing code to set parameters and retrieve results. It
provides simple XML or Annotion based configuration to map Java POJOs to database

How JPA resolves Object relational

JPA provides mapping…map application classes to tables using annotions

JPA vs Hibernate

Hibernate is one of the most popular ORM frameworks

JPA defines the specifications. It is an API

 How do you define entities

 How do you map attributes?

 How do you map relationships?

 Who manages the entities

Hibernate is one of the popular implementations of JPA

 Hibernate understands the mappings that we add between objects and tables. It ensures
that data is stored/retrieved from the database based on the mappings.
 Hibernate also provides additional features on top of JPA. But depending on them would
mean a lock into Hibernate. You cannot move to other JPA implementations like Toplink.
Web Service – W3C Definition

Software system designed to support interoperable machine-to-machine interaction over a network.

3 Keys

 Designed for machine-to-machine (or application -to-application) interaction

 Should be interoperable – Not platform dependant
 Should allow communication over a network

XML, JSON
Different Groups/Types of Webservices

SOAP

REST

SOAP and REST not really comparable

Simple Object Access Protocol (specific way of building web-services), XML as format for sending
request/response.
SOAP defines a specific XML request and response structure

SOAP

 Format
o SOAP XML Request
o SOAP XML Response
 Transport
o SOAP over MQ
o SOAP over HTTP
 Service Definition
o WSDL
CHALLENGES

1. Bounded Context : Identify boundaries of each of the microservices.

For new applications it is much more difficult. We might not have right- business knowledge
to define the bounded context

It is a evolutionary process, it is not something which we will get right the first time… try and
follow domain driven design…try to identify the right boundaries for the microservices based
on the knowledge we have at that point in time.
The important thing to understand is that as we gain knowledge we should put that
knowledge back into the microservices into deiciding what is the right boundaries for these
microservices.

2. CONFIGURATION MANAGAMENT: Say we have 5 or 50 microservices and these

microservices have multiple instances in each environment and there are multiple
environment. Say there are 10 microservices with 5 environments and lets say 50 instances.
So we are talking of tons of configurations.

3. DYNAMIC SCALE UP AND SCALE DOWN: Establishing the technology to do that. The loads on
different microservices will be different at different instances of time and at particular
instance I might need two instance of microservice and later point in time I might need 10
instance of the microservice. So I should be able to bring the new instances of microservices
up and bring down older instances of microservices when they are not really needed. All this
with dynamic load balancing because when there is one instance of microservice 1 there are
4 instances of microservice 2 then I would want to distribute the load between all the
 instances of microservice and if there are 4 instances of microservices 2 coming up, then I
would want to ensure that all the new ones are also being used to the fullest.

So we need the ability to dynamically bring in new instances and also to distribute the load
among the new instances.

4. VISIBILTIY: If I now say functionality is distributes among 10 microservices, and there is a

bug how do I identify where the bug is. We need to have a centralised log where I can go
and findout what happened for a specific request and which microservice caused the
problem not just that we also need monitoring around the microservices because we have
100s of microservices we need to be able to identify the microservices which are down. We
need to automatically identify microservices which are down, automatically identify servers
where there is not enough disk space. All this kind of things need to be automated. So we
need great visibility to what happening to this microservices

5. PACK OF CARDS: If microservices are not well designed microservice architecture can be
like pack of cards what do I mean basically that in microservices architecture we have one
microservice calling another, another calling another..there will be certain microservice
which will be fundamental for the whole thing and if that microservice goes down then the
entire application might go down. So it is like pack of card. Therefore it is very important to
have fault tolerance in our microservice

ADVANTAGES OF MICROSERVICE ARCHITECTURE

1. Adapt new technology processes very easily. When we build application as a combination of
microservice which can communicate