PurePerformance - 039 101 Series: Azure

Episode Date: July 3, 2017

If you wonder what the top 3 ways are to pronounce Azure, then check out this episode. Also, if you want to learn more about what Azure really provides, why it used to be ahead of the curve, and why Microsoft had to re-invent it to provide services that software companies really needed, you won't want to miss this episode. Martin Gutenbrunner (@MartinGoodwell) gives us a good overview of the key Azure services and use cases that make Azure an interesting platform for many enterprises. It might also be surprising that it is not just a Microsoft-lock in Technology Stack. Besides .NET, there are many technologies that companies can use to run their applications on Azure IaaS, but more so on Azure Service Fabric. Listen in and learn the core fundamentals of Azure, why it might be interesting for you and what role monitoring plays.

It's time for Pure Performance! Get your stopwatches ready, it's time for Pureson again with pure performance and again we have andy grabner hello andy how are you today uh i'm good and i'm not sure what happened with you because your voice sounds a little odd and off what What happened to you since like an hour ago when we recorded the session with Daniel on Node.js? I don't know. I had, well, as I mentioned, I'm up here recording in the kitchen

and the benefit of recording in the kitchen is I found a lone single uneaten Swedish fish and I just had that before this episode. So maybe that impacted me already, the little sugar burst. Um, anyhow, yes, we have a, uh, another great one of our one-on-one shows today on a, well, our guest and I'll let you introduce him in a second. He's, he's a man of two names, right. And, um, we're going to talk about probably, I think there hasn't been a problem with pronouncing a technology since linux was invented right because this technology i've i call azure based on the color at least the

pronunciation over here i've heard azure i've had heard azure uh what else what other ways do people pronounce this one uh i think that might cover it but i'm sure i think they covered the top one what's the what's the show on tv where you have to guess the top most answers oh family feud family yeah that's kind of like what are the top most answers the pronunciations for azure uh and i think i think you covered the top three at least and and unfortunately you know i remember when linux came out and everyone was calling a linux i i had a installed an early version and there was a fun little recording uh from linus torvalds in there, and it was,

hello, my name is Linus Torvalds, and the proper pronunciation of Linux is Linux. And I was like, that's awesome. So I think any time someone opens an Azure account, there should be some kind of recording of whatever. I don't actually know what the official pronunciation is, but maybe our guest does. So why don't you go ahead and introduce our guest, Andy?

So our guest of honor today is Martin Guttenbrunner, or as you say, the man of two names, Martin Goodwell. And he can probably better explain why he has two names. Martin, are you there with us? I'm here. Hi, Brian. Hi, Andy. And I hope it's for no legal reasons, but go ahead. We just added him at the Witness Protection Program. Yeah. Hey, Martin. Martin, do you want to give us a quick, you know, explain who you are and maybe also lift the secret

of the correct pronunciation or the way you think it's correctly pronounced yeah so I'm I'm a technical guy I've been a software engineer for about 10 years did Java I did where but it's of the architecture and stuff and now I'm a dynatrace I'm at the innovation lab and I'm a liver compassion related things so work on Azure-related things, so try to see what's cool about Azure and how to get the most out of it. Yeah, I think Brian pretty much hits the top three ways. So about your names. My German name is Gutenbrunner,

and Goodwill is just the literal translation, the literal English translation. The reason I use it is that my German name was too long as the Twitter handle. I got three characters too long. So I just, you know, tinkered a bit and this is, yeah, what I got. It's like your showbiz name. It means you're set up to be more famous because you have a showbiz author, showbiz alias i should say

yeah i use it frequently oh so uh so talking about uh azure uh can you as you are at the tech league on tech lead on azure when it comes to the talent with innovation lab can you give us a quick overview of what azure or or Azure services are all about and kind of like a quick overview of people that may have never heard about it which I think is you know obviously it's hard to not hear about Azure when you talk about the cloud offerings out there but a quick overview of what what what it is what's provided and and why people are maybe looking into Azure and not into AWS or google cloud yeah it seems there's a resurgence of azure as well right it's um microsoft seems to be making a comeback and it

feels like azure might be leading that way so yeah so yeah azure is microsoft's cloud as you as you already said i think i'm not even sure when they launched it. Was it 2007 or 2009, something like that? And, yeah, I think everybody's aware that a cloud is just someone else's computer or someone else's server. So if you want to not have to maintain your own IT infrastructure, you usually decide for a cloud provider. And with that being said, Azure pretty much started out the same way

as I think AWS and Google Cloud Platform did. So you can run infrastructure as a service there, meaning you still have your virtual machines. You can run platform as a service there, meaning you still have your virtual machines. You can run platform as a service there, meaning you just deploy your application packages without needing to interact with the underlying operating system layer. And yeah, interesting fact is maybe how Azure started out. Microsoft probably thought, but that's just my guess, they should do something

different. So the cloud should be more than just lift and shift your stuff to hosted servers. So they really started out with the platform as a service idea. I think, I'm not sure whether AWS already had that concept at that time. So they started as a pretty much PaaS-based cloud provider. And PaaS-based, just for anybody listening, too, if you're familiar with Cloud Foundry, that's another example of a PaaS type of technology. So they were way ahead of the curve, it sounds like, as you're on that, right? Yeah, so exactly. It was called cloud service back then.

So those familiar with the terms web roles and worker roles, I think that was really the first offering you could use in Azure. And then it turned out that people, you know, from a mindset perspective were not there yet. So they weren't able to leverage, to really leverage on that. So they added that infrastructure as a service component, but they somehow built it on top of the PaaS thing. And so all of a sudden they decided that they had to start over. So what we have today with Azure Resource Manager is kind of Azure version 2 in all its glory. That's interesting.

So they were ahead of the curve, allowed developers, I guess, particularly to push their packages into their web roles or into their worker roles. And then I guess when people started to realize that the cloud is a real thing, but they were not ready for that, they said, let's start small and let's maybe do the lift and shift. And the lift and shift is typically infrastructure as a service. And they didn't have the offering and then they added the offering to it. Oh, that's interesting. I didn't know that. So to be honest, I don't know whether they were. so i think they were ahead of the curve from a mindset perspective they probably faced technical problems so they weren't able to to implement it on a technical side as they intended

it to that's my guess and i think maybe it might have been a lot of the supporting tooling might not have been as well developed um as it is now right to run those might have been a lot of the supporting tooling might not have been as well developed as it is now, right? To run those things, there's a lot of supporting tooling and interfaces that developers would really, that they have now that really allows them to embrace this idea. So yeah, could be a lot of issues. But Azure now has gone on to offer tons and tons of services, right? They're not only infrastructure as a service. They're not only infrastructure as a service, they're not only platform as a service now, right? But they're doing what container services, but even if we go to, and we'll put this site, this link up there just for anybody who's

curious, azureplatform.azurewebsites.net, right? Looking at the different things, right? Service fabric, load balancing, you know, under storage, networking, compute. I saw machine learning databases, right? There's security. There's tons and tons of services and components that they offer. So they're a whole different beast now, aren't they? Yeah, definitely. So I think this is kind of the Microsoft mindsets.

They try to provide the full gallery of things you might need. I think this is where there is a bit of a difference between Microsoft customers and other customers. So as I said, I come from an engineering background and this was always how I felt the difference between.NET and Java, for example. So as a Java developer, you were pretty much used to search the internet for your favorite library or library of choice. So if you wanted to do this, you started to Google around for what would be the best library for you to use..NET, on the other hand, has much more functionality built in from a framework perspective. So you find most common use cases you will find within the.NET framework. Plus, syntax itself is much more, there's much more syntactic sugar in it.

So, and I think this is also resembled here in Azure. Microsoft really provides or tries to provide everything. It's funny that you mentioned that because in a way, right, obviously besides the Java slash.NET debate, right, there's also the Microsoft-Apple debate. And typically on the hardware side, at least, or on PCs, right, Microsoft provided the OS and it was bring whatever peripherals and whatever drivers you want.

Whereas on the Mac side, they built you the entire laptop and gave you everything built into it. And it, it almost sounds like from the Azure side, uh, Microsoft is, is taking on more of that Apple model or even, even on.net it's, it's done that for a while too, right? Where everything was brought in for you and they're trying to give you that complete ecosystem out of the box, which is just, again, with these larger companies, they have different approaches to different parts of their business. So it's interesting to see that. So if we look at all these services, I mean, they obviously also remind me a lot of if you look at AWS, what they provide, storage, networking, compute. Based on what you have seen, what do people do when adopting or when moving towards Azure services?

What are the key big projects that you see that they do? Do they do still lift and shift and putting things into the Azure cloud using IaaS? Or are they now starting to build new apps on top of the Azure service stack? And if that's the case, what are they building? And what are they using? What are the main services that people use?

So I think everybody pretty much got it by now that just doing lift and shift to the cloud probably does not add up. So when you do the math, I think you discover quickly that running virtual machines in the cloud tends to become quite expensive pretty soon. So most people I talk to really got it that they need to re-architect or whatever.

But the most frequent use case I've come across so far the last two years is that people keep running their ecosystem as it is in their private data centers. So we're talking enterprise scale here. So they keep that in their private data centers and they move to the cloud for adding new services. And those new services are developed with a microservice mindset in mind. And they still have the VPN connection between cloud and on-premise. So the hybrid approach is really the most common one these days, I would say. And then the other thing I was quite surprised to learn was that, for example, Azure API management,

so your API gateway service kind of is also one of the most frequently used services. So this means no matter whether the service which finally handles your request is running in the cloud or in your private data center, the first point of contact for the client is always the API management service. So this means you have your mobile app or your website, you're doing that request, and the first spot it hits is in the cloud. And then it might be rerouted back to your private data center, but the first entry point is always the cloud. So this allows you to take advantage of always on, of resiliency, of being load balanced, things like that. And then you just easily distribute the traffic wherever it needs to go

public private wherever and i guess this obviously also allows you then to easily or more easily switch over once you decide to replace certain services that you have on premise right now and you're rebuilding some of this functionality new in the cloud then the only thing you need to do to enable that is just change your your api configuration and say from now on you know you are directing the traffic to this new service that happens to run in the azure cloud and no longer on the back end yeah exactly and also i think right i know you mentioned here and i was looking at before before, Azure Stack, right? So that's, if I understand it right, the ability to say you are running things within your own infrastructure.

If you want to keep it enterprise and keep it internal, you can deploy Azure, basically an on-prem private instance of Azure, and then you can still run things in the cloud and have that up. But is Azure Stack available yet, or is that still kind of under, in process? So it's currently in tech preview free, I think, tech preview stage three, right? It is expected to hit the market this year. So I expect it to be somewhere around mid-calendar, September maybe, something like that. And that's going to interest you. I was just going to say, this is kind of going into the, we just did a show on OpenStack, right? So this is a very similar concept,

at least from a higher level point of view, right, of running one of these services within your own data center. But you wanted to say something interesting, and I cut you off, so sorry. So, yeah. these services within your own data center but you you had an interest you wanted to say something interesting and i cut you off so sorry so yeah uh azure stack so you won't be able to install azure stack on your hardware so you cannot buy azure stack in a in the cardboard box coming on on five dvds something like this so you always uh you always uh have to uh get into agreement with one of the certified hardware vendors. So you really buy the server with Azure Stack on it, and then it will run in your data center, for example. But you have to buy the approved servers is what you're saying, and then bring them in. Yeah, so they will bring them in. And I think you do not even get root access to Azure Stack servers,

to Azure Stack Hardware, because Microsoft is really managing that for you. Okay. So OpenStack really can run on your five-node Intel NUC cluster just next to your desktop. This won't happen with Azure Stack Zone. You still can go for the tech preview download, which is available for free, but it's single-node only.

But yeah, you can run it on your own hardware, but be aware that you need pretty powerful stuff to run it on. And I did one time install Windows 2000 from FloppyDisk. I do want to go on the record and say that. So let's continue.

So besides the API management that you mentioned, what are the other big services that you always see that people are using and that we should talk about? So I think Azure App Services is the most commonly used service with the projects I came across. So App Services has come through some renaming the last few months, the last couple months or years even. So you might know it as Azure Websites, Azure Web apps, something like that. So currently it's called Azure App Services, and it's kind of an umbrella term for web apps, mobile apps, and API apps.

So the three of them are really the same thing, just three different names for them. Maybe to emphasize that you can not only run your front-end technology on Azure PaaS, you can also run your backend services on Azure PaaS. Yeah, so this is really the thing I see most these days. It makes perfect sense. Plus with service fabric, there is kind of the equivalent to Cloud Foundry or OpenShift coming from Microsoft.

As far as I know, Microsoft itself builds most of its offerings on top of Service Fabric. So Service Fabric is not only built for Microsoft's customers. They really heavily build their own stuff based on service fabric. So I think the majority of Azure compute consumption, which is done by Microsoft itself, is bound to service fabric instances, actually. So I think that gives you confidence that it's a good, it's a bulletproof technology. So I think we will see this coming much more often in the future. Besides that, yeah, all these storage services,

you know, Blobs, TableSkills, things like this, are also heavily used because many Azure services offer out-of-the-box integration. So you can choose to write system logs directly to an Azure storage account, things like this. So it's really easy to work with that. So going back to Service Fabric, though, to understand, what does Service Fabric really do for me? Is it rolling out my for me is it is it

rolling out my apps it's deploying it correctly is it scaling up scaling down is this what i understand what service fabric is yeah so yeah this is it pretty much so to start with you you deploy your your five node cluster you can even do this on your local machine or in AWS or wherever you want, or you can run it as a service on Azure. So you have your minimum five node cluster and you deploy all your application packages to Service Fabric. And then you can easily scale up and down. Service Fabric takes care of failover in case your one node fails, for example. You can even ship your regression tests with your applications. So when you do, Service Fabric will deploy your service to a single node only.

It will run the regression tests on that node. And if one of these tests fails, Service Fabric automatically rolls back that service to the last working version. And it did those regression tests in an isolated way, so all the traffic that was still coming in from clients was still routed to the previous version. And so you're pretty safe, so you might even say you can really test your stuff in production by leveraging that so that's and that's interesting so that's a feature

from service fabric which the way you describe it for me is something that you would normally do in your pipeline so you have a pipeline and you make a code change and then one phase of the pipeline is executing your your tests and then based on that decide whether you push it forward and but the way you described it's part of service fabric but then i would assume service fabric is tightly obviously integrated with microsoft visual studio team foundation services yeah so just that, but when you build your application on top of Service Fabric, you usually decide, you make a very important decision because Service Fabric also offers concepts like stateful services, stateless services.

So it takes care of persisting your data for you. So in your code, it just looks as if you were working with a dictionary object or a HashMap object or something like that. But it really automatically persists, scales whatever your data then. So you're really locked in. So it doesn't make it, if you use these features, I would say you decide to stay with service fabric for a long time, which doesn't need to be a bad thing necessarily. It's just something, again, it's that Microsoft mindset. So if you do something with the Microsoft product, you do not even need to look left and right because you have everything there that you might need. And I've tried it it it's really convenient so i've never seen something as as easy to use as seamless to use before

so but if i understand this again correctly if i'm a developer and i say i want to write an app that means in visual studio or in team foundation services i basically say i want to build a service fabric application and then i get the templates and then i basically just put in my code but basically what it really means when i then run it i can run it locally on on a local you know on some local deployed nodes or i can say hey service fabric now you know take it live and then service fabric really make sure to deploy it correctly in the cloud, does upscaling, downscaling. And wow, that's pretty cool.

Yeah, you do not. So it's not kind of staged. So you can push to your local, but you can also push to your public service fabric cluster. So I do not think that your local cluster can promote it to production. So this is still something you have to do. So it does not take that pipeline concept away from you. But of course, you can use it in a pipeline with multiple stages, no problem. And I think now might be a good time to mention that, yes, we are talking Azure.

Yes, we are talking Microsoft, right? But we're not talking specifically.NET, right? Azure is much more than, it's not just for.NET users, right? Exactly. It's not just for spinning up a Windows box or something, right? This covers pretty much everything. Yeah. So that's actually a pretty good question because also one thing from the early days of Azure was that it was called Windows Azure and not

Microsoft Azure. I think the reason for that was that Microsoft thought or they came to the conclusion that Windows was the much stronger brand, the much more well-recognized brand, as opposed to Microsoft. But this also led to the assumption that it was for Windows only, which is absolutely not true. So, of course, you can run your VMs in Azure, Windows and Linux, as we learned, but also all the PaaS offerings, so Service Fabric and App Services. You can deploy your JAR files there, your WAR files there. You can deploy Node.js. I think you can do Python. You can do PHP. So I think you can even

deploy self-running Go applications. So Microsoft really covers that microservice requirement landscape pretty well, I think. So you can run pretty much anything on Azure. Right, right. Andy, is it a good time to, I wanted to ask about Service Bus. Sure, go ahead. Because that's something that, unless you had something continuing from what we were talking before that you wanted to wrap into no no the only the only thing that i wanted to say so it seems service fabric is really this this you know obviously the way to go unless you just

use you know infrastructure as a service but if you build apps then then use service fabric which makes a lot of sense and uh the traditional web and worker roles that we used to have i think they were used to called azure cloud services is that a thing of from the thing from the past or is that still? something you do So, I think there is a lot of services running Built on that technology and I really doubt that they will ever deprecated it deprecated but

They really suggest you to move on to app services or even service fabric. So there won't be any new inventions in that field, plus cloud services won't be coming to Azure Stack, for example. So also maybe interesting side note, Azure has, I don't know, 30-plus regions around the globe. And every Azure region can be seen as kind of running its own version of Azure. So some Azure regions might offer more features than others, depending on the internal number of the Azure services running there.

And from a conceptual perspective, Azure Stack is absolutely the same. So Azure Stack can be regarded as just another Azure region. And cloud services is one of the offerings that won't ever be made available on Azure Stack. So while

not deprecated officially, I would say... A lot of people people running on there. Yeah, that makes sense. Yep. Yeah. So in terms of Service Bus, you know, I hear Service Bus all the time. I should say all the time, but quite a lot.

And I never, you know, had an opportunity to dive into it, but it seems like it's a very, very hot piece of a hot topic, you know, within there. Can you explain Service bus um i guess briefly or what is service bus and why do why is it a big buzzword so um when you when you're building microservice uh based environments or applications you need a means of having those services communicate with each other without knowing who the other one is. So you do not want to bind your services too tightly. So you need a central service, a central instance that takes care of managing that communication between services and this is what Service Bus is actually. So it has that queue concept

and some other things. So the website you mentioned earlier has Service Bus on it and it's a pretty good source to get a good overview of Service Bus, so what it is, what it does, what it costs you. So it's not for free. Yeah, but I think any project running on Azure is leveraging on Service Bus, so if you're planning to move to Azure, you should really take a look at Service Bus, definitely. And I guess the alternate, as you said,

would really be kind of more binding- oriented services yeah right yeah but but in truth this is not really an option so yeah interesting okay so if if i want to i would like to switch gears now i think we have learned at least i know now better that you know we are we are obviously building applications, or let's say it that way. We see, as you said earlier, API management is a key component that actually allows you to make the first step towards the cloud. Because with that, you can actually control load balancing, but you can actually also control once you are actually moving things for real to the cloud. And then the API management allows you to redirect the traffic. It seems i obviously with azure have the ability to do infrastructure as a service if i so want to do it but the more bigger thing is definitely building applications using service fabric and obviously then using all the

other services that support me with it storage and load balancing and all that stuff um now switching gears now what does this mean from a monitoring perspective? Because this is obviously a big topic for us. Are there any new use cases, concerns? What do people look at when they monitor Azure? Is there like an Azure core service monitoring where I get an overview of the services I consume? What are the typical use cases that we see out there? And also what might be the typical things that go wrong that people need to look out for?

So before I answer that, I need to add something. I previously mixed up a bit. So I said API gateway and now looking at that exact website so there is an application gateway and an API management so these are different services so the service I've been talking about this application gateway not API gateway and there is another thing which is API management so I I mixed up those two. I mixed them. So I made API gateway from application gateway and API management.

Sorry about that. Okay, but to answer your questions. So what is worth monitoring or different monitoring in Azure? So when you go the app service approach, I think it's important for you to know which instance size to pick. So when you decide for app services, you need to decide how many cores you will need, how much main memory your services will need. And this increases or decreases the price by a factor of two.

So, you know, one core with four gigabytes of RAM takes about half the money than two cores with seven gigabytes of RAM, for example. So while this is quite primitive, I think it's very important to see your applications running in production and to monitor the usage. So are they idling too much or are they under constant load? So you really need to know, you need to have a good feeling about those instance sizes. Besides that, I think it's not that different in Azure as opposed to any other environment you're running on. So when you're working on microservices, you really need to be aware of that lots of complexity has moved from inside single services to between services. So you need to be able to do call tracing.

You need to be able to do call tracing, you need to be able to correlate the problems. So, you know, the typical issue of one failing hardware instance or one failing service floods your inbox with like 57 error messages, alerts, because these were just the thread cells that were violated. So I think monitoring needs to align to that dynamic mindset. And also speaking of service fabric a couple of minutes ago, so service fabric takes care of a failure, for example. So if I have one failing node and service fabric is able to fix that problem on its own, maybe it will be nice to have some kind of information message that this has happened, but by no way I want to be woken up at 3 a.m. in the morning because of that problem that was automatically solved. So, yeah, monitoring needs to become much more flexible, much more aligned to that microservice mindset.

So it's not really an Azure mindset. It's really a microservice mindset. We need to go. Does Microsoft provide APIs or does it provide some built-in monitoring? For instance, the example that you just mentioned is perfect. Like does Service Fabric, does it give me an overview? Does it alert me or just send me at least informational messages in case it had to fix a problem that occurred?

Yes, so Service Fabric itself heavily uses event tracing for Windows, so that ETW framework. So you can read event tracing messages that are published by Service Fabric easily. I think there are code samples out there, just a dozen or a couple of dozen lines of codes subscribing to that event, and you will have all the information. You will know when some failover happened. You will know when something was not available, things like this. So, yeah, Service Fabric has this. And also Microsoft as a whole is trying to build that unified monitoring interface, service, whatever.

So it's called Azure Monitor. And Azure Monitor is designed to gather monitoring data from all other Azure services. So each Azure service has its own APIs for grabbing metrics and for integrating with monitoring. But with Azure Monitor, they want to have the single point of contact for you. So you do not need to find out how to connect to this service and how to connect to that service and things like this. So you really have that single stop, that one-stop shop Azure Monitor.

It is not complete so far. It probably will never be complete. So they are still adding services, and services themselves are also changing constantly. So, but this is definitely something to look at. That sounds interesting because I can imagine if you wanted to interface with all the APIs to pull in the data, right, you'd have to know all the ones that you have to interface with. It almost kind of sounds like this, what was it called?

What was this new API called? Monitor? Yeah, the unifying one that you mentioned, they had a name for it? Yeah, Azure Monitor is the project that tries to cover all of them. That almost seems like it would help you also discover, like let's say you were going in there to set up monitoring, it might help you also discover

what's all running in that system as well, just from that Azure point of view or from that API point of view, because it would take out the requirement of knowing we're using all these services, because it sounds like they would all just show up in there, right? So that's just like a great feature. It sounds like a great feature, though. Sounds a little similar to what AWS provides with CloudWatch, I guess, right? This is where you get all the overview of what's going on and collecting all this data.

There's also, so CloudWatch has its own standard of, not CloudWatch, AWS is providing you with that JSON format that allows you to define your infrastructure as code, right? I just forgot the name um azure has the same so with arm templates azure resource manager templates so you can define your your infrastructure in a json file and you can you can use management apis to to do that exactly the same. So what Brian just mentioned, so if you want to get an overview, a convenient overview of what's running in your Azure environment, you can take advantage of Azure management APIs. They provide kind of all these information for you. So which VMs, which app service instances,

which SQL databases, you name it. I think the equivalent you were looking for is probably AWS CloudFormation. Yes, exactly. That's where you can configure how your environment looks like and which components it actually includes. Yeah, and Azure has the same with this ARM concept.

So ARM is also the name of the new Azure architecture. And I think they really did a good job with this. So you can work with Azure on Azure Portal. So when you're more than mouse-driven administrator, operator, you can use Azure CLI, which is now in its second version. You can use PowerShell commandlets, and you can use REST APIs. And all of them interact with that ARM architecture inside Azure.

So multiple means of working with Azure, and it all boils down to a single point. So each of these solutions is equally powerful to solve your problems. So you can really pick out of three or four solutions what style you prefer most to manage your environment. Now, I know you've been the tech lead for Azure within Dynatrace Innovation Lab. You also told us that there's obviously built-in monitoring in Dynatrace.

They do a lot of stuff. It's also on the application monitoring. I think it's called the Application Insights. Then they have this project with the application or Azure Monitor. What have you seen out there where you have seen people that are adopting azure using azure but what comes with azure itself didn't cut it so what are the use cases from a monitoring perspective that are currently not covered out of the box which obviously allows then other vendors to to come up to fill these gaps yeah so. So App Insights, as you said, very much focuses on the developer.

So when you are a software engineer, you're starting to work on your solutions that are designed to run on Azure. You usually will put in your App Insights code into your application, giving you the ability to measure this, to measure that. So as a developer, I think you have a pretty good sense for what you want to know and what you have to measure. So App Insights is really great for this. Then there is, I think it's called OMS now,

which allows you to really manage your environment from an administrative perspective so this means what are the operating system patch levels on my windows and linux servers um are there security patches required where are the servers uh physically located um things like this so we are pretty good here on that front as well. From my perspective, what's missing is exactly what I said before, so that microservice mindset, you need to be automatically able to monitor additional instances of one service.

For example, you do not necessarily want to be informed when one node fails because the underlying service might very well be able to recover from that problem on its own. Plus, microservice is always in a pretty close connection with the DevOps thing, in my opinion, and probably not just my opinion. And this also means, so DevOps means everybody should be able to monitor that production system, to know what's going on in that production system. And when you look at that classic operator doing production monitoring you know being aware of is everything running smoothly right now I think app insights will not

cover all your needs because you you need to have kind of engineering backgrounds to to to modify it plus it is very much focused on single services and single instances. And on the other hand, OMS won't help you either because it's just, you know, displaying metrics and things like this. So allowing a non-software engineer to monitor a production environment, to know what's going on, to be able quickly to forward issues to the teams. I think this is what really

gives other vendors room to add value to Azure. That makes a lot of sense. I think what you said, one thing that you said earlier is really interesting. You know, the microservice mindset, the not being alerted when individual components fail, because I think what we need to figure out is how is monitoring different of resilient systems

than of static systems. And I believe this is the biggest thing we all need to understand. People that have been doing monitoring for a while, like we all have been doing monitoring for quite some time, but for me it was also a mental shift of instead of being able to look at the dashboard and define thresholds and being alerted if something is out of the norm and then get alerted. I think with building resilient systems, there's always something out of the norm.

And therefore, we need to have a different approach of monitoring. And you're right. We need to look at the service level, understanding is the service still operating as expected and what does this mean? And then only being alerted in case something is abnormal and across obviously all the systems that you've deployed whether it's on-premise but it's in the cloud or not that's interesting okay cool did you I remember I remember at earlier this year we had one of our larger customers in Denmark, Coop, presenting their Azure story. So they moved at least parts into Azure, where I believe what you actually brought, one of the use cases also is kind of innovating.

They were innovating through Azure, but then making calls back to the backend system, I believe, through that same API gateway. Any lessons learned there? Anything that we can share that they learned as an early adopter of Azure? Well, lessons learned, yeah, for sure. Lots of them. So, you know, when you deploy your service to Azure PaaS, in particular, your service is going to be moved after a couple of days for maybe no reason, for maybe any reason.

So I think what operators learn is the server is not important anymore. Just because you deploy to one server does not mean that your service necessarily runs on that very same server in three days' time, for example. So let loose of the host-centric view and more focus on the services and on the applications and let the underlying platform do the magic kind of thing. I think this is one of the major lessons learned.

And that basically comes back to we need to reshape our traditional thinking of monitoring. And yeah, because we are working with fluid underlying infrastructure. And the infrastructure in this case is managed

obviously by a third party, which is Microsoft. Cool. Anything else that we should cover from an Azure perspective? Is there any other terminology, any other key services that people should at least be familiar with that they should have heard because it constantly comes up, whether it is something around some special storages or i don't know containers is there anything that we should

at least mention well yeah so azure container services just because it's just containers um you you can run your tcos or your dockerarm or Kubernetes cluster on Azure as a service, so you do not even need to take care of setting it up. So it's really also as a service. Of course, you always have the option to set up your own virtual machines and then install whatever you want there. But, yeah, so containers are perfectly covered in Azure as well. So there should really be something for every taste, for every use case.

Okay, cool. I know, I think at least I know you are in Seattle right now at the MSBuild conference. What is it called? Exactly, Microsoft Build. It's going to take off tomorrow until Friday yeah yeah what is the what is the big thing there I assume it's a developer centric conference around team foundation services yeah any anything that you can tell us what's probably coming what's what's the big thing at this conference? So there will be some.NET Core, I guess. There will be definitely some Cortana.

There will be some HoloLens. Yes, I think artificial intelligence will be a big topic. Of course, Azure in any respect. Besides that, I can't wait to learn more. Do you think they might announce that Azure will be offering Microsoft Bob as a service? Sorry, never heard about that. It's a good look at Microsoft Bob when you get a chance. Basically, I think it was between 98 and ME.

I remember when 98 had all those themes. Those all came out of, or ME, I forget what it was. That all came out of Microsoft Bob. It was supposed to be, I think Melinda Gates actually, it might have been her project, but anyway, correct me if I'm wrong. It was basically, it's kind of like the the running joke within microsoft operating systems yeah was it that that alternate desktop that looked like a living room or an office or something yeah those all came that all came out of it it was supposed to be like yeah a super friendly bit but yeah there's a lot

of i wasn't sure we were talking about when this millennium era is today. So maybe that'll be the big announcement. Anyhow, anything else on this? I mean, I think it's, you know, as opposed to some of the other 101 conversations that we're having, like when we were talking OpenStack, how there is a, you know, you can bring all of it in-house and you can monitor everything from the root cause. And I think with Azure stack, you might eventually get to that point, right? Where you're monitoring the health of the Azure, let's say for lack of a better word,

the Azure operating internals underneath everything, once you have it inside, that might be something to do down the pipe. But otherwise, in its current state, it's really, yes, you're monitoring your full stack, same as always, but since you're running it in this way, you have to have a new approach. You can't be monitoring all these microservices and distributed components and your fabrics and your service buses and all this, you can't be monitoring that in the same old fashioned way, getting alerts like crazy. So it's not like there's anything core different. It's the mindset different, which applies to any other microservices based architecture. But it'd be interesting to see what goes on once the Azure Stack starts coming in-house, if there's the ability to start monitoring that with something like OpenStack.

So a last word for our listeners. In case people want to find out more about maybe some use cases or what we as Dynatrace have to offer particularly for azure what's the best way to get more information so i would try to go to dynatrace.com i'm not really sure if there is something there but i would expect so but so yeah um the website so we are currently revamping, we're adding content constantly. So the website is one very good thing, one very good spot to visit, plus the blog and, of course, the Twitter feed. So anything new should be there soon. Cool.

Yeah, especially the blog is great because the product team on the one side is pushing a lot of product news every time when we make updates there's something coming out and then obviously you know our team is blogging about use cases on blog.dynatrace.com as well so that's cool all right i think that's that's it for my side i learned if i can play the summer later again, I learned that Azure went through different, at least like two iterations, right? They may have been a little bit ahead of the curve in the beginning when they tried to bet on pass only, realized that IaaS, infrastructure as a service, is actually the first wave of cloud migrations. Then they basically revamped Azure. And now it seems what I have learned, at least from you, I can obviously use infrastructure as a service. But the key thing that people are probably going to do is building new cloud native apps, microservice apps, probably through service fabric, consuming a lot of the services that

Microsoft provides as well, whether it's storage service or, I mean, the services that microsoft provides as well whether it's storage service or i mean the list is the list is endless it seems if you look at the overview and the api gateway is a great way to get started because it allows application gateway thank you the application gateway allows you to really get started with this because it gives you the load balancing and the failover and then you can gradually switch or bring in certain features that are then no longer coming from your on-premise solution but from from the cloud and it seems this is a great way to go and then also as we said mind shift or mindset shift in the way we monitor. It's about services and no longer about just static resources.

And that's a big thing that I learned. Well, thank you, Martin. Martin of many names. Is that your third name? Martin of many names. That could be your Dungeons & Dragons name or something. Yeah. Thank you very, very, very much for doing this today. I definitely learned a lot, and I hope our listeners learned a lot, too.

I think it's great that there's out there. There's so many great platforms, and the things we're covering in these 101 sessions, I think, really just show the robustness of offerings that are out there now. It's kind of an exciting time. And hopefully this is all somewhat friendly competition between the different companies offering these services, because there's a lot of choices with slightly different components in their offerings that everyone has to choose from. And I think there's a lot of great stuff coming out from all of this. So hopefully this will bring everybody to better products

and much better pipelines and just getting where everybody wants to help. It'll help everybody get to where they want to be, basically, is what I'm having a hard time getting out there. So I'm excited about this, and thank you for sharing this information about Azure because there's definitely so much more to Azure than people might conceive just because of the bias of,

oh, it's Microsoft, it's got to be Windows and.NET stuff, right? Right. Awesome. Thanks a lot. Thank you. Thank you. Yeah, any questions, comments, feedbacks, reach us at pureperformance at dynatrace.com or pure underscore DT.

Martin, you have some blogs and stuff I imagine we can post links to. And are you a tweeter? Yes, at Martin Goodwill. There you go. See, that's where that last name comes in handy. Thank you very much, Martin. Have a good time in San Fran. Goodbye.

Bye. Bye.