What email address or phone number would you like to use to sign in to Docs.com?
If you already have an account that you use with Office or other Microsoft services, enter it here.
Or sign in with:
Signing in allows you to download and like content, and it provides the authors analytical data about your interactions with their content.
Embed code for: From_a_Monolith_To_Microservices_With_ServiceFabric
Select a size
Slides from the presentation about Microservices and Service Fabric
From a monolith to microservices, with Azure Service Fabric
Bang Head Here
Think locally, Act Globally
The road to Microservices
1 year of “Microservices”
Which module does this functionality fit?
Get a coffee
How/where do we host this service?
Cloud? Which product? How to deploy? Monitor? communicate with The Monolith?
Business case validation?
Configuration management? (that one is a biggy)
What DB can/should we use? SqlServer, Ravendb, DocumentDB?
Internet facing services?
What about security?
New services nearly every release, every week
150 git repos
1 person can’t assess the entire system
20 42 windows services
26 58 IIS processes
Load balanced on 2 4 serveurs
40 Windows services (doubled)
52 IIS processes (doubled)
Zero Down Time Deploys
Decouple the who from the where
Highly available, Consistent
Cluster management for microservices
Windows or Linux
Process deployment and orchestration
Stateless / Stateful services
Minimize (negative) impact, Maximize benefits
Can we do this?
What would this mean for developers?
What would it mean for DevOps?
What does it mean for the Lifecycle?
What do we get from this?
So, can we have the cake, and eat it too?
MSMQ : bound to a machine
DTC (and other 2PC protocols) require HA and low latency between resources.
Incompatible with the cloud
DTC : Msmq/NServiceBus
Outbox and Deduplication Pattern
“Using Outbox allows for running endpoints with similar reliability to DTC while not actually using DTC.”
At least once + deduplication
DTC : WCF
No tricks there unfortunately
Replace with messaging
Service Fabric ticks all the boxes
Cloud vs On-prem
Future proof (cloud, container, no vendor lock-in)
Remove DTC and MSMQ
Hosting a web app In Service Fabric
Service Fabric Overview
Twitter : @serbrech
Je suis francais
Worked in NO all my career on multiple projects
NO very open to new tech, lots of freedom in the choice of tech.
Seems to be less scared to evolve than other places I have heard of.
I just moved back to France where I will work remotely for Microsoft.
What are microservices?
Who works with Microservices?
Anyone knows Service Fabric, or better has tried it?
What’s a monolith?
Origins of this experiment
Concepts : Service Discovery
Concepts : Reverse Proxy
What’s a m
But… Lack of experience with large system,
lack of architecture leadership,
legacy code, scared.
Lots of WCF (Do you use WCF? Web API? Sync vs Async comm)
What’s the problem?
Synchronous communication, WCF, DTC, Temporal dependencies
If A crashes, B is down as well… What about High availability?
How do you do versionning?
Anyone here «doesn’t do» versionning?
Change contract? Who is impacted?
Anyone recognize their dependency diagram on this slide?
How did this even work you may ask?
All contract on same version
Big Bang Deployment
Tough testing, best effort, not deteriministic.
Ans when something goes wrong...
What about scale??
AUTOMATE all the things. Provisionning, deployments, etc…
Anyone tried to do this?
Anyone has been successful doing this?
Deadlines, we try to do better…
No temporal dependencies
Version contracts … ok
Autonomous deployments, all scripted, reproducible.
Painful, A lot of things to learn. Bad bounded context, bad domain definition..
Same infrastructure (ex : .net version)
Next one :
More responsibilities on our infrastructure. Try to get on Azure…
-> Co mplicated (legal, communication with internal infra, multiple env…)
-> VMs on azure, in the our AD domain (hybrid cloud)
New DB -> ARM + DSC on our shoulders
Differnet app server -> ARM + DSC (anyone has tried to automate msmq install?
Tough but fair. If the team does not reuse the infra, it’s up to us to set it up.
But…. Multiple env, config management, load balancers, msmq addresses (bound to machine name / IP)
system NOT decoupled from Infra.
All env will experience if try full automation.
We automated a LOT of things along the way.
Build script, leveraged by everyone.
RavenDb provisioning, and deployment. (Anyone using RavenDB here? cry)
Octopus and teamcity templates + deployment scripts
Building blocks, legos
Towards smaller services ...
System flow based on events, not on WCF.
Autonomous! Autonomous! Autonomous!
And all these learnings, little by little, were adopted. Which made developing small new services easier (conventions, deployment, etc…) And here we are today, with about 10 teams writing new small(ish) services, web apis, web components, spas, etc…
WE DO MICROSERVICES
New services nearly every release, if not every week
150 git repos in a year. (SPAs, Web Apis, Wcf, Windows Services, Batch, Infrastructure Services)
Majority of services still dependent in some way on waypoint
Only a few developers are involved in the big bang deployment that occurs once a month
It becomes increasingly hard (read, impossible) for 1 person to know if the system is 100% OK
Everything is a trade off in software.
Clear that we do not get the local simplicity for free
The cost is the architecture and infrastructure complexity
cost of writing more services. maintaining at scale (people/load)
We do all this because we need flexibility/scalability/availability… otherwise, please keep writing a small monolith!
Service B Config to call Service A
What happens if I want to move service A to a different place?
Abstract the where, and the namig service. Gateway to our cluster
Pretty negative because too invasive.
But it’s not
All in one
What I told you and more
Integrate with Azure
Runs locally on dev machine
Can install on-premise.
Can provision on azure with portal integration
The more you use it, the more benefits you get from it
Cluster management bells and whistles
Self Hosted (Owin)
App Manifest, Service Manifest, Service Proxy
Communicate with RavenDB just the same. No difference there. It’s just network, it’s just processes. No magic
Progressively migrate services? All but queues…
If not we need to think twice about microservices…
Ideally, not much… keep working the same as today
Stop thinking about server, think about environment
Flexibility, scale endpoints
Deployment? Enables progressive rollout!
Azure Service Bus,
But also SqlServer
Cloud strategy : handle failures through HA archi and infra.
Handle the Chaos monkey.
Reliability : ExactlyOnce
At least once + Deduplication
Thank If to let me work on this and support the research
I wish I could help taking this further, Hope it will be taken further at waypoint as I will unfortunately not be on the project from December 15re :