PurePerformance - 073 Understanding Azure Service Fabric with Sravan Rengarajan

Episode Date: October 22, 2018

Did you know that Azure Service Fabric is used by most of Microsoft’s global high scale services such as Bing, Dynamics or Xbox)? It’s a battle tested distributed systems platform that enables developers to deploy, manage and scale their microservices. In this session we have Sravan Rengarajan, Program Manager at Microsoft Azure, giving us an overview of the key use cases, how Service Fabric started and in which direction it is heading. We also learn how you get your own free local version of Service Fabric and why Service Fabric gets us towards real Serverless computing. Additional information can be found on the Service Fabric GitHub codebase – yeah – its all out there on GitHub!https://www.linkedin.com/in/sravan-rengarajan/ - Sravan on Linkedinhttp://aka.ms/servicefabricdocs - learn more about Service Fabrichttp://aka.ms/servicefabricmesh - learn more about Meshhttp://aka.ms/tryservicefabric - free clusters to party on!https://github.com/microsoft/service-fabric - GitHub codebase

It's time for Pure Performance! Get your stopwatches ready, it another episode of Pure Performance. My name is Brian Wilson and with me as always is my trusty sidekick and overlord Andy Grabner. Hello Andy, how are you today? Oh overlord, what's that all about? I always refer to the Austrians as the Austrian overlords because you guys Because you guys are just so much smarter, it seems, than at least us SEs over here. But, yeah. Nah.

Well, at least I think we must do something right over here on this side of the pond. Because as we all just discussed, it's really quiet these days here in the summer months in Europe. Yeah. And it still seems we get stuff done somehow. You have all those days off, all that beer, and you still get work done somehow but uh you have so many you have all those days off all that beer and you still get work done and we don't it's amazing yeah i'm a little under the weather today so i'll be probably a little bit more of a calm person but since uh as the airing of this will be right around the corner from halloween i'll say happy halloween

to you because you know that's such i have heard that's a huge huge holiday in austria probably bigger than like i don't know i think it's the biggest holiday in Austria, isn't it? Of course. Well, at least in the stores it looks like it. No, seriously. Oh, really? Yeah, we do some Halloween. Everything that is commercial and that sells makes it to everywhere in the world.

So we have it too. So I want to introduce, and hopefully I pronounced your name correctly, and you can kick me later if I got it too. So I want to introduce and hopefully I pronounce your name correctly. And, you know, you can kick me later if I got it wrong. But Shravan, if you are on the line, you know, hopefully you are there. Are you there with us? How are you? Yeah, I'm here. Hey, thanks for having me, guys. And you pronounce my name perfectly fine.

Don't worry. Perfect. I didn't try the last name, to be honest, even though I could try. That's quite all right. Shravan, can you introduce yourself, who you are? We know, well, this is based on if people read the description of the podcast, we know you're a program manager at Microsoft, but what exactly are you a program manager for? And give us a little background. Yeah, yeah, absolutely.

So I'm Shravan. I am a program manager in Microsoft Azure in in the Azure compute group. And I work on a product called Azure diagnostics. So that's how customers who use the ServiceFiber platform to get the data in their applications, in events from the platform itself, and then also performance counters from the infrastructure, which their code runs on, getting all of that data into a tool like Dynatrace or Azure Log Analytics so that they can visualize it, create alerts, monitoring, et cetera. Cool. Hey, and I know you're obviously from Microsoft, but we always try to draw some parallels

so people understand the terminology. So that means you are working in the compute part of Azure, and that means Service Fabric is one of the compute offerings. Is there an equivalent to Service Fabric in some of your competitors' cloud offerings? Yeah, I wouldn't. I would say there isn't quite a direct equivalent,

but I would consider Service Fabric as a layer in between IaaS and PaaS, which are typically the compute products that all the cloud providers offer. I would say we are pretty similar to something like GKE, Google Kubernetes Engine, or ECS, which is Elastic Container Service. They also have a Kubernetes offering called EKS. So that's with Amazon Web Services. And similarly, Azure also has a Kubernetes offering called Azure Kubernetes Service. But each of these things are what we call container orchestrators. So if you guys are familiar with containers, this is kind of what tells you which nodes or which machines your

container should go on and schedules the deployments and manages those resources for you. So Service Fabric does all of that as well. But before containerization took off, it was actually just primarily used for microservices in the form of processes, or you can even just take an executable with all of its dependencies and then deploy that to our platform and then the platform is smart enough to know like we should put these microservices on these machines to have the best uh you know failover resiliency etc cool so as a developer then if i if i'm using service fabric and obviously you moved now to containers, what's the typical way of me as a developer writing a microservice? That means I upload my container or my Docker file or how does this work?

So containers are a way to – I guess it's an application of the microservices paradigm. So with traditional development, you usually have a lot of apps have these like three tier architecture, right? You have some sort of maybe like web or front end UI. And then you have a middle layer, which has a lot of business logic and then more processing. And then finally, the third, the deepest layer is some sort of database or data store. And typically when customers or when anyone does an upgrade to their application, all these components, each or each of the three components are extremely tightly coupled. So you have to upgrade the entire thing, even if you're just making like one line, a one line change or so. And then additionally, the upgrade usually just involve copying that into another virtual machine entirely. This can be very like error prone, very expensive, very time consuming. So with microservices, the idea is we compartmentalize

functionality in your application so that you have individual running components that somebody and basically these processes run on their own. They can be upgraded on their own. They can be scaled on their own. So I'll give you an example. Like let's say you're running an e-commerce site and you can have a microservices or a microservice for your payments part. You have microservices for your shopping cart, microservices for your product catalog.

And if you want to make just a change to the shopping cart part, you can just make that change and Service Fabric will only update the bits for that microservice running in your deployment and everything else will be untouched. And that gets independently versioned. So you can roll back just that part if you want. Let's say you're experiencing a lot of traffic on just the payment side and you need to scale up so you can easily just scale that up without having to copy over the entire application if that makes sense yeah that makes a lot of sense cool and and uh from and service fabric if i am developing a microservice coming back to your examples they just brought from let's say the shopping cart do I as a developer need to define the dependencies that I have

so that Service Fabric actually knows who am I depending on or is this something that I have to kind of not declare? This is something that through our SDK, you can easily have an inter-service-to-service communication or if one of your services has dependency on another, that's totally fine. One of the things I also wanted to talk about was the thing with data. So the bottom tier of the monolithic application, the database, right, that usually requires a whole network call to some other store like SQL Database

or like MongoDB or something. And then that call has to go fetch the data and then come all the way back to your application. But with Service Fabric and then I think a lot of other orchestrators are providing similar capabilities, we have something what's called stateful services. So now you don't need to take a dependency on an external data store. You can have your microservice itself hold all of your data in memory, which takes no dependency on network, reduces latency, and is a lot more reliable. You can work with your data just as you would with any sort of collection in.NET. You can literally just type in the data structure, iReliableDictionary or iReliableQueue, and all of your data will just live in memory that way.

So we see a lot of customers who require this increased throughput and low latency, such as for gaming or for high-frequency trading, using this paradigm. For that data, is that read out from a database? Is it written as a file and deployed along with it? Is it either or? Like, what's that situation? I'm glad you asked that question.

So the main pro for this method is the data is co-located on the node itself. So the data, I believe the actual implementation of it is it is in a file like on the nodes. And service fabric is obviously like if that node goes down, like you are at risk of maybe losing that data. So service fabric is smart enough to make sure that your stateful service is replicated across multiple nodes. Usually we recommend at least three replicas.

OK. And that's what we call call one partition of your data. Okay, so then obviously when you're doing upgrades, you're gonna do rolling upgrades, so this way, you never look at. Yep, and that's another thing with service fabric, compared to Kubernetes or other orchestrators. So a lot of these problems like naming and service discovery,

routing, rolling upgrades, we have that built into our platform with ways that we think would be beneficial to users. For someone using something like Kubernetes, you might have to integrate with other open source technologies to build that in. You might have to do more like plug and play. It does give you more freedom in that sense. But with service fabric, you have rolling upgrades, for example, built into the platform. I think one of the cool things that you talk about there is you're building upon the long history of experience of Microsoft in how to deploy these things that sounds like you're saying which is actually I think a real good benefit because anyone else doing different kind of deployments of different technologies they're going to be figuring out what they think is best practice or looking at what they might be able to do whereas you know

you're offering what you have years and years and years of experience doing so that's pretty cool yeah and then more to that so this was was actually started many years ago, like when Azure first came to be. And we were working on bringing SQL Server into the cloud. So I'm not sure if you guys know, but actually many, many internal services such as Azure SQL DB, Cosmos DB, and not just Azure services, but like Dynamics and Bing, they all use service fabric to power their compute. Well, that's cool and impressive and also obviously gives your customers the, I would say, the good feeling that they are not just using a new technology

because you came up with a service to just fill a gap with your competition. You actually use or expose a service now to the public that you have battle tested and used over the years. And you know it works. So that's pretty sweet. Have you seen a change? Because you mentioned, and correct me if I'm wrong, but you mentioned earlier Service Fabric has been around for a while. It used to be as a developer, you defined your processes and your applications and then Service Fabric took them and scaled them up and down and now it's moving more towards containers.

Is that shift complete? Meaning, do we see 100% of new development that happens on service fabric being container-based, or do you still see kind of somewhat of legacy approaches? Yeah, I would say it's a mixed bag. There are still folks who don't want to fully move to containers, and they prefer just developing.NET processes. So we have our own programming models as well. For stateful, stateless services,

we also have an actor programming model. And a lot of customers use that. But to your point, we do recognize and we see a huge trend in containerization and folks just wanting to package. We see containers as like a packaging technology. So folks packaging all their dependencies into one container and then using service fabric

to orchestrate all of their containers. We have customers like Alaska Airlines, for example, is a huge proponent of that methodology. And then to continue on that, though, one of Microsoft or I would say Azure's plays is the lift and shift, which is basically if you run a lot of you already have your own data center, you run on prem and you're thinking about moving to the cloud. But you don't want to really like rearchitecture everything and you're worried about security security or network issues or whatever. So basically, lift and shift promises that you'll be able to lift all of your current workloads and bring that to the cloud with ease. So with Service Fabric and microservices development,

there's a lot of apprehension that, oh, microservices seem cool, but I have to dismantle everything and maybe put it all back together. And I'm not sure if it's going to work the way I want it to. But with service fabric, like I like to think of it as the customer journey as a spectrum. So you can first bring your workloads, lift and shift them to service fabric just by taking the executables and their dependencies. So we call that running guest executables and their dependencies. So we call that running guest executables. Or you can package your workloads into containers. Or if you already have it running in containers, that's perfect. You can bring that into service fabric,

and then we'll work with you over time to compartmentalize certain parts of your application into different microservices. So it's not like you're going from zero to 100 overnight. It's a journey, and we realize that as well. Yeah. It's actually fascinating because we have been – some of our colleagues have been writing blogs about the approach of lift and shift but then breaking the monolith. So with our product, with Dynatrace, we can obviously live on the, let's say, more the classical application architectures like a monolithic app. We can tell you what type of code gets executed when certain endpoints are hit and what are the dependencies to enter the backend database. And with this information, you can actually make smarter decisions on what pieces of the monolith you want to break out or which pieces

of the monolith you want to rebuild and then latch on top as a service. And it seems like you're seeing the complete same trend here. And the first piece is lifting and shifting into the new, into the cloud world and then breaking it apart. You said compartmentalizing um so i think that's that's actually great to see that this also happens obviously uh in in in the azure world um is there now one thing you mentioned earlier and i know it just came with one of the words you said you mentioned gaming um and and it's interesting that you mentioned gaming because we had a previous recording. We recorded it yesterday, but it probably aired like two weeks ago. And we talked about Minecraft and monitoring Minecraft with Dynatrace with our colleague Mike Villager.

So is gaming really – did it just mention it just by – was it a random thought or is this really something that gamers use as well oh yeah absolutely it's i would say it's not just a random thought uh we have a new customer actually um called next games and they have a augmented reality mobile game called the walking dead i believe it is so you can use this app and you can walk around like your office building and then you'll be able to see these zombies and then you can like buy guns so that entire wrong there yeah exactly so that requires like thousands of connections connecting to thousands of devices um they use stateful services as well as well as stateless services, which is obviously the opposite of that. But yeah, gaming is one of, I would say, one of our big focus verticals. A lot of game development, not just with service fabric, but with something like Xbox as well

and Xbox Live, which powers millions of consoles connected to one another. So only a few services can really handle that scale. box live which powers like millions of consoles connected to one another um so only like you know a few services can really handle handle that scale and just just to bring it all together then um is do you happen to know offhand if the sign-in for it's a centralized sign-in for minecraft is that part living in the service fabric um I don't know. Okay. Mike was just mentioning I put that pit yesterday and I was curious.

Yeah, because it was really fun because he had this as a side project monitoring Minecraft to learn more about internal architecture and then figuring out how his modded version, where it spends too much time and which dependencies it has

to other services. And then he came up with, well, there's always, when you sign on, there's like a call to an external service. And sometimes that call, you know, took a little too long. And so he was wondering where the call actually ends up. Yeah, I'm not sure if that's, if Minecraft specifically uses service fabric. But I know like other services in Xbox do. Yeah. Now I got another question. So service fabric. So gaming is interesting. Any any other particular areas where service fabric is, let's say, more used than others?

Do you see any trends or is it just across the board? Yeah, it's it's really across the board. A lot of customers, going back to the lift and shift story, so like a retail provider, like an insurance company, they have a bunch of internal software that they use, and they want to just move to the cloud in general. We saw with the trend many years ago that IaaS was the big thing. That's what AWS did really well, basically just copying over your virtual machines. But now people want more layers of abstraction and more convenience, right? Because you don't want to be paying to

manage a bunch of VMs or you're only paying someone to do that. You'd rather just focus on the actual development of your application. So a lot of these folks, and then another thing is Azure has a service called Cloud Services, which was our, we like to call it PaaS V1. And that's what people are using first if they didn't want to use virtual machines. But now people are migrating from that to service fabric. They're doing what we call app modernization, which is, you know, breaking out their monoliths into microservices, adopting containers. So any anyone really who wants to use containers wants to use wants to orchestrate them on Windows or Linux. So that's another thing. Service fabric is available for Windows Server, but also for Linux as well.

It did start out as a Windows only thing initially, but just as Azure used to be called, Windows Azure, like we're more than Windows now. We wanna embrace open source and everyone. We're actually seeing a lot of customers don't wanna pay license fees for Windows so they prefer Linux and we service harbor came out with a Linux offering it went GA I believe last year Linux containers are miles ahead of Windows containers as

well so we have to be able to support these and deliver a great experience to stay stay ahead of the game right I believe if you run a.NET Core service in Linux, there's no license for that, correct? Yeah. You're paying for that. Yeah, I just think that's really awesome. Azure's really come a long, long way. One thing you mentioned in here,

and I think we have a very common connection here, right? We're very much into servicing the multi-hybrid cloud and all this right whether or not you're running in your own data center back and forth in the cloud other clouds um you put a note here that uh service fabric can run in your own system yeah between can you go into that a little bit because we see that as a really big trend on like once people are becoming really mature in what we call the enterprise cloud, that there's this crossover. I'm glad you mentioned that. Hybrid, the hybrid strategy for Azure is extremely important.

Like we realize that customers, obviously, like many people want to adopt the cloud, but maybe due to compliance reasons or for whatever decisions, they want to also have some workloads on premise as well. And that doesn't mean that they should miss out on everything that the cloud has to offer. So we do have Service Fabric, I'll say, has three products. So we have the offering on Azure itself, where you can orchestrate your containers and your microservices, all the infrastructures hosted on Azure.

You can also get what is called service fabric standalone. So the entire platform downloaded in binaries and you can orchestrate that in your own hardware. So we have, and that's also available completely for free. So basically the technology that powers like millions of cores in Microsoft, that platform we're giving away to you to use in your own data centers and orchestrate your own containers and microservices and get all the benefits that you would normally get on Azure. And then the third, so I would say that's like the lowest level one where you own the hardware, you're in charge of the platform, microservices and everything.

If you're using service fabric on Azure, then you technically still own the hardware, but we're hosting it for you in our data centers. We actually have the physical servers, and you're just like paying for them. But then the third layer of abstraction is you don't even want to deal with hardware at all. You're primarily just focused on your application container. I have this code and I want it to just run somewhere. I really don't care about what kind of server it runs on. Making sure that it's

replicated across X number of servers, I want you guys to handle that for me. So that's like truly PaaS. And I'll use the buzzword, quote unquote, serverless. And that new product is called Service Fabric Mesh, where if you have a container or a number of containers, you can orchestrate that on Service Fabric without having to worry anything about managing infrastructure and nodes and whatnot. And one more question on this one. I know, Andy, I know you're itching to get into, but just because I know we have a lot, we know a lot of people who like to tinker, including ourselves. So if you were going to, if somebody wanted to play with a service

fabric on their own and download that piece, right, what would you say like the minimum requirements would be to run that, right? Because some things you can, some things people can take and tinker with and explore and learn other things like you know if you're going to try to play around with cloud foundry right you need like a whole mess of servers right so what is that footprint for just tinkering with maybe service fabric on-prem or even if you were spinning up your own in azure just to play with i'm glad you asked that. So our getting started kit, actually, you can download the Service Fabric runtime and SDK for, let's say, like.NET, for example. And what it does, it actually will create a local cluster on just like your laptop. So you'll see if you open up what we call the Service Fabric Explorer, which is our, it's kind of just like a management UI to see what's going on in all your nodes and your cluster. By the way, a cluster is just a fancy way of saying

a group of nodes. So through that, you'll like, you can just download that kit and only have your laptop and do deployments on your local Visual Studio, deploy them to your local cluster, and you can see each of your microservices landing on different nodes from within the cluster that's on your laptop. So the binaries that actually power that is a simplified version of Service Fabric standalone. Okay, cool. Yeah, go ahead, sorry. No, I wanted to go into it and finish your thought,

and then I have a thought and a follow-up question. I was going to say, all you really need to tinker and play around is just a laptop or some sort of computing device, and then be able to download the Service Fabric SDK in the runtime. Excuse me, I have a few more questions if you don't mind. Pretty cool. Hey, so I want to go into serverless in a second, but before we go into serverless,

because you mentioned that term, how do you normally license then? So if I am running on Service Fabric on Azure, what's the licensing model then? Because that's interesting to know, even though a lot of the stuff is is for free what's the licensing model yeah that's a good question as well um the only thing that you pay for with service fabric is the actual infrastructure itself so when you create a

cluster on azure um you get to choose what type of vm skew so how many how much cpu and how much memory you want your nodes to have. And each of those, like if you want a beefier VM, that's going to be more expensive, obviously. So that's the only thing that you're really paying for. You're just paying for the VMs themselves, the actual platform itself. And that experience is completely free. Cool. And is Service Fabric able, I mean, obviously, the Service Fabric take care of scaling my containers. If I run out of capacity, is there some automation where I can then just add additional hardware? Like, obviously, it's Azure hardware.

Is there an automation mechanism to scale it up? Yeah. The hardware that, or I would say like the IS service that Service service hyper groans on is called virtual machine scale sets and they're designed for this very purpose where you have many different virtual machines and you want them kind of all to be similar size and shape right and you might not know how many you want today or i mean maybe a week from now but you want to start out with a certain amount and if i get more, and more traffic into one, then I can definitely scale up. Um, usually we actually see customers scaling out, which is, which means creating more replicas of their microservices on the existing number of machines

that they have. But obviously, you know, that, that, um, isn't fully sustainable. You might get a lot of replicas running on a machine and your CPU is really running hot, then you actually have to either beef up that VM or maybe even get more VMs themselves. And before you move on, Andy, I wanted to ask on that one, with just like bare bones Kubernetes, you would say, I want to have five of these running, right?

And it's going to keep five running, but you can't without using additional plugins, right? And it's going to keep five running. But you can't without using additional plugins, at least as it's been explained to me. You can't say if my CPU gets over 80%, spin up another node. Is that kind of functionality, is the logic functionality built into service fabric so you can say if certain conditions are met,

scale up or scale vertically or whatever, horizontally? Yeah, the scaling out part is completely service fabric scale up or scale scale vertically or whatever horizontally yeah yeah the scaling out part is completely service fabric with the new increasing the number of replicas and then obviously the the VMSS technology is what we use to increase the number of VMs or increase the size of each VMD you have cool so now the the next you know I think interesting thing that he mentioned is serverless. So the way I understand it, the way you, I think, started explaining it is if I have a container, then I just give it to serverless i don't care about how on how many machines it's running you take care of that it is running and that it is accessible yeah yeah and that's exactly it um the word like serverless i believe was kind of first uh popularized with aws lambda functions

which are just very like smallets of code, very event driven. I believe that's actually what powers Alexa skills. And then Azure, we released something called Azure Functions, which is functions as a service as well. But if you really want to dig deep into the semantics, serverless just means you don't have any exposure to the actual services or servers themselves. So we actually saw Google, they announced a serverless Kubernetes like two weeks after Service Fabric Mesh was announced in public preview. And I think serverless, the word is being redefined into just no infrastructure, none of that management at all. But obviously, you can still code full, you know, large scale applications and host them in the cloud, but just not have anything to do with virtual machines. And that's again, to continue

on what you were saying, like that's that's exactly what service fabric mesh offers is as long as you can package your workload into containers, you can even describe how you want the containers to relate to one another. Like you want X number of containers for this application and this many as part of this microservice within the application. These ports open, these ones talking to one another. That's all available with Service Fabric Mesh.

And then what do I pay for? Do I pay for how long Service Fabric keeps these individual containers alive? Or do I pay per request that are handling and the time they take to execute? That's a great question. So I'll back up a bit and say, when we were just talking about Service Fabric on Azure, you're paying for the full VM itself.

So if you request a VM that has like five cores, let's say your workload is only using maybe one of those cores, then you're still going to end up paying for the entire VM itself. But with Service Fabric Mesh, you're actually only paying for what you use so when you deploy your application your containers you get to pre-define that i want my container to only use uh two cores and like half a gig of ram or something and that's all that you'll be billed for while your container is alive so in theory that container could be running on any size vm much larger beyond that but you're just saying this is this this is the requirements of it so that's what you pay for yeah absolutely we behind the scenes run really large clusters with tons of nodes lots of cores and it's a fully like multi tenant

environment so your stuff is right there Brian stuff is running right next to Andy stuff running right next to my stuff. And each of us might be on the same VM, but we're only paying for a fraction of that total VM cores, whatever our container is using. And then are you, Eastern Service Mesh, also taking care of shutting down containers completely? Let's say, you know, know in case there's really no load or do you always keep at least one instance of a container up and running yeah that so the the pattern that we've seen uh with customers so far is there's always going to be like maybe one instance of the container running like let's say you're running back to that e-commerce site example

during let's say your market is in the u.s so during like nighttime hours here uh not many people are probably going on your website so you might just only have one container up and running um or maybe a few but then during daytime or like during the weekend or something like more people are going on your site and that's when you um you'll scale out and you'll have more containers. You'll obviously be paying more because you'll be using more. But you can easily scale in and scale out just with simple CLI commands. And I always say the smaller you architect or the smaller you make your individual containers that host your different features, the better it is. Because that means the less resources it needs.

And then you can potentially at a very low traffic time, everything just scales down to a single instance of every single service. And then it's much more efficient than having a huge monolith lingering around and consuming megabytes of RAM. I will say that with service fabric mesh, we support only containers, but we do see that as a good lift and shift opportunity. So any customer that wants to embrace going to the cloud, let's say you want to go to the cloud because you're tired of hosting your own data center and dealing with servers and infrastructure and stuff. Then Service Fabric Mesh could actually be a great fit for you. As long as you can package your workloads into containers, you can give it to us and then we'll do everything under the hood to make sure it's running and that all the lights are on and et

cetera. Absolutely. Yeah, that's pretty cool. Um, now one, one topic that I want to touch base, you know, is open source. We know that, uh, open source is obviously a big topic in our industry today we know that you are microsoft is contributing a lot to open source how does this look like in the service fabric world is there i mean you know you give away a lot for free but is there any open source initiatives any partnerships that you guys have what's what's happening? That's a great question. So with Service Fabric for Azure, we open sourced the runtime code, I believe on, it was Pi Day earlier, so March 14th earlier this year for Linux.

And there's also like, there's a difference between open source and open development. So we were still doing work on our side for getting like the CICD pipeline and build system fully open source for Windows. But Service Fabric on Linux is open source. I heard a fun stat that it's the largest code base to be open source by Microsoft. Like the code base is even larger than.NET, which is pretty crazy. And in addition to us ourselves going open source, we were embracing partnerships with other open source companies and whatnot. And now one partnership we have in the mesh space is with

Envoy, which is a container, like, trafficking routing technology developed by Lyft, the ride sharing app. So that's the technology we'll be using under the hood to make sure that your containers and mesh are able to talk to one another. Yeah, Envoy just made it into Istio, right? It's part of Istio, too? I'm not sure.

Yeah, I believe so, yeah. so isn't that uh so i mean that makes a lot of sense but is this a little overlapping with some of the features that you guys already have uh uh is this then going to be complementary is it going to be replacing some of your core functionality so so we have a lot, obviously like a lot of built-in functionality, like I was saying. We, you know, there are a lot of things that to have a full production workload, you need to take care of CICD,

you need to take care of monitoring, security, et cetera. And we offer other Azure services and integrations with that. But not all customers, you know, might prefer to use Log analytics or visual studio team services, for example. So we don't want to discriminate or, you know, not, or lose customers just because of those things.

So we want to integrate with as many partners as we can. That's why we offer service fabric, like on-prem and Azure. Theoretically you can take the on-prem binaries and even host your host service fabric in AWS if you want on EC2 instances. Anything else? Did we miss to cover any aspects of service fabric? I think we have a good understanding

on obviously what service fabric is and how it came from, but anything we missed? No, I think we pretty much covered everything. It is, like, just, I want to reiterate, like, it's a platform that we want to make it available for anyone to use, like, regardless if you are more comfortable on-prem or hybrid or in Azure and other clouds. We obviously have integrations with Azure services,

but we're embracing partnerships with Envoy, even with Dynatrace for monitoring. Basically all these partnerships helps us increase our customer base as well. And that's really what we're going for. Maybe to round it up in the end, because you talked about our partnership and we always try to keep our podcasts product neutral from a Dynatrace perspective but it's still interesting to know what you do from a monitoring perspective.

So you mentioned in the beginning you are also responsible for the monitoring integrations and the partnerships that you have here. Is there, what's the value add that you see that vendors like Dynatrace bring to the table? What additional features and values do we provide on top of what you guys already provide? I would say that the, so the monitoring side of things in Azure is still a very like Windows, focusing Windows bias. So as we released Service Fabric Linux a year ago, by just doing that, we want to increase our presence in the open source and Linux world. And partnering with other companies like Dynaracer, making sure an Elk deployment, an El elk cluster works with service fabric um that really helps you know our other side is the linux side of story because we don't want to be just branded as uh windows only i would say like even azure is does not want to um have that image as well we

are it's microsoft azure now formerly known as windows azure um just like it's service fabric formerly known as windows fabric oh that's cool service fabric, formerly known as Windows Fabric. That's cool. Yeah, I mean, obviously, I think our big benefit that we always see with our customers is that we are multi-tech stack, multi-cloud, hybrid cloud, whatever you want to call it.

I think we see a lot of joint customers that leverage the fact that we provide insight into the current infrastructure, also then into the new infrastructure when they move over to Azure and then comparing it. And then still in times where they will end up with both, like a combination of still some on-premise, some in the cloud, having a single monitoring tool that gives them the full visibility across Windows, Linux, on-premise, off-premise, .NET or Node.js, whatever it is,

containers or not containers. So that's cool. And thanks for the partnership. I mean, it's really great that you help, you and your team now, obviously, with this podcast. But I also want to give a quick shout out to somebody else within Microsoft that we've been working closely with in the last couple of weeks. It is Donovan Brown's group, the DevOps guru and his colleague or his team. His league of the DevOps Superheroes.

And he and his team member, Abel Wang, they actually started implementing and have implemented what we call the unbreakable pipeline for VSTS. So the integration between VSTS and Dynatrace and then with this providing fully automated monitoring of everything you deploy with VSTS into Azure and automatically leveraging the data, monitoring data for quality gates, doing things like automatic rollbacks, scaling up, scaling down. So there's some cool things that we've been doing with Microsoft over the last couple of months and years. And to your point, again, Microsoft has been long seen as the windows company and uh but obviously you've you've definitely changed your public perception and you have uh you've shown this you know with us but also with everything you do out there in the community so that's that's really great to see yeah andy i was going to bring up donovan brown myself because the whole time uh we were having this discussion i kept on

thinking exactly what donovan said that this is not your parents microsoft right you know every time we talk to to microsoft i'm always so impressed with where the companies come but again for people who are just getting into the tech world they they don't know that history so much but for us all for us older timers it's's a fantastic transformation. Thank you, guys. That really means a lot. Cool. All right, Brian. Shall we summon the Summaryator?

Do it now. So what I found fascinating, and I didn't know this about Service Fabric, is that it's a service that came out of Microsoft that was actually used and is still used by large services within Microsoft has been battle tested. So it's not just a service that Microsoft sells to their customers just to fill a gap that they see with other cloud vendors. It seems, you know, obviously a great dedication towards containers, which is obviously where the world is moving towards. I also think it's great that you guys are providing

both in the cloud and on-premise offerings. Did you even provide the on-premise cluster software for free? So we would encourage and we'll provide the links on the podcast description to where people can find more information about Service Fabric, where they can download it. It's great as developers, if you want to play around with it, install it locally,

and then deploy into your local Service Fabric cluster. And where the world is heading towards, or where your world heads towards, it seems where everybody's heading towards serverless, where serverless is no longer the, the serverless was initially coined maybe by AWS Lambda, but it's really about, let's focus on writing services

and let's not worry about the servers anymore because this is a problem that has been solved and we should focus on building new services that are automatically scaled for us and we only pay as we go. And yeah, that's it from my side well thank you andy um the only thing i can say is uh uh i want to give a big thanks to sravan for coming on because i finally can wrap my head around service fabric now um i'm not going to say i could explain it

perfectly to anybody but i I have a much, much greater understanding of it. And it's all starting to come together. So really, really appreciate you coming on. I'm hoping our listeners really got a good understanding of it as well. So thank you very much. Any final thoughts that you have? No, I don't think so. I guess i'll say that yeah service fabric um you know we even though it is like a in between i as and paz product um we're primarily like application focused application development is um what our go-to is and we want our developers to make service fabric applications host their their applications, define them,

you know, with containers and use the microservices paradigm. And additionally, like we really believe that in maybe like two plus years time, like even though service fabric is an orchestrator and I've been preaching all about it during this episode in two plus years time, we really don't think people are going to care about or want to use orchestrators. That's why we're really betting big on serverless and service fabric mesh. We see that as the next step in cloud computing technologies,

more layers of abstraction. Right. And you know, Andy, I did have one last thought on this. If we go back two performs ago, when we were talking with Josh McKenty, right, there was the idea of we asked him, oh, what's internet 3.0? I think we asked, right? And he was like, I want to talk about internet 4.0, where I don't have to care or think about any of this stuff anymore. Right. I just going to deploy something and everything is done. Right. And we're seeing more and more and more and more. That's really the trend that we're seeing coming up, whether it's whether it's service fabric, whether it's, you know, a cloud foundry kind of thing. Or there's all these newer technologies are coming out so that people creating the applications or the services don't have to think about the underlying infrastructure anymore. It goes back to kind of a thought that I had with, you know, if we think about, well, yeah, I kind of put it in context of monitoring, right? Especially in terms of Dynatrace where when you used to go online, right, you'd have to make sure nobody was on the phone, make sure nobody, you know, your call waiting was disabled, open up your dial-up software,

get a connection and hope it didn't disconnect in the middle of you trying, you know, waiting a minute for that Monty Python script to download or whatever you'd be doing in the early days, right? Nowadays, we don't even think about connecting, right? That part is done automatically for us. And that's, I think, the trend that we're seeing in technology now is a lot of that stuff that we had to do in the past that we had to think about in the past is being done for us and now we just use the pieces that are important for what what our our real goal is uh and that's where i kind of see something like service fabric fitting into that whole um trend that we're seeing now yeah all right yeah that's that's technology yeah completely

all right well um anybody has any comments or questions you could tweet us at pure underscore dt um or you can send an email to pureperformance.dynatrace.com as always thank you andy for being here and being the voice of intelligence as to my counterpoint uh thank you very much for Ravan, for being on. We really appreciate you taking the time today. Of course. Thank you, Brian. Thank you, Andy, for having me.

This was awesome. Thank you. Bye-bye. Bye-bye.