The Azure Service Fabric Team Blog has a new case study of a customer using Service Fabric: https://blogs.msdn.microsoft.com/azureservicefabric/2016/03/15/service-fabric-customer-profile-talktalk-tv/. It provides great detail on the application architecture and the advantages of Service Fabric that are leveraged, but it speaks less about the organizational transformation that was involved.
The solution design addresses some of the fundamental drivers of the Talk Talk TV audience: they are experiencing rapid growth in their viewers, and any solution must scale readily to meet those changes while preserving profit margins. Their industry is also very competitive. With the internet, customers have choices in entertainment. Only nimble organizations who can meet rapidly evolving consumer desires will survive.
The platform they describe appears to enable agile development and inherent scalability at controllable cost.
The company appears to be braver than many in that they are pushing for organizational change to help drive the innovation they seek. The set a goal for establishing Autonomous experimental teams.
The TalkTalk TV leadership desired to create nimble, teams that can deliver functionality quicker.
Many companies, in my experience, are very timid about pursuing changes that would disrupt their existing staffing and skill models. Yet, those disruptive changes are the ones that, while risky, offer the greatest possible return.
They cite frustration with their old style architecture due to difficulty coordination of SQL changes with code, and the need for downtime in those cases.
By shifting state to stateful services and actors, they are leveraging Service fabric to achieve easier deployments with little downtime. This allows for better user experience and greater team agility.
With the unpredictability of their customer growth, and the inherent strain in delivering high volumes of media data, they need a platform that scales easily. The Service Fabric clusters seem ideal for this in that they can add new nodes as demands dictate, and better utilize those servers with the high-density that Service Fabric enables.
The subscription-based services, like Document DB, offer a huge advantage that allows them to provision just what they need and no more, and very quickly.
Security is a point of fear with many companies. This business appears to use Key Vault and Azure AD to secure access to the assets and services that comprise the solution.
I wish the authors or the case study and gone into greater depth regarding how security issues were addressed.
The cite increased productivity (get more done with fewer IT people). This means lower costs for a given level of investment.
The one-box development experience with the full Service Fabric services available locally increased our productivity and enabled us to deliver more features faster
I infer that they also reduced time and effort needed over their original deployment process. As they cited it, it was clumsy and probably labor-intensive
the use of database-stored queues to manage cross-service interactions required painstaking coordination to manage deployments and upgrades simultaneously every week and usually involved downtime of the application.
The authors claim the solution enables scale and growth through agility and continuous delivery.
The case study details a number of Azure services used including Service Fabric, Document DB, Media Services, Key Vault, Active Directory, and Azure Batch. They explain clearly how those services are used to support the overall goal of delivering media content to their customers.
I especially appreciated the deeper dive into the Service Fabric architecture. As someone who is just learning this, one piece at a time, it is empowering and educational to see how all the pieces can be hooked together into a working system.
The use of a light-weight activity gateway service was thought-provoking for me, and got me thinking more about how I can use microservices rather than macro-services.
I’m always interested in the organizational changes that accompany a new technology adoption. I’m especially keen on this where cloud-based services are concerned. As mentioned above, they deliberately sought to create autonomous experimental teams. I’m eager to see how this works for them. It aligns with my vision for modern development teams.