CPU and RAM costs continue to plummet. Multi-core systems are ubiquitous. Writing code is easier than it has ever been. Why, then, is it still so darn hard to make a scalable system?

1. Using Microsoft for Microservices
Presenter: Chase Q. Aucoin

2. PRESENTATION MAP
Our hope is that at the end of this your mind
will be racing with questions and ideas
2
What Is a Microservice
Business Domains
Business Agility
Teams & Organization
Building Services
Health & Monitoring
Questions & Answers
Where Does UI Fit?
Testing & Deployment
Failure as a Service

3. Simply put: It’s a self contained, domain specific, service
What is a Microservice

4. Using Microsoft for Microservices 4
When you hear the term cloud you probably think
a place. When we say cloud we mean a set of
patterns and practices. These patterns and
practices work regardless of hosted providers or
on premises deployments.
What Does Cloud mean?
Cloud Services are available on demand. Whether
that is VMs, File Storage, or Data Processing
On Demand
Cloud services are distributed across many fault
zones to ensure high uptime.
Distributed
In a cloud scenario building applications that can
scale horizontally is favored to the traditional
approach of increasing the size of compute
resources. This allows for “infinite” scalability.
Horizontal Scale
Because of the transient nature of resources in a
cloud environment services assume that they will fail
instead of assuming they will always exist.
Built To Fail
Lose coupling between components allows easy
transitions between implementations and locality of
a given resource.
Loosely Coupled
Where possible use existing built technical
resources to provide the highest levels of
productivity and reduce operations complexity.
Favor Existing Technical Solutions

5. Using Microsoft for Microservices 5
Traditional when we think of a service we think of an in process body of code that has
methods. Sometimes we mean the actual deployable “windows service”. Sometimes we
think of it as a worker process that is servicing something on a continuous loop.
During this presentation we mean an application that does the “heavy lifting” of
responding to a clients request.
What is a service

6. Using Microsoft for Microservices
Traditional 3-Tier Architecture
Client - Presentation
Service – Business Logic
Data - Database

7. Using Microsoft for Microservices 7
The monolith is ancient. It contains all knowledge. It succeeds as one. It fails as
one.
The Monolith
Most monolithic application start from a need to get business value out quickly.
They are typically feature driven and more often than not built in an
environment of tight deadlines and high expectations. It is only in hindsight as
productivity slows, and the pace of innovation declines that we question its
nature. Most times at this point it has become so engrained into its place within
a business that changing its nature seems like an impossible task.
It is not impossible, but it does take work.

8. Using Microsoft for Microservices 8
You only have to deploy and manage one
application
Single Deployable
Cloud services are distributed across many fault
zones to ensure high uptime.
Initial Agility Is High
You can change large amounts of the source all in
one place. This could also be considered a con in
most scenarios.
Simplifies Make Broad Changes
Feature A that is part of one domain may be ready
to go but other features in other domains may have
committed code that are not ready for deployment
into a production environment
Inconsistent State
As you move the application through the delivery
pipeline you have to test the entire surface area of
the application.
Testing
You cannot scale the areas of the application that
are creating “hot zones” independently making for
difficult management scenarios both technically and
also with your consumers.
Scale
Deployable Service or Data
Feature A
Feature B
Feature C
Feature D
Feature E
Feature F
Monolithic ApplicationAdvantages Challenges

9. Using Microsoft for Microservices 9
“I don’t need to know everything. I just need to know where to find it when I
need it.” Albert Einstein
Microservices
Microservices instead of being solely focused on features. Are focused on a
given business or technical domain or “bounded context” that they operate in.
This nature allows us to have laser focus on business need. It also allows us to
speak the same language as the business and delivery applications in a more
meaningful and rapid way in a large scale application set.

10. Using Microsoft for Microservices 10
If one service fails it does not bring down the entire
application stack. Worst case scenario loss of a
single set of functionality is lost until recovered.
Physically Decoupled
You only have to test one domain. This does require
an adherence to some SOLID principals for best
results.
Testing
Easily scale a specific potion of the application that
needs to scale. Likewise you can scale delivery
teams more reliably providing more types of
functionality going out in parallel.
Scale
Embracing a Microservice paradigm for software
delivery usually means shift mentality within the
organization about how to deliver software.
Requires Culture Shift
Since there are more moving parts that means there
is ultimately more to have to keep track of. This is
where automation is important.
Large Footprint
It is usually slow initially for the organization to shift
culture and get it’s processes in place
Initial Agility Is Slower
Deployable Domain
Service A
Data A
Microservice ApplicationAdvantages Challenges
Deployable Domain
Service B
Data B
Deployable Domain
Service C
Data C
Deployable Domain
Service D
Data D

11. Using Microsoft for Microservices 11
Advocates fewer services but doesn’t suggest what
the bounding of those service are. Services are
typically very “smart”
Fewer Components
The logic for a feature may be scattered across
many domains.
Logic Across Many Domains
Mulesoft, Biztalk, Corba, EJB
Middleware Required
Service a scoped within the bounds of a given
domain.
Many Small Components
Typically the business logic for doing an atomic body
of work lives within a single service.
Business Logic Per Service
Service are exposed via simple wire protocols such
as HTTP with JSON with API gateways creating high
levels of interoperability across BU’s
API Driven
Isn’t This Just SOA?SOA Microservices
Sort of..
Conceptually the 2 are similar, but SOA tends
to be a loaded term that may be defined
drastically different form one person to the
next.
In our experience SOA becomes a vehicle for:
• Selling expensive over-complicated software
(ESBs, BPM tools, ERP, Service Registries Etc..),
• Long business process modeling initiatives
• Large checks with little to no tangible ROI

12. How do we think about services in relation to the business
Business Domains

13. Using Microsoft for Microservices
What is a Business Domain?
An area of the business that tends to use similar taxonomy/terminology to describe a
business/technical need or value proposition.
1
Focuses on the management
and information retrieval of
Employees
Employees
2
Focuses on the tracking and
management of projects
Projects
3
Focuses on the logging of events
in the system
Logging
4
Focuses on the authentication
of users into the system (Identity
management)
Authentication

14. Using Microsoft for Microservices
Why we organize Microservices by domain?
It does a few things for us.
• Enables us to speak in a common language with the business alleviating miscommunication
• Allows us to create end to end ownership for a team
• The business and engineers work closer allowing for rapid ideation, validation, and iteration
• Create highly concurrent deployment scenarios
• Create isolation. Services only have to care about what is happening within their domain without being
bogged down by having to know everything all the time
• Alleviates paralysis by analysis

15. Scaling teams is just as important as scaling software
Teams & Organization

16. Using Microsoft for Microservices
Conways Law
organizations which design systems ... are constrained to produce
designs which are copies of the communication structures of these
organizations.
“
“
Melvin Edward Conway PhD | Rockwell Semiconductor
Business Team
UI Team
Service Team
Data Team

17. Using Microsoft for Microservices
Inverse Conways Law
Organizations which design systems ... Are encouraged to create
communication structures that produce the desired designs for the
systems.
“
“
David Pitt | Keyhole Software
Domain A Team
Domain B Team
Domain C Team
Domain D Team

18. Using Microsoft for Microservices 18
Siloed teams leads to siloed application architecture.
Limiting holistic knowledge of a give domain within
the business.
Siloed Teams
Difficult to scale teams to meet the demands of the
business.
Limited Scalability
Too much time is spent transferring knowledge
between the layers so everyone has to know
everything all the time. This hinders the
effectiveness of delivery.
Productivity
Each delivery team knows exactly what it needs in
order to get it’s products into production end to
end.
Cross Functional Teams
Teams can easily be distributed across BU’s and as
new domains are required new teams can be on-
boarded to meet demand without limiting existing
teams.
Highly Scalable
Once the cross functional team hits it’s stride new
features can be production ready in days not
months.
Highly Productive
Conways LawSOA/Monolith Microservices
organizations which design systems ... are
constrained to produce designs which are copies of
the communication structures of these
organizations.
“
“
Melvin Edward Conway PhD | Rockwell Semiconductor

19. Delivering more, faster, with automation and collaboration
Business Agility

20. Using Microsoft for Microservices
How Can We Create More Value Across Our Organization?
Reuse applications that we have already built value in to create value across all of our
business units.
Microservice facilitate this because at their heart they are just APIs.

21. Using Microsoft for Microservices 21
“I think of novels in architectural terms. You have to enter at the gate, and this
gate must be constructed in such a way that the reader has immediate
confidence in the strength of the building.”” Ian Mcewan
API Gateways
A strong gateway is incredibly valuable within an organization. It allows your
work to be self documenting and creates scenarios for pull instead of push
during cross collaboration. It enables us to leverage our existing code over and
over in new and novel ways.

22. Beyond Conceptual: how do we put it together?
Building Services

23. Using Microsoft for Microservices 23
What are the pieces that enable
us to create Microservices in our
organization?
Technical Components

24. Using Microsoft for Microservices 24
Since our services are so widely
distributed we need to know when
one is failing and pull it out of load to
alleviate stress during peak load.
Circuit Breaker
Service Fabric – Built In
Polly
Service Fabric - Name Service
WCF – Discovery Service
Azure – Service Bus
The service registry lets services find
each other at run time without
having to know in advance where
service are located.
Service Registry
Using JavaScript/HTML and
frameworks like backbone or angular
powered by services requested via
AJAX through the API gateway
SPA Front-End
Angular
Backbone
Ember
React
Web API with Swagger
Azure – API Gateway
Mashery
Mulesoft
The gateway is the entry point to
serve up client requests via an HTTP
based API for maximum
interoperability
API gateway

25. Using Microsoft for Microservices 25
TFS – Release Management
Jenkins
TeamCity
Service Fabric
Docker
The biggest key to the successful
implementation of the Microservice
paradigm is to automate as much of
the delivery cycle.
Continuous Delivery
Messaging increases asynchrony
across the system and enables
patterns such as CQRS, Pipes &
Filters, and Subscription Based
Extension
Messaging
Azure – Service Bus
RabbitMQ
Service Fabric – Built In
Azure - Application Insights
Operations Management Suite
ELK Stack
Log aggregation allows you to see
what’s going on across your services
at a glance.
Log Aggregation
Nuget lets us manage the packaging
and delivery of shared libraries within
the enterprise
NuGet
ProGet
MyGet
Nuget.Server

26. Using Microsoft for Microservices
SPA SPA SPA SPA
API Gateway API Gateway API Gateway API Gateway
Auth Primary Auth Secondary Auth Secondary Employee Primary
Employee SecondaryEmployee Secondary Project Primary Project Secondary
Project Secondary

27. Using Microsoft for Microservices
Project DAL
Project Service
Project API
[Project]
Appointment DAL
Appointment Service
Appointment API
[Appointment]
Employee DAL
Employee Service
Employee API
[Employee]
SQL Server Mongo/3Rd Party API
Sample Architecture
Authorization
Authentication
Service Fabric
Application Insights
TFS/ Release Management

28. Moving away from rendered views
How Does UI Fit?

29. Using Microsoft for Microservices
How do we think differently about UI in this paradigm?
• The UI is just another consumer of services
• The UI should go on a separate cadence as the services as it wil be the slowest to move through the
business process and the least impactful to system stability
• Favor simple HTML and Javascript modules

30. Best practices to make launching the most boring part of the cycle
Testing & Deployment

31. Using Microsoft for Microservices
What should we keep in mind for testing?
• Automate service testing and make it part of the CI/CD process
• Keep the testing surface area limited to the domain that is being published.
• Isolate a domain specific automated integration testing environment for regression that can be drop
and recreated during the delivery process.

32. Using Microsoft for Microservices
Containers
• Instead of delivering “code” deliver containers.
• Docker and Service Fabric are excellent choices for containerization.
• Have an automated rollback strategy as part of deployment. This is built into Service Fabric
• Configuration should be injected at runtime or via container configuration
• Storage mechanisms should be durable and movable in case of failure. Good choices include vSphere
disk virtualization or Azure File Storage mounted as a drive at application startup.

33. Keeping your system healthy after launch
Health & Monitoring

34. Using Microsoft for Microservices
How do we keep services healthy?
• Leverage tools like Application Insights and ELK stack
• Use your hosting platforms built in health tools. Service Fabric, IIS, Azure all have customizable health
metrics.

35. Dealing with mission critical failure before it ever happens
Failure As A Service

36. Using Microsoft for Microservices
What is failure as a service?
• Use tools like Keyhole Trouble Maker or Built in Service Fabric tools to randomly stop applications in
production
• If your apps are able to handle this continual shutting off of parts of the system you can sleep easy at
night knowing that the system is stable.
Failure As A Service
Dealing with mission critical failure before it happens

37. Question & Answers