Microservices and API Management

1. Microservices and
API Management

2. Microservices

3. Agenda
1. Microservices
I. Need for Microservices
II. Definition
III. Function & Features
IV. Microservices vs SOA
V. Areas of caution
2. API management
I. API and how its used ?
II. API management function & features
III. Examples

4. Need for Microservices
 In Monolithic Architecture the large monolithic code base intimidates developers,
especially ones who are new to the team. The application can be difficult to
understand and modify. As a result, development typically slows down
 There are not hard module boundaries, modularity breaks down over time, to
implement a change or to deploy new versions of services frequently is difficult and
the quality of the code declines over time
 Overloaded IDE - the larger the code base the slower the IDE and the less productive
developers are
 Requires a long-term commitment to a technology stack
 Fault isolation was required. one misbehaving component of a monolithic architecture
can bring down the entire system

5. Definition
 Microservices is a software architecture style in which complex applications are
composed of small, independent processes communicating with each other using
language-agnostic APIs.
 These services are small, highly decoupled and focus on doing a small
task, facilitating a modular approach to system-building.
 These services are built around business capabilities and independently deployable
by fully automated deployment machinery.

6. Microservices
 Architect the application by functionally decomposing it into a set of collaborating
services. Each service implements a set of narrowly, related functions.
 Services communicate using either synchronous protocols such as HTTP/REST or
asynchronous protocols such as AMQP.
 Services are developed and deployed independently of one another.
 Each service has its own database in order to be decoupled from other services. When
necessary, consistency is between databases is maintained using either database
replication mechanisms or application-level events.

7. Microservices

8.  The services are easy to replace
 Services are organized around capabilities, e.g. user interface front-end,
recommendation, logistics, billing, etc.
 Services can be implemented using different programming languages, databases,
hardware and software environment, depending on what fits best
 Architectures are symmetrical rather than hierarchical (producer - consumer)
Microservices Features

9. Microservices vs SOA
 Microservices must be independently deployable, whereas SOA services are often
implemented in deployment monoliths.
 Classic SOA is more platform driven, so microservices offer more choices in all
dimensions
 Services in micro-service systems are smaller than most of those in SOA designs,
but most importantly micro services are stand-alone and are a manifestation of
the Single responsibility principle.
 A service in SOA may have many responsibilities and thus may be as hard to evolve
as any monolithic application.
 SOA initially started with XML/WSDL, but microservice architecture uses REST api.

10. Microservices vs SOA

11. Microservices vs SOA

12. Areas of Caution
 Developers must deal with the additional complexity of creating a distributed
system.
 Testing is more difficult
 Deployment complexity for different service types.
 Increased memory consumption.
 The tangled dependencies might make it difficult to decompose your
monolithic application into a set of services.

13. API Management

14. API
 Application programming interface (API) is a set of routines, protocols, and tools
for building software applications. An API expresses a software component in
terms of its operations, inputs, outputs, and underlying types.

15. API
 A good API makes it easier to develop a program by providing all the building
blocks. A programmer then puts the blocks together.
 APIs do all this by "exposing" some of a program's internal functions to the outside
world in a limited fashion.
 An API specification can take many forms, including an International Standard, such
as POSIX, vendor documentation, such as the Microsoft Windows API, or
the libraries of a programming language, e.g., the Standard Template
Library in C++ or the Java APIs.

16. How API is used?
 API in procedural languages: API specifies a set of functions or routines that
accomplish a specific task or are allowed to interact with a specific software
component
 API in object-oriented languages: is a description of how objects work in a given
object-oriented language expressed as a set of classes with an associated list of class
methods
 API libraries and frameworks: An API can also be related to a software framework a
framework can be based on several libraries implementing several APIs
 API and protocols: When an API implements a protocol it can be based on proxy
methods for remote invocations that underneath rely on the communication
protocol
 The role of the API can be exactly to hide the detail of the transport protocol

17. API Management
 API management is a system in which an enterprise publishes application
programming interfaces (APIs) in a secure environment. The enterprise maintains
the APIs in a registry and exposes them to consumers inside or outside the
enterprise.

18. API Management Functions
API management software tools typically provide the following functions:
 Automate and control connections between an API and the applications
that use it
 Ensure consistency between multiple API implementations and versions
 Monitor traffic from individual apps
 Provide memory management and caching mechanisms to improve
application performance
 Protect the API from misuse by wrapping it in security procedures and
policies

19. API Management Features
 Documentation – Sounds boring, right? Still, one of the most common problems of
developers is figuring out how an API works. An API management service has to provide
an easy way to read the documentation and enable developers to “try before they buy”.
 Analytics and Statistics – It is critical to understand how people use your API and get
insights for your business.
 Deployment – Should be flexible and support public or private clouds, on-premises
implementations, or combinations.
 Developer engagement – Engaging with your API consumers, developer or partners is
important. Getting an easily accessible developer portal will significantly facilitate
onboarding.

20. API Management Features
 Sandbox environment – This feature will increase both the value of an API and
its adoption rate. What better than being able to develop and test your code.
 Traffic management and caching abilities.
 Security – APIs carry sensitive data, so it is important to protect the exposed
information. The service has to at least provide identity and access
management for users and developers.
 Monetization – Provide the capability to monetize your API.
 Availability – Should be available, scalable and redundant. An API environment
can become demanding and the service should be able to deal with any kind of
errors, problems or temporary traffic spikes.
 Support of Legacy systems.

21. API Examples
 The developer of a game app, for instance, can use the Dropbox API to let users
store their saved games in the Dropbox cloud
 Sign In into many apps and Web sites using their Facebook ID—a feature that
relies upon Facebook APIs
 Companies can shut down services and APIs that your applications depend on—or
they can go out of business entirely like Google regularly shuts down when it
doesn't see any profit in them—like Google Health or more recently, Google
Reader.