The document provides an overview of microservices architecture and how to build microservices on Azure. It begins with defining microservices and comparing them to monolithic applications. Key characteristics of microservices like independent deployability and small, focused teams are discussed. The document covers design considerations like service boundaries, data management, communication between services, API design, and logging/monitoring. Hosting options on Azure like Service Fabric and serverless Functions are presented. It concludes with noting references for further reading on microservices patterns and practices.

1. BUILDING
MICROSERVICES ON
AZURE
~ Vaibhav Gujral
@vabgujral

2. About Me ■ Over 11 years of experience
■ Working with Assurant Inc.
■ Microsoft Certified Azure Architect
■ MCSD, MCP, Microsoft Specialist
■ Aspiring Blogger & Community Champion
■ Interests– Value Investing, Photography &
Astronomy
■ Husband of One & Father of two
■ Blog – http://vaibhavgujral.wordpress.com
■ Twitter - @vabgujral
■ Skype – vaibhav.gujral
■ Email – gujral.vaibhav@hotmail.com

3. Agenda ■ What are Microservices?
■ Monolithic Vs Microservices
■ Characteristics & Benefits of Microservices
■ Design Considerations
■ Data Considerations
■ Inter-service communication
■ API Design & API Gateways
■ Logging and Monitoring
■ CI/CD pipeline for Microservices
■ Hosted Models for Microservices
■ Demo

4. WHAT ARE
MICROSERVICES

5. Monolithic Applications
(ref- https://www.martinfowler.com/articles/microservices.html)
■ Monolithic Application
– Built as a single unit
– Generally deployed as a single logical executable
– Single change involves building and deploying new version of whole application
– All the components/logic runs in a single process
– Horizontally scalable behind a load balancer
– Challenge 1 – Change cycles are tied together. A change made to a small part
of the application, requires the entire application to be rebuilt and deployed.
– Challenge 2 – Harder to maintain good modular structure/boundaries
– Challenge 3 – Scalability and Resiliency issues

6. Defining Microservices
Microservices is a variant of the service-oriented architecture (SOA) architectural style
that structures an application as a collection of loosely coupled services.
-Wikipedia
Microservices are an architectural and organizational approach to software
development where software is composed of small independent services that
communicate over well-defined APIs. These services are owned by small, self-contained
teams.
-Amazon
In a microservices architecture, the application is composed of small, independent
services.
-Microsoft

7. What are microservices?
In short, the microservice architectural style is an approach to developing a single
application as a suite of small services, each running in its own process and
communicating with lightweight mechanisms, often an HTTP resource API. These
services are built around business capabilities and independently deployable by fully
automated deployment machinery. There is a bare minimum of centralized
management of these services, which may be written in different programming
languages and use different data storage technologies.
—James Lewis & Martin Fowler
(ref- https://www.martinfowler.com/articles/microservices.html)

8. Monolithic Vs Microservices
(ref- https://www.martinfowler.com/articles/microservices.html)

9. Monolithic vs Microservices

10. Maintainability vs Changeability (Replaceability)
(ref- https://www.martinfowler.com/articles/microservices.html)

11. Microservices’ Characteristics
■ Each microservice implements a single business capability.
■ A microservice is small enough that a single small team of developers can write and
maintain it.
■ Microservices run in separate processes, communicating through well-defined APIs or
messaging patterns.
■ Microservices do not share data stores or data schemas. Each microservice is
responsible for managing its own data.
■ Microservices have separate code bases, and do not share source code. They may use
common utility libraries, however.
■ Each microservice can be deployed and updated independently of other services.
■ No technology barrier

12. SOA vs Microservices
■ SOA and microservices shares many features
■ Microservices can be considered a subset of SOA
■ Enterprise Service Bus – good example of SOA style architecture
■ Few key differences
– In Microservices services are deployed independently, unlike SOA, in which
deployment model is quite similar to a monolithic
– Microservices are lightweight as compared to SOA styled services which can be
a combination of services
– Microservices can have different data stores whereas in SOA, all services
share same data source.

13. Benefits of Microservices
■ Agility
■ Small Code, Small Teams
■ Mix of technologies
■ Resiliency
■ Scalability
■ Data Isolation

14. Adopters of Microservices

15. Design Considerations
■ Service Boundaries
■ Data consistency and integrity
■ Network Congestion and latency
■ Complexity
■ Communication between clients and application
■ Monitoring
■ Continuous Integration and Delivery (CI/CD)

16. Defining Service Boundaries
■ General Rule - Service should do "one thing“
■ Design around business capabilities, not horizontal layers such as data access or
messaging
■ Services should support loose coupling and high functional cohesion
■ A service should encapsulate domain knowledge and abstract that knowledge from
clients

17. Domain Analysis
■ Analyze the business domain to understand the application's functional requirements.
■ Next, define the bounded contexts of the domain. Each bounded context contains a
domain model that represents a particular subdomain of the larger application.
■ Within a bounded context, apply tactical DDD patterns to define entities, aggregates, and
domain services.
■ Identify the microservices in your application.

18. eCommerce – Domain Analysis

19. eCommerce – Bounded Contexts

20. Before finalizing, ensure…
■ Each service has a single responsibility.
■ There are no chatty calls between services. If splitting functionality into two services
causes them to be overly chatty, it may be a symptom that these functions belong in
the same service.
■ Each service is small enough that it can be built by a small team working
independently.
■ There are no inter-dependencies. It should always be possible to deploy a service
without redeploying any other services.
■ Services are not tightly coupled, and can evolve independently.
■ Your service boundaries will not create problems with data consistency or integrity.

21. Data Considerations
■ Each service manages its own data to avoid unintentional coupling between services.
■ It's fine for services to share the same physical database server. The problem occurs
when services share the same schema, or read and write to the same set of database
tables.
■ Embrace eventual consistency where possible.
■ For transactions, use patterns such as Scheduler Agent Supervisor and Compensating
Transaction to keep data consistent across several services.
■ For strong consistency guarantees, one service may represent the source of truth for a
given entity, which is exposed through an API. Other services might hold their own copy
of the data, or a subset of the data, that is eventually consistent with the master data
but not considered the source of truth.

22. Inter-service communication
■ Synchronous communication. In this pattern, a service calls an API that another
service exposes, using a protocol such as HTTP or RPC. This option is a synchronous
messaging pattern because the caller waits for a response from the receiver.
■ Asynchronous message passing. In this pattern, a service sends message without
waiting for a response, and one or more services process the message
asynchronously.

23. API Design
■ Two types of API:
– Public APIs that client applications call.
– Backend APIs that are used for inter-service communication.
■ Few Considerations –
– REST vs RPC
– Efficiency
– Serialization
– Framework and language support
– Compatibility & interoperability

24. API Gateways
■ Sits between clients and services
■ Acts as a reverse proxy, routing requests from clients to services
■ May also perform various cross-cutting tasks such as authentication, SSL termination,
and rate limiting
■ Available options in Azure:
– Azure Application Gateway
– Azure API Management

25. Logging And Monitoring
■ Critical for tracking what’s happening across services
■ Distributed Tracing - understanding the flow of events across services
– A single operation or transaction may involve calls to multiple services.
– To reconstruct the entire sequence of steps, each service should propagate
a correlation ID that acts as a unique identifier for that operation.
■ Available options in Azure
– Application Insights - managed service in Azure that ingests and stores
telemetry data, and provides tools for analyzing and searching the data.

26. CI/CD
■ Different options for updating services-
– Rolling Updates
– Blue-green deployments
– Canary Release

27. Hosting Models for Microservices
■ A service orchestrator that manages services running on dedicated nodes (VMs).
– Azure Service Fabric - a distributed systems platform for packaging, deploying,
and managing microservices.
– Azure Container Services - lets you deploy a production-ready Kubernetes,
DC/OS, or Docker Swarm cluster.
– AKS(Azure Container service) - a managed Kubernetes service.
■ A server-less architecture using functions as a service (FaaS).
– Azure Functions - a serverless compute service that supports various function
triggers, including HTTP requests, Service Bus queues, and Event Hubs events.

28. Orchestration Vs Server-less
-Factors to consider
■ Manageability
■ Flexibility and control
■ Portability
■ Application Integration
■ Cost
■ Scalability

29. DEMO

30. QUESTIONS?

31. References
■ https://docs.microsoft.com/en-us/azure/architecture/microservices/
■ https://www.martinfowler.com/articles/microservices.html
■ https://aws.amazon.com/microservices/
■ https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/

32. THANK YOU