So you’ve decided you are ready to embrace microservices? Now begins another fun part of your journey - choosing the platform that fits your team, your solution, and your technology choices. Up to a point the microservices platform is irrelevant during the design phase, but at some you need to align the design with a platform. On Azure you have many choices including Docker, Windows Containers, Azure Container Service and Service Fabric. Come to this session for a peak at the capabilities and approaches for each; and insights on how to select the platform that fits best for your next green field solution or migration to microservices.
Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...
Microservices On Azure - choosing the right approach for your solution
1. Microservices on Azure
choosing the right approach
for your solution
Michele Leroux Bustamante
Cofounder / CIO Solliance
Cloud/Security Architect
michelebusta@solliance.net
15. Virtualization vs. Containerization
VM
OS
Docker Engine
VM
Host OS
Hypervisor
Guest OS Guest OS Guest OS
Binaries Binaries Binaries
App A App B App B
Binaries Shared Binaries
App A App B App B
Container
NOT
a Container
16. Virtualization vs. Containerization
VM
OS
Docker Engine
VM
Host OS
Hypervisor
Guest OS Guest OS Guest OS
Binaries Binaries Binaries
App A App B App B
Binaries Shared Binaries
App A App B App B
No OS
OS
Fast
Efficient
Simple
Practical
19. ### Dockerfile for Windows
FROM windowsservercore
RUN dism /online /enable-feature /all /featurename:iis-webserver /NoRestart
RUN echo "Hello World - Dockerfile" > c:inetpubwwwrootindex.html
### build the image and run
docker build -t iis .
docker run --name iisdemo -it -p 80:80 iis cmd
Microservices On Azure - choosing the right approach for your solution
So you’ve decided you are ready to embrace microservices? Now begins another fun part of your journey - choosing the platform that fits your team, your solution, and your technology choices. Up to a point the microservices platform is irrelevant during the design phase, but at some you need to align the design with a platform. On Azure you have many choices including Docker, Windows Containers, Azure Container Service and Service Fabric. Come to this session for a peak at the capabilities and approaches for each; and insights on how to select the platform that fits best for your next green field solution or migration to microservices.
Add services behind
----- Meeting Notes (1/10/16 06:19) -----
today we have a different set of issues
browser compat, mobile browsers, apis for mobile and rich clients, back end services, layers
Classic view of the evolution; but there were many hops on the way the frame the complexity of issues…
Well understood business capability
Group highly interrelated entities, transactions, and processes
High cohesion inside the service
Reduce regression testing, cascading dependencies
And now, this…
But, how much more complicated is it really?
There is motivation…it’s all about decoupling…
Context Mapping
Complex and monolithic systems slow IT execution. By breaking monoliths into atomic microservices, teams simplify the problem space, work independently, and accelerate execution.
Ideally, the microservice domain model can ‘fit in your head’ and defines a well-understood business capability.
Context mapping identifies domain entities and interaction points. Teams define context boundaries that encapsulate domain details and groups highly interrelated entities, transactions, and processes. For example, in a trading system, a bounded domain context may represent account, security, watch list, order book, or trade.
Loosely coupled, high cohesion
Tight coupling creates large, monolithic systems. In a monolithic system, business changes require modifying multiple consumers and executing formidable regression test plans. Additionally, a low cohesion system creates a difficult to understand environment by grouping unrelated functions.
While SOA focuses on loosely coupling service consumers and providers from a technical perspective, a microservices approach focuses on loosely coupling services from a business domain perspective. While SOA does not prescribe service capabilities, a microservices approach guides service interfaces towards atomic business capabilities.
Microservices are autonomous, and exhibit low coupling with other microservices. Inside the microservice, each endpoint, resource, and function exhibits high cohesion, and helps implement a single business capability. When microservices are loosely coupled, teams can evolve and update the microservice without impacting other business capabilities.
Shared nothing architecture
Shared nothing architecture creates the ultimate loosely coupled service environment. Atomic microservices stand-alone, function independently, and don’t contain cross-service dependencies. When microservices do not share data, process, or rules, they can operate in parallel, and a microservice failure will not impact others. By preventing cascading dependencies, teams reduce regression testing before deployment and lower development cost.
Full stack, dynamic deployment
To implement shared nothing architecture, teams must unsure each microservice executes on a full stack. Each microservice encapsulates it’s own database, process server, application server, and integration server.
A microservices approach prescribes exposing the business capability and user interface via a composable service interface. Your team can rapidly compose new user experiences by weaving together “micro-views” on a web page. For example, in our trading application, three distinct microservices generate an account summary, pending orders, and watch list views displayed on the web page.
Parallel, Non-Blocking Development
Project managers accelerate delivery by fielding teams that operate in parallel and don’t block on each other. The microservices approach recommends empowering independent, autonomous teams, and organically composes systems across domain boundaries. By reducing project dependencies and developing without coordination checkpoints, teams can rapidly evolve their business capability.
The problem microservices architecture tries to solve can best be understood by its evolution and the previous technology approaches that feed it.
Do this, without concern over the data relations and aggregation – at first
What are your services?
What are your front ends?
What topology is expected, integrations, queues, async
Data ownership, transactions, eventual consistency
After defining services, apply it to technology
Why do containers stop/start so fast?
Quick to start, stop
Can snapshot, fix, redeploy
create image
Run container
Link containers (compose)
Publish to registry
It is commonly understood that Docker makes extensive use of Linux kernel features (namely namespaces and cgroups.
In a similar way, Microsoft has been adding containerization primitives to the Windows kernel, allowing any user code to execute a process in a sandboxed environment.
Those feature are only available in the just released Windows Server 2016 Tech Preview 3 (TP3), which makes it the only Windows Server operating system that is capable of running the Docker daemon today.
o http://localhost/mesos
o http://localhost/marathon
o http://localhost/
Only the cluster has access
Still may need token flow, however
Web app
400 tps
Service fabric
Partition early
With granularity
Let sf decide when to scale
No need to migrate and refactor
Service fabric
Partition early
With granularity
Let sf decide when to scale
No need to migrate and refactor