Recently I attended this event @ Microsoft Reactor in London, I was part of a four-person team, consisting of two developers and two ops. This was my first time participating in such an event. Prior to attending I did my homework on Azure Service Fabric cluster reviewing Channel 9 content, automating the deployment of the SF cluster through Visual Studio Team Services and ARM Template. Connecting to the Service Fabric Explorer (management interface) and having a look under the hood.
Approx. 30 teams attended, each team was assigned as Microsoft employee as a mentor/proctor.
The challenge involved an application cloned from a Git repository and SF cluster provided by Microsoft, the source code needed compiled and deployed to the cluster. Metrics were used to monitor high availability and response times of the application while suggested improvements to application, microservices and security were applied.
Visual Studio Team Services was the preferred choice for automation and we were one of the first teams to have CI/CD pipeline configured and application deployed.
The SF Product Team visited each team for feedback. I noted no verify connection to the SF cluster in Team Services (Kubernetes verify connection has this) which means you needed to run a release before you knew if the connection was valid or not. I feed this back as a suggested improvement.
We did run into pre-designed pitfalls which did take time to fix, it was a challenge after all. Some pitfalls we seemed to find first and distracted from innovating.
The deep-dive exposure to SF was a quick way to get skilled up in the Product, the challenge was intense but very enjoyable. Just like any DevOps project, blockers need removed and communication between the team essential.
The take always for me was understanding when to use SF, over Kubernetes or Platform as a Service offerings and the subtle nuances between them. Some real life gotchas when automating code change with additional partition collections to an Azure Cosmo Database you need to delete the application and redeploy (potential downtime).
To prevent downtime and performance impact use Azure Traffic Manager and a staging SF cluster for pushing code changes. Direct a small percentage of traffic to the staging SF cluster, monitor user experience in real time using Application Insights : Live Metrics.
SF Mesh currently in Public Preview will be a game changer Microsoft will provide a fully managed and patched cluster you just bring your code and define microservices.
