An Introduction to Micro services

Micro services are small, self-contained services that can

evolve independently and deploy separately to support
continuous integration and continuous delivery.
A micro service architecture promotes developing and
deploying an application or a set of features composed
of independent, autonomous, modular, self-contained
units.
Each unit is assigned to a team that owns it for improving
it. Adoption of micro services, teams can rapidly ship
newer versions of applications or features without
disrupting rest of the solution..
MONOLITHIC VS MICROSERVICES
 Why Micro services?
• Enables Agile Processes: Moving away from a waterfall-based mindset that views software projects as large, multi-
year capital expenditures. Micro services helps enterprises to fully adopt agile development and deployment methods
with a strong technology platform that facilitates cloud-native approaches and micro services architecture setup.
• Leverages Best-fit Technology for Each Component: Developers are choosing best-of-breed languages, frameworks,
and tools to write parts of applications. One large application might be composed of micro services written in Node.js,
Ruby on Rails, Python, R, and Java. Each micro service can be written in a language that is best suited for the task.
Teams that develop microservices can make technology decisions that are right for the job. They can experiment with
modern technologies, libraries, languages, and frameworks, yielding faster innovation cycles.
• Modularity and Code Re-usability: Organizations today invest in reusable building blocks that are composable. Each
microservice acts like a Lego block that can be plugged into an application stack. By investing in a set of core
microservices, organizations can assemble them to build applications catering to a variety of use cases.
• Elastic Infrastructure: With multiple cloud infrastructure providers is available in the market, enterprises today can
dynamically provision, configure and orchestrate a few hundred virtual servers. But, instead of launching multiple
instances of the application server, it is possible to scale-out a specific microservice on-demand. Microservices
simplifies load balancing because when the load shifts to other parts of the application, an earlier microservice will be
scaled-in while scaling-out a different microservice.
• Ease of CICD (Continuous Integration and Continuous Delivery): Microservices helps small, autonomous, co-located
teams with test driven development, continuous integration and continuous delivery that make the successful launch
of each feature or application.
• Decentralized Data and Governance: While microservices encourages its developers to save time by always using re-
usable code libraries established by others, while also giving them the freedom to flirt with alternative solutions when
needed.  In addition, a solution with traditional architectures uses a single logical database across different
applications.  In a microservice, each service built for specific application or feature usually manages its unique
database.
 Microservices Business Benefits
• Reduces Time to Market: As each microservice is built and aligned around a
business function to reduce the complexity of the application change-
management process. It expedites updating new technologies, libraries,
languages, and frameworks, yielding faster development cycles, including rollback.
Each service is individually changed, tested, and deployed without affecting other
services, enabling faster time to market.
• Superior Application Quality: By using “divide-and-conquer” approach of
microservices architecture, teams can perform both functional and performance
testing of each unit easier than before as components can be tested in isolation
and combined with a full or virtualized set of microservices. It also minimizes test
automation and quality-assurance overhead and facilitate concurrent, A/B release
testing on subsystems. Thus, microservices approach results in overall
improvement in application quality.
• Zero-Downtime Deployment: Microservices enables versions and releases
planning process and backward compatibility requirements with master and
multiple slave containers. It allows you to deploy the latest version of your
microservice without interrupting the operation of the other micro-services.
IMPLEMENTING SERVERLESS MICROSERVICES ARCHITECTURE ON AWS

SERVERLESS MICROSERVICES ARCHITECTURE

• Microservice is an architectural approach for
softwares that are designed to speed up
development cycles and support scalability. In
this approach, software is composed of small
independent services that communicates over
well-architected APIs.
 MONOLITHIC VS MICROSERVICES ARCHITECTURE

In monolithic architecture, all the components are tightly coupled and run as a single service. Here, the
entire architecture has to be scaled if any one component of the application experiences a spike in
demand. This architecture type increases the difficulty level to implement new ideas in the application.
In Microservices architecture, each component is a small application that has its own hexagonal
architecture. It is an architectural style that structures an application as a collection of services that are
loosely coupled and independently deployable.
 FEATURES OF MICROSERVICES ARCHITECTURE

Independent
• In Microservices architecture, each component can be changed, upgraded or replaced
individually without affecting the functionality of other components.

Decentralized
• Microservices architecture follows the decentralized data management, where each
service has its own view on data models.

Autonomous
• In Microservices architecture, there is no need to share any of the component code or
implementation with other components. Any communication between components can
be done via well-defined APIs.

Black Box
• Microservices architecture behaves like a black box because each component hide the
details of complexity from other components.
 ADVANTAGES OF MICROSERVICES ARCHITECTURE

Quality
• Microservices architecture can also improve the quality of code as the whole application
is running into small and well-defined components

Scalability
• In Microservices architecture, each component is properly decoupled so it can be scaled
horizontally and independently from each other and it never faces the downtime during
the Scaling process because in horizontal scaling more components are added to the
existing pool instead of increasing the capacity of each component

Easy Development
• Microservices architecture makes it easy to try out new ideas and roll it back with the help
of continuous integration and continuous delivery, if something undesired happens.
Resilience
• With Microservices architecture, applications can handle total service failure by degrading
the functionality instead of crashing the entire application.
 CHALLENGES OF MICROSERVICES ARCHITECTURE

Migration
• The Process of migration from a Monolithic architecture to
Microservices architecture is complex and requires to release
code dependencies going down to the database layer.
Testing
• In a Microservices environment, testing is complex due to
different services and their integrations.
Monitoring
• In Microservices architecture application is broken down into
small components. It is difficult to find the root cause of the
problem when something goes wrong because issue may not lie
within the component that fails, but a dependency.
SERVERLESS MICROSERVICES ARCHITECTURE
 SERVERLESS MICROSERVICES
ARCHITECTURE
• The diagram shows the Serverless Microservices architecture where the complete solution is built
without managing any server. This also eliminates the operational efforts of running and monitoring the
servers.

• Lambda will handle everything required to run and scale the execution to meet actual demand with high
availability. Lambda supports several programming languages and it can be called directly from any web
or mobile applications.

• In the architecture diagram, Lambda is integrated with API Gateway. Synchronous calls from API gateway
to AWS Lambda enables the application to operate as serverless. AWS Lambda will store all the data in a
fully managed NoSQL database called DynamoDB and all the static data will be stored in S3 Bucket.

• It can be said that Microservices architecture is designed to overcome the challenges of traditional
monolithic architectures seen in enterprise applications. It allows collaboration between operations and
development teams of any organization leading to devops and is a preferred choice nowadays.

• AWS offers multiple managed services that can help engineers build Microservices architectures and
minimize architectural and operational complexity.
How to start with designing Micro services-based
Solution Architecture
• Microservices-based solution architecture is not always the best fit for all use-cases, and using
a one size fits all approach has several drawbacks. Before designing a microservices-based
solution architecture, enterprise solution architects must address the following questions.
• Is Microservices architecture a good fit for the solution?
• How should one define the Microservices Architecture?
 1. Decomposition of the application into services
Microservices architecture is a set of loosely coupled services and decomposition of the
application into services plays a key role in microservices architecture implementation,
deployment, and CI/CD.

Solution architects can define the decomposition methods based on need & solution, there are
no “best” methods for decomposition but there are common methods, which can help you to
decompose your solution in several services as mentioned below. To apply decomposition, you
need to understand the need & role of each component, weight/links between several
components and more factors for each component of the entire solution.
Decomposition Strategies:
Decompose by module/business capability: This method suggests defining each component for
each module or feature i.e. messaging, logging, device communication, user management. This
helps you to assign an entire feature/module to separate teams, where respective teams will be
responsible for a module/feature
Decompose by domain: This method suggests defining the region where your solution is going
to be deployed, and further defining the services to that region. Define services corresponding
to Domain-Driven Design (DDD) subdomains. DDD refers to the application’s problem space –
the business – as the domain. A domain consists of multiple subdomains. Each subdomain
corresponds to a different part of the business. E.g. User Management, Device Management,
Device Communication
 2. Microservices Discovery and Registration

• Microservice architecture uses the service registry to maintain

a location of service to send requests, and this registry can be
managed on the server side or client side. The Service can
register itself or via a third party (deployment scripts) can
register the service.
• Each service should register itself on the registry on service
bootup with a health check interface. Health check interfaces
help the registry check for service availability. While defining
the service registry you must implement a mechanism that
enables the clients of the service to make requests to a
dynamically changing set of ephemeral service instances.
 3. Micro services Communication
• For this, the architecture must allow each service to communicate with
each other. Here are multiple ways to define inter-service communication:
• Remote Process Invocation: Remote Procedure Invocation applies the
principle of encapsulation to integrating services. If an application needs to
modify the data of another, then it does so by making a call to another
Each service can maintain the integrity of the data it owns. Furthermore,
each service can alter its internal data without having every other
application be affected. You can use grpc, Apache Thrift and REST for such
communication
• Messaging: Use asynchronous messaging within inter-service
communication using tools such as Kafka, RabbitMq etc. This will work
when each request is independent and does not require any callback
• Domain Specific call: Use domain specific protocol for inter-service calls
e.g. SMTP or IMAP for email, RTSP, RTMP, HLS or HTTP for media streaming
 4. Micro services Observation
• Observation is another key point for microservices frameworks. This allows you to debug &
monitor each service. There are several aspects which need to be addressed while
designing microservices.
• Log Aggregation: Use centralized logs from each service instance. User/Reviewer can
search & analyze the logs. They can configure alerts on several critical errors and check the
number of errors by categories. This can be achieved by integrating logstash as the central
log server
• Health Checks: Health check interfaces help the user/reviewer to check whether a service
is available or not. This can be achieved by creating a REST interface with a static response
and integrating a load balancer which periodically checks the health of API and updates the
status of service
• Application Metrics: It provides service status metrics including information for example –
How many calls per API? Where are the maximum requests originating from? This service
runs in the background and interacts with each operation of the server, so the service you
choose should take minimal runtime overhead. e.g. Appmetrics for the node, Coda Hale for
JAVA
• Log Deployments & Changes: It is useful to see when deployments and other changes
occur since issues usually occur immediately after a change. E.g. Enable notifications for
deployment status, enable notifications on application crashes
 5. Micro services Database Management
• Most services need to have persistent data in a database. For example, the Device Service stores
information about devices and the User Service stores information about users.

Database Management Strategies:

There are multiple ways to manage databases in microservice frameworks.
1. Database per service: Keep each microservice’s persistent data private to that service, and accessible only via its
API
2. Shared database for the solution: Use a (single) database that is shared by multiple services. Each service freely
accesses data owned by other services using local ACID transactions
3. Hybrid database: Create a common shared database and service-specific database separately for e.g. In a typical
IoT Cloud Platform-as-a-Service, architects may choose to store request timeout, in the specific database which
will be accessible only through specific service exposed for that module

Things to consider while managing databases:

4. Some business transactions must enforce invariants that span multiple services
5. Some business transactions need to query data that is owned by multiple services. For example, to retrieve user
devices, it will request details from user service and device service
6. Some queries must join data that is owned by multiple services
7. Databases must sometimes be replicated and shared in order to scale
8. Different services have different data storage requirements. e.g. Log service will use LogStash, user service &
device management will use MongoDB
6. Microservices External Interface (API Gateway)
An external interface is the gate from where
users/applications interact with microservices.
Implement API Gateway to enable a single entry point
for all service requests from clients.
API gateway will authenticate requests and proxy/route to
actual services. API gateway implements security
(include Access Token in header or query parameter) for
secured endpoints.
Enterprise architects should design API gateways to take
care of security, applications data protection and the
number of request limit (per user, per IP or per
application) to prevent DDoS attacks.
 7. Microservices Testing
• When trying to test an application that communicates with other services, one could
do one of two things:
• Deploy all microservices and perform end to end tests: Simulate production in your
test environment and run end-to-end tests before deployment. This method will test
real use cases and ensure service quality. The disadvantage of such tests is that they
are time consuming and debugging is extremely difficult
• Mock other microservices in unit/integration tests: Mock the external services and
run unit and integration tests. This approach is very fast but it cannot guarantee that
production is safe
• Common advice for testing microservices is to use combined integration tests & unit
tests. Run some of the tests as unit tests, and some of them as integration tests which
can ensure the required quality within the solution.
• While planning the test you must include service component tests & service
integration contract tests as part of the testing process. You can use several Testing
Tools/frameworks in development, such as Junit, Spring Cloud Contract for Java &
Mocha, Chai, Sinon, Proxyquire etc, for Nodejs. You can generate HTML reports by
checkstyle to validate the test report & code coverage.
• Ideally, 80% code coverage is recommended for any source code.
 8. Micro services; Continuous Integration &
Deployment
• Each service is deployed as a set of service instances for throughput & availability.

CICD Strategies:
• Multiple services per instance: Run multiple services on the same host (physical or virtual). E.g.
deploy all NodeJS services on an EC2 instance as separate services. This will work when you are in
development or you have a small number of users accessing your application. As users grow, this
method leads to problems like resource conflicts, Memory & CPU utilization issues, and insufficient
monitoring of service behavior
• Service instance per host: Deploy a single service on each host. This overcomes issues of multiple
services per instance with an effective way to balance the load, such as when the load is high for a
particular service. In such cases, you can scale your deployment to multiple instances for a single
service. This pattern also has one drawback; consider you have one service which does not have
frequent usage i.e dispute of orders, still, this will be deployed on one instance and you can’t utilize
CPU & memory resources from here for another service
• Serverless deployment: Use deployment services which remove server and infrastructure
management. It allows you to zip your package, deploy it on application services and charge you on a
request basis. In this method, you need not worry about resource management and load
management. Design your service to run without the server using public resources like S3 or Azure
storage for file storage, Dynamodb or Azure database as a database, SNS or Event Grid for
communicating between two services, SES as email service. Popular framework components include
AWS lambda, Google Cloud function, Azure functions
 9. Microservices Deployment platform
• You can also use a deployment platform to automate the deployment of your
microservices for both serverless & server based models.
• If you have a huge system with multiple integrated services which self-manages
server instances & services, is generally a cost-effective solution. You can use AWS
cloud formation & task definitions with Docker swarm mode & Kubernetes to
automating deployment, scaling & manage all applications centrally. AWS cloud
formation allows you to use a single file to model & provision infrastructure, and
task definition allows you to define several Docker images for your environment.
Once the environment is up, task definition takes care of all services i.e if your
service crashes it would launch anew Docker instance automatically.
• If your solution is small but requires a service, then you can deploy your services
to PaaS platforms like AWS Elastic Beanstalk which allows you to deploy and scale
web applications and services developed with Java, .NET, PHP, Node.js, Python,
Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and
IIS. It charges based on the resources you use.
• To deploy your serverless code you can use several tools like claudia.js which
allows you to automate AWS lambda and api-gateway deployments
 Example Implementation:
• Let’s Imagine we are building an IoT solution using a microservice
architecture which includes device connectivity, user management,
alerts & rules engines. In addition to this, the solution must expose
REST API details to third-party applications like Android and iOS.
• As our solution uses microservices architecture, it divides the
solution across multiple services like:
1. API Gateway (e.g. express gateway which provides the secure gateway
(using API key) including several features like rate limit, routes the
request to microservices)
2. Express for API microservices
3. Seneca microservice tool for inter-service communication
4. MongoDB cluster as a database.
5. Redis for service registry & event store
6. Docker, Jenkins & cloud formation for deployment
IoT solution using a micro service architecture