Aug. 19, 2025

Episode 430: Exploring Business Central: Online vs. On-Premises

Episode 430: Exploring Business Central: Online vs. On-Premises
Apple Podcasts podcast player icon Spotify podcast player icon Youtube Music podcast player icon RSS Feed podcast player icon Amazon Music podcast player icon Audible podcast player icon YouTube podcast player icon
Apple Podcasts podcast player icon Spotify podcast player icon Youtube Music podcast player icon RSS Feed podcast player icon Amazon Music podcast player icon Audible podcast player icon YouTube podcast player icon
Season 4 Business Central Partner

Are you considering Microsoft Dynamics 365 Business Central as your ERP software, or are you considering an upgrade to your version of Microsoft Dynamics NAV?

 

In this insightful discussion, host Krs Ruyeras and Brad Prendergast welcome two distinguished Microsoft MVPs, Duilio Tacconi and Alexander Drogin, to discuss the key differentiators between  Business Central Online and On-Premises. They explore licensing, infrastructure, performance, and security considerations, offering valuable perspectives for businesses deciding between these two platforms. The conversation buzzes with the benefits of cloud flexibility and the challenges of managing on-premises setups, delivering a fun, clear, and inspiring guide to making informed choices that’ll spark ideas and fuel confident decisions.

Send us a text

Support the show

#MSDyn365BC #BusinessCentral #BC #DynamicsCorner

Follow Kris and Brad for more content:
https://matalino.io/bio
https://bprendergast.bio.link/

00:00 - Podcast Introduction and Guests

06:15 - Licensing Differences and Infrastructure Requirements

15:18 - Integration with Azure Services and AI

21:58 - Performance Considerations and Scalability

36:30 - Update Process and Maintenance

01:08:30 - Security, Compliance, and Data Access

01:16:13 - Closing Remarks and Contact Information

WEBVTT

00:00:00.620 --> 00:00:04.091
Welcome everyone to another episode of Dynamics Corner.

00:00:04.091 --> 00:00:10.612
Is it faster if I run on a treadmill inside my house versus running outside?

00:00:10.612 --> 00:00:12.346
I'm your co-host, chris.

00:00:13.801 --> 00:00:14.461
And this is Brad.

00:00:14.461 --> 00:00:18.050
This episode was recorded on August 7th 2025.

00:00:18.050 --> 00:00:20.923
Chris, Chris, Chris, Is it faster?

00:00:20.923 --> 00:00:23.109
I think it's a matter of how fast you're running.

00:00:24.161 --> 00:00:30.089
Well, it depends the environment too, right, like if you're inside on a treadmill, it's consistent.

00:00:30.089 --> 00:00:37.670
Maybe outside you get the environment, you get the asphalt, maybe some trail.

00:00:37.691 --> 00:00:39.713
Some elevation.

00:00:40.621 --> 00:00:41.618
I see what you're saying.

00:00:42.601 --> 00:00:57.185
And just like the environment may impact your choice on where you're going to run, you also have choices when you're using Business Central to run Business Central Online or Business Central On-Premise With us today we had the opportunity to talk about some of the differences between those two.

00:00:57.185 --> 00:00:59.250
We had some two amazing guests.

00:00:59.250 --> 00:01:00.621
We had Alexander andilio.

00:01:17.221 --> 00:01:20.048
Arrivederci, hello, hello, good morning.

00:01:20.188 --> 00:01:21.650
Hello, hello Hello hello.

00:01:21.650 --> 00:01:22.091
How are you?

00:01:22.091 --> 00:01:25.061
How are?

00:01:25.542 --> 00:01:26.123
you doing, sir?

00:01:26.123 --> 00:01:26.543
Yeah, all good.

00:01:26.543 --> 00:01:27.504
How's Santa?

00:01:27.504 --> 00:01:28.807
Can you hear me all well?

00:01:29.768 --> 00:01:32.251
We hear you well, I hear you well.

00:01:32.251 --> 00:01:33.194
It's always good to hear you.

00:01:33.194 --> 00:01:40.263
We're waiting for the real Italian stallion over here.

00:01:40.263 --> 00:01:48.459
It's a pleasure, it's an honor to speak to the real Italian stallion and Mr Alexander, do you know, to the real Italian stallion?

00:01:48.459 --> 00:01:52.405
And, mr Alexander, do you know where the real Italian stallion comes from.

00:01:52.405 --> 00:01:54.688
Nope, no, alexander, do you know?

00:01:55.850 --> 00:01:56.591
Sorry, do I know what?

00:01:57.332 --> 00:01:58.454
The real Italian stallion.

00:01:59.176 --> 00:02:00.037
Is it Rocky?

00:02:00.037 --> 00:02:02.566
Rocky Balboa?

00:02:02.566 --> 00:02:02.688
It is.

00:02:02.707 --> 00:02:03.093
Rocky.

00:02:03.114 --> 00:02:03.397
Balboa.

00:02:06.531 --> 00:02:09.896
So that's where the real Italian stallion comes from you're the real.

00:02:09.896 --> 00:02:11.405
Italian stallion, not Rocky Balboa.

00:02:12.651 --> 00:02:18.009
I'm honored of this title well, I say it to you all the time.

00:02:18.009 --> 00:02:23.795
Now, I didn't think you picked it up, or if anybody knew, but that's what it is.

00:02:23.795 --> 00:02:27.008
So, no, that's good.

00:02:27.008 --> 00:02:29.710
We appreciate you both taking the time to speak with us today.

00:02:29.710 --> 00:02:38.432
I've been looking forward to this conversation for a long time, because I have this question asked to me often.

00:02:38.432 --> 00:02:41.527
When I say often, it's probably almost daily.

00:02:41.527 --> 00:02:44.027
Now I don't want to say almost daily, but it's several times a week.

00:02:44.027 --> 00:02:55.433
You know what that question is what is the difference between business central online and business central on-premises?

00:02:55.433 --> 00:03:00.591
And we couldn't think of two others.

00:03:00.591 --> 00:03:07.242
Well, we could think of two others that would be able to help us answer that question, besides the two of you.

00:03:07.242 --> 00:03:11.673
So you're on the spot now, both of you.

00:03:14.902 --> 00:03:16.288
I let Alexander start.

00:03:18.562 --> 00:03:22.009
But before we get into that, I do have some questions on it.

00:03:22.009 --> 00:03:24.973
And before we get into that, would you mind telling us a little bit about yourself, Alexander?

00:03:24.973 --> 00:03:25.014
I?

00:03:26.153 --> 00:03:27.775
do have some questions on it.

00:03:27.775 --> 00:03:30.876
And before we get into that, would you mind telling us a little bit about yourself, alexander?

00:03:30.876 --> 00:03:31.156
Yeah, I'll try.

00:03:31.156 --> 00:03:35.858
First of all, good evening, good afternoon, it's good morning for you, and thank you for having me in this podcast.

00:03:35.858 --> 00:03:37.079
I'm really happy to be here.

00:03:37.079 --> 00:03:41.572
Well, a little bit about me.

00:03:41.572 --> 00:03:45.316
Well, you know me as a business central developer.

00:03:45.316 --> 00:03:48.423
Yeah, I started in this area well, pretty long time ago.

00:03:48.423 --> 00:03:56.405
It was over 20 years now, uh, when business center was still called navision attain and it wasn't even microsoft.

00:03:56.405 --> 00:04:05.731
And since that, all time, since that time I'm still working with, with navision dynamics, nav, bc, whatever it's called.

00:04:05.731 --> 00:04:07.361
Well, I start.

00:04:07.361 --> 00:04:14.143
I've been so in different capabilities, let's say, worked at an end client in consulting.

00:04:14.143 --> 00:04:20.262
For a while we even worked with duilio together providing support for partners at microsoft.

00:04:20.262 --> 00:04:32.307
Although duido was on the front line, I was hiding behind and the development team actually fixing those bugs that made it through the first line support.

00:04:34.081 --> 00:04:37.130
It's good to be behind the front lines, to be hidden in the back.

00:04:37.800 --> 00:04:44.863
I never envy those who are in the front actually dealing with partners and clients, so Duilio was the hero.

00:04:46.649 --> 00:04:48.033
No no.

00:04:50.261 --> 00:04:51.983
Maybe you were fixing your own bugs?

00:04:52.324 --> 00:04:52.925
I don't know.

00:04:57.040 --> 00:04:58.285
That's a shot from the front line.

00:04:58.285 --> 00:04:58.726
That was good.

00:04:58.726 --> 00:04:59.249
I like that.

00:05:02.060 --> 00:05:04.112
It was 15 years ago, probably 15 years Long.

00:05:04.112 --> 00:05:09.608
Probably 15 years Long, long time ago, in another galaxy.

00:05:12.043 --> 00:05:15.848
Time goes so quick it feels like it moves fast.

00:05:15.848 --> 00:05:17.728
Twilio, would you mind telling us a little bit about yourself?

00:05:19.341 --> 00:05:20.908
Yeah, I'm Twilio Tacconi.

00:05:20.908 --> 00:05:32.653
I used to work in Microsoft like Alexander for more than 15 years and then I moved to a partner site, and in a partner site I'm more on the performance side.

00:05:32.653 --> 00:05:47.875
I don't want to define myself as a developer, I do not pretend to, but I'm just analyzing, through telemetry and other sources, depending on if you are on-premises or online, what is actually the output of the code.

00:05:47.875 --> 00:06:03.567
So this kind of question on-prem or online it is something that I have in my heart, in my soul actually, and I'm just taking and tackling this every day in a different way from the specific area that I'm working on.

00:06:03.567 --> 00:06:04.310
Yeah, that's good, that's good.

00:06:04.329 --> 00:06:06.237
Thank area that I'm working on.

00:06:06.237 --> 00:06:07.279
Yeah, that's good, that's good.

00:06:07.279 --> 00:06:08.745
Thank you both again for being on.

00:06:08.745 --> 00:06:14.560
Thank you both for all that you do for the community and for everyone using Business Central.

00:06:14.560 --> 00:06:32.367
So, to go back to it, it is a question because when a customer has an implementation, or if they're looking at a new implementation, or if they're looking to upgrade, they are presented with Business Central Online and Business Central On-Premises from some partners and as well as the literature they can read.

00:06:32.367 --> 00:06:39.870
But along with the question of what's the difference, you know, the first question is well, which one should I use?

00:06:39.870 --> 00:06:51.216
But in order to make the decision on which one you should use, I think it's important to know what the differences are and maybe why someone would use Business Central Online versus on-premises or vice versa.

00:06:51.216 --> 00:06:56.331
So, with that, what do you guys think?

00:06:56.331 --> 00:06:58.247
What would you say are the differences?

00:06:58.939 --> 00:07:00.264
Would that make a difference, though, brad?

00:07:00.264 --> 00:07:10.192
If it's going to be from a business aspect, would you consider the cost as well, on top of long-term maintenance, on top of the technical?

00:07:10.901 --> 00:07:12.026
This, is what I'm looking for.

00:07:12.026 --> 00:07:18.338
It's what are the differences between business central online and business central on-premises?

00:07:18.338 --> 00:07:21.168
And then that's always the other day.

00:07:21.168 --> 00:07:22.466
Do you say on-premise or on-premises?

00:07:22.466 --> 00:07:22.901
Did you know?

00:07:22.901 --> 00:07:27.047
A lot of people talk about that, by the way, and then some just say, yes, you say on-premise or on-premises?

00:07:27.047 --> 00:07:27.343
Did you know?

00:07:27.343 --> 00:07:30.233
A lot of people talk about that, by the way, and then some just say yes, it's on-premise, and then some just cut it short and say on-prem to avoid it.

00:07:30.233 --> 00:07:32.740
But no, there are many differences.

00:07:32.740 --> 00:07:36.331
So, mr Duilio and Alexander, what do you think?

00:07:36.331 --> 00:07:40.031
What are some of the big differences between Business Central Online and on-premises?

00:07:49.279 --> 00:07:53.879
Well, if Duilu, let me start, I would say well, we can look from very different points of view.

00:07:53.879 --> 00:08:01.983
Maybe we can think first, like Christopher suggested, from a business perspective, from development, maintenance costs and so on.

00:08:01.983 --> 00:08:18.016
But I think the most important aspect right now, first of all, that if a new customer comes to you and asks if I should use on-prem or SaaS, the first thing to consider is that they can't buy an on-premise license anymore.

00:08:18.016 --> 00:08:30.240
So I think the question is solved basically oh okay, yeah, basically oh, okay yeah, so so we're done.

00:08:30.422 --> 00:08:31.939
We're done with the conversation.

00:08:32.964 --> 00:08:34.008
Yeah that's the biggest difference.

00:08:34.008 --> 00:08:42.966
I believe it's Microsoft like incentive they want clients to use to be in SaaS.

00:08:42.966 --> 00:08:48.551
So there is no new licenses on-premise.

00:08:49.774 --> 00:08:49.974
Okay.

00:08:49.974 --> 00:09:13.787
So for those that are using the existing versions and they want to move to Business Central Online, there's still some differences from those using Business Central on-premise and Business Central Online to maybe make the move to Business Central online if they're on-premise or vice versa, if they have the licenses in place or if they do have licensing for it as well.

00:09:13.787 --> 00:09:39.354
So we talked about there is a license required for Business Central on-prem, so you are required to buy licenses if you're using Business Central Online, but those are the user license and the user levels, whereas Business Central On-Prem, you're required to have the user license, the application license and any licenses that you need for extensions as well.

00:09:39.354 --> 00:09:43.966
So what else, mr Dweller, do you have something big?

00:09:59.008 --> 00:10:02.129
I know you have a lot in there, all the infrastructure behind the scene.

00:10:02.129 --> 00:10:12.195
But if you want to go in the on-prem then you have to pay for the license, plus you have to create your own infrastructure, maintain your own infrastructure.

00:10:12.195 --> 00:10:16.076
Those are the two main point in here.

00:10:16.076 --> 00:10:23.626
So the same license, but then if you want to go into on-premise, then you have to take care also of what is running behind the scene.

00:10:23.626 --> 00:10:25.480
Then you have to purchase your license of what is running behind the scene.

00:10:25.480 --> 00:10:28.783
Then you have to purchase your license for the SQL server and for the SQL server.

00:10:28.783 --> 00:10:38.605
Then you have to purchase the license for your Windows server and then you just have to purchase your own SAN for the disks in order to make it perform, and so on and so forth.

00:10:38.720 --> 00:10:41.067
And this is just for the infrastructure per se.

00:10:41.067 --> 00:10:43.384
And then you have to maintain the infrastructures.

00:10:43.384 --> 00:10:48.926
I mean that once you have deployed everything, even the deployments, you have to do this by your own.

00:10:48.926 --> 00:11:06.730
Once the deployment has been done, then you just have to schedule your own maintenance for the SQL Server re-indexing, update of the statistics, all the jobs that you want behind the scene, everything that is upon you, including the typical maintenance that you have behind the scene.

00:11:06.730 --> 00:11:15.067
Everything it is upon you, including the typical maintenance that you have to do on the SQL server and on the Windows server, from a security perspective or using a patching strategy.

00:11:15.067 --> 00:11:26.653
All of the things that I told you has been performed and done by Microsoft under the umbrella of the Dynamics 365 Business Central online version.

00:11:26.653 --> 00:11:30.009
So this is one of the two big differences.

00:11:30.860 --> 00:11:38.875
Don't you have to do the IIS and web services and SSL and DNS, all of that right.

00:11:39.580 --> 00:11:43.327
Yeah right, completely completely.

00:11:43.327 --> 00:11:56.847
And then you have to take care of everything, even if your infrastructure because this is part of your infrastructure even if your infrastructure might have some problem with security, then you have to do penetration tests.

00:11:56.847 --> 00:12:02.928
This is what Microsoft also does by itself in order to see okay, is my online version secure enough?

00:12:02.928 --> 00:12:15.910
And if it's not secure enough, then they will add much more security substrate, software substrate or controls or whatever it is, and it is continuing evolving, upgrading, updating.

00:12:15.910 --> 00:12:17.245
That is one thing.

00:12:19.643 --> 00:12:21.208
That sounds like a big one.

00:12:21.208 --> 00:12:23.706
We're starting off pretty big with a big difference.

00:12:23.706 --> 00:12:30.892
So one of the differences with online, you don't have to be concerned with the infrastructure.

00:12:30.892 --> 00:12:38.690
With on-prem, you have to be concerned with the infrastructure and again, someone may need to use it and they may have an infrastructure.

00:12:38.690 --> 00:12:44.186
But when I think of maintaining infrastructure, you also have to have the individuals to maintain the infrastructure.

00:12:44.186 --> 00:12:52.960
So that's what just came to me when were saying that, as you're thinking of, all that you have to work with is somebody needs, there's a person that needs to do all this not just the licensing.

00:12:54.043 --> 00:12:58.154
Yes, yes, just not the licensing for it as well, which is quite um.

00:12:58.154 --> 00:13:03.091
It's interesting now that you put it in that that light, wow, uh.

00:13:03.091 --> 00:13:04.436
What are some other differences?

00:13:04.436 --> 00:13:06.845
Are there any differences within the application?

00:13:06.845 --> 00:13:08.009
We talked about the licensing.

00:13:08.009 --> 00:13:25.245
That's a difference and, as I alluded to, I know one thing I'll throw in there is if you create extensions ptes for yourself, or if you have somebody do them for you, then you need to also pay for the objects, like they used to in the old days, I guess, but we all have been working with it for a long time.

00:13:25.245 --> 00:13:35.369
Someone new may not understand, but the extensions that you create are also required to pay for those objects as well, for those extensions that you use, correct?

00:13:36.309 --> 00:13:41.664
yes, that's right yeah, and if you're online it's not necessary to use those.

00:13:41.664 --> 00:13:48.927
So with that geez, we'll go there, we'll keep going, keep going.

00:13:48.927 --> 00:13:51.690
So what are some other differences that stand out?

00:13:51.690 --> 00:13:52.241
Is there anything?

00:13:52.241 --> 00:14:00.749
From the application point of view, the platform is a big one, or, like you said, the behind the scenes, the infrastructure is a big one.

00:14:01.340 --> 00:14:04.009
AI out of the box is one thing actually.

00:14:04.009 --> 00:14:06.631
All the AI feature the one of the box is one thing actually.

00:14:06.631 --> 00:14:17.931
All the AI features the one with the artificial intelligence that are in the online version, all of those ones are going with under the umbrella of the online version.

00:14:17.931 --> 00:14:22.048
Those ones are not available to be used on the on-premise.

00:14:22.048 --> 00:14:31.032
In the on-premise you still can, but you have to provide your own development and then connect to your own AI spots and so on.

00:14:32.461 --> 00:14:40.889
And, if I may add, it's not only about AI, it's basically any Azure services, because we can't talk about Business Central right now.

00:14:40.889 --> 00:14:47.846
Another big thing at Business Central when we talk about Business Central on-premise, it's kind of a standalone application.

00:14:47.846 --> 00:14:49.339
So we install it, we use it.

00:14:49.339 --> 00:14:57.029
Now, what different like why Business Central has become Business Central and was not Norwegian anymore?

00:14:57.029 --> 00:15:01.947
Because it's a different kind of application, because it's part of a bigger ecosystem.

00:15:01.947 --> 00:15:15.883
All the whole Azure infrastructure and we have easy integration, simple integrations, with lots of Azure services out of the box, practically when they're online it can be done.

00:15:15.883 --> 00:15:31.750
Yes, it can be done on-premise as well, but involves more of those qualified people who can set it up, who know how to do it, more penetration testing, more security concerns when they integrate on-premise network with Azure.

00:15:31.750 --> 00:15:37.908
So Business Central Online comes with many benefits of those Azure services.

00:15:38.639 --> 00:15:42.886
Okay, so Business Central Online, you can have access to Azure services.

00:15:42.886 --> 00:15:45.681
Dulee mentioned AI On-prem.

00:15:45.681 --> 00:15:46.447
You can have access to Azure services.

00:15:46.447 --> 00:15:47.013
Julie mentioned AI On-prem.

00:15:47.013 --> 00:15:57.570
You can have access to those services, but it requires someone to do some sort of development, whether you purchase something to do it or if you hire someone to do the development.

00:15:57.570 --> 00:16:04.931
What are some of the other features of the Azure services that are within Business Central that differentiate between on-prem and online?

00:16:06.626 --> 00:16:09.580
I can think of blob storage, file storage access that are within Business Central, that differentiate between on-prem and online.

00:16:09.580 --> 00:16:16.014
I can think of blob storage, file storage access, for example, if we want to use any storage online.

00:16:16.014 --> 00:16:37.642
Well, when it comes to integrations, especially when it's integrations, we can use all the rich tool tool set that azure can offer like uh, uh, as your, as you use um yeah, basically it is.

00:16:39.284 --> 00:16:41.528
I talk about ai, an agent.

00:16:41.528 --> 00:16:43.373
Uh, those are all services.

00:16:43.373 --> 00:16:43.813
This one.

00:16:43.813 --> 00:16:53.389
Some of them come out of the box natively and those are only available out of the box in the online version and not in the on-prem.

00:16:53.389 --> 00:17:01.328
But it's not that, because in the on-prem you cannot have it, but you just have to develop this your own and this is adding extra cost to the solution.

00:17:01.328 --> 00:17:12.119
This one it is already there and maintained by Microsoft so that it is covering correctly all the standard of development, deployment, security and so on and so forth.

00:17:12.200 --> 00:17:16.652
This is the good part of the online version.

00:17:16.652 --> 00:17:17.805
There are many, many goodies.

00:17:17.805 --> 00:17:20.166
Other kind of integration out of the box.

00:17:20.166 --> 00:17:30.969
It is with Teams, and even with Teams you can use it and you can even bundle this with Teams and even with Teams you can use it and you can even bundle this to Teams.

00:17:30.969 --> 00:17:36.635
Well, here in Italy, I think, also for the dimension of the companies, then we don't have that much integration with Microsoft Teams.

00:17:36.635 --> 00:17:44.138
But this is just another goodies, another things that has been added.

00:17:44.138 --> 00:18:20.223
And if you go to BC Learn and then you see what are the things that are available for the on-premise and for the online version, you have not a long list, but a medium list of the things that are not available in the on-premises, Even something also related to the connection between power platform the online version, born with native connection also with the Power Platform, or the Power thingy, with the Power BI and Power Apps and everything that you have with the power in front of it.

00:18:20.223 --> 00:18:25.307
It will be much more easier within the online version compared to the on-premises.

00:18:26.061 --> 00:18:27.567
And we need to turn CRM to the left.

00:18:28.901 --> 00:18:30.465
The R365 as well.

00:18:31.048 --> 00:18:32.301
Yeah, so a lot of that.

00:18:32.301 --> 00:18:34.690
Technical additional requirements, right?

00:18:34.690 --> 00:18:43.127
I think you need gateways installed locally in your application server or somewhere in your network and someone has to maintain that as well.

00:18:43.700 --> 00:18:43.961
Okay.

00:18:43.961 --> 00:18:57.741
So if someone's looking to use ai with business central, I know they keep at the microsoft keeps adding features and functionality, like now, as you mentioned, the agents, sales, sales order agent, payables, agent, and they have other co-pilot summary now they have.

00:18:58.643 --> 00:19:15.913
I'm still waiting for that autofill to work, but we'll see uh I'm hoping, I'm waiting, I keep trying, every, every, every release I try to see if I can get that to to fill something from outside, uh for an address or something to see.

00:19:16.500 --> 00:19:28.041
So if you're looking to have any integrations, it's not to say that you can't do it with on-premise, it's just a little bit more effort, uh, to connect to any of the azure services that we spoke about.

00:19:28.041 --> 00:19:34.772
And if, uh, you don't need it, I guess you can take that consideration off.

00:19:34.772 --> 00:19:35.413
Uh.

00:19:35.413 --> 00:19:41.101
But in my opinion, just to throw it in there, just to add something, thinking about that, you may limit yourself.

00:19:41.101 --> 00:19:47.847
You may not need some of those services, but you have to think about the future as well and what it would take to use some of those services.

00:19:47.847 --> 00:20:03.449
And so someone who's looking to use that natively, as you had mentioned, without having to hire or pay for someone to do the development which, again, you may have a reason for that, which is okay, just to keep that in mind to consideration as well.

00:20:03.449 --> 00:20:10.712
And with that, is there anything else that stands out for either one of you?

00:20:10.712 --> 00:20:18.595
The differences between them, with the on-prem version and online version.

00:20:20.578 --> 00:20:21.119
Well, we kind of.

00:20:21.119 --> 00:20:22.439
Yeah, go ahead.

00:20:23.722 --> 00:20:27.673
Oh, we mentioned a little like we touched upon the development side.

00:20:27.673 --> 00:20:37.634
We said that on-prem, for example, we need to pay for additional objects when we develop, customize anything which we don't need to do in SaaS.

00:20:37.634 --> 00:20:39.527
But there is other side of it.

00:20:39.527 --> 00:20:45.272
We are more flexible on-prem in what we can do, what we can access.

00:20:45.272 --> 00:20:49.672
We can access file system, for example, which we obviously can't do in SaaS.

00:20:49.672 --> 00:20:51.625
The file system doesn't exist.

00:20:52.141 --> 00:20:53.064
Want to store anything?

00:20:53.064 --> 00:20:59.229
Use blob storage, file storage, those Azure services, net control, net add-ins.

00:20:59.229 --> 00:21:01.867
We want something really custom.

00:21:01.867 --> 00:21:05.349
We need to full flexibility or a full power of NET.

00:21:05.349 --> 00:21:12.874
We can do it when we deploy on-prem in the cloud.

00:21:12.874 --> 00:21:25.269
Now we are very much limited and if we want to do something like this, we have to think about contributions into the system app, because only system app can access dotnet.

00:21:25.269 --> 00:21:38.180
Actually, I had this kind of problem when we needed integration by FTP, for example, until recent time, thanks to one recent open source contribution in Business Central.

00:21:38.180 --> 00:21:47.662
Now we will probably have FTP access or FTP services in Business Central system, but before previously we didn't have.

00:21:47.662 --> 00:21:52.107
So it was quite a problem to access an FTP server from Business Central.

00:21:55.182 --> 00:21:56.049
So that's a big point.

00:21:56.049 --> 00:22:06.585
So if you're working online, access to the local file system doesn't exist because it operates outside of your network in a sense, so you don't have access to it.

00:22:06.585 --> 00:22:27.564
So if you needed to do some FTP integrations, as you mentioned that's a common one that I see where there are some challenges with online you have to, as you mentioned, use some online storage and then, from that online storage, exchange the files, whereas on-prem you can work with a local file system and then be able to exchange the files through there.

00:22:27.564 --> 00:22:29.016
And you mentioned another one as well.

00:22:29.016 --> 00:22:31.656
You mentioned if you needed to use some.

00:22:31.656 --> 00:22:36.140
You mentioned use NET controls or any other custom controls or apps.

00:22:36.140 --> 00:22:36.882
What do you mean by that?

00:22:37.530 --> 00:22:39.276
Well, any kind of NET development.

00:22:39.276 --> 00:22:40.901
What was it?

00:22:40.901 --> 00:22:49.121
Well, I can give an example from our development perspective.

00:22:49.121 --> 00:23:01.800
I work for LS Retail and in the past, all the custom code, all the connections with hardware for example, hardware station in LS used to be a big NET control.

00:23:01.800 --> 00:23:04.758
Well, we communicate with hardware a lot.

00:23:04.758 --> 00:23:08.480
Well, there is no better way to do it than NET control.

00:23:08.480 --> 00:23:11.861
Now we don't have this option.

00:23:11.861 --> 00:23:15.461
The only thing we can do is online communication via APIs.

00:23:15.461 --> 00:23:20.498
There's no NET anymore and there was a lot of NET code here.

00:23:22.510 --> 00:23:35.809
Oh, with that application, I know there was a lot, as you had mentioned, because it was a requirement to work with the hardware, so it required to have the NET stack so that you can interface with the hardware directly in order to use the application.

00:23:35.809 --> 00:23:41.883
So that's one thing to consider between on-prem and online.

00:23:41.883 --> 00:23:56.616
See, it's good to deep dive into this, because I hear so many different things between online and on-prem, and some are in favor of it one over another for various reasons, but it's nice to hear the differences between the two of them as well.

00:23:56.616 --> 00:23:59.214
So what can you think?

00:23:59.214 --> 00:24:16.438
One thing that I hear, and maybe you can help articulate it for me a little bit, is data access is something that I hear is a big one, that people talk about Data access and data capacity.

00:24:16.438 --> 00:24:21.817
Can you maybe tell me a little bit about that with on-prem and online?

00:24:22.849 --> 00:24:34.380
Well, of course he detailed all those things that we need to purchase to deploy Business Central on-premise.

00:24:34.380 --> 00:24:44.178
We need to have our hard drives, SSD licenses, but we're practically unlimited in the storage when we store data on-prem right.

00:24:44.178 --> 00:24:55.301
We have our own server and storage is cheap, even if it's ssd prices are going down lower and lower on ssd storage when we are online.

00:24:55.301 --> 00:25:07.414
We have 80 gigabytes storage plus three gigabytes per full user and 80 gigabytes storage plus three gigabytes per full user and, if I remember correctly, three gigabytes per full user license and two gigabytes per team user license additionally on top of these 80.

00:25:07.414 --> 00:25:10.403
And that's it and additional storage.

00:25:10.589 --> 00:25:13.458
Well, it can be purchased, but it's not that cheap.

00:25:13.458 --> 00:25:15.343
It's quite expensive.

00:25:15.343 --> 00:25:20.077
Yeah, and there are some customers who have a lot of data.

00:25:20.077 --> 00:25:27.112
If you have terabyte of data, it's not that rare Terabyte of data and it's one environment, what I'm saying.

00:25:27.112 --> 00:25:45.763
80 gigabytes plus it's the limit per tenant for all environments and you need production environment, you need sandbox, at least one, and if you need two sandboxes for development, for testing, like troubleshooting, support, well, we're talking about three gigabytes data.

00:25:45.763 --> 00:25:47.192
How much will it cost?

00:25:47.192 --> 00:25:49.881
I don't know the price, but it will be quite expensive.

00:25:51.329 --> 00:25:52.954
Yes, so that's a consideration.

00:25:52.954 --> 00:26:12.623
Then is the amount of storage, amount of data that you would like to have within your business central environment, because online you have a fixed capacity per your licensing and then you can purchase additional capacity, whereas on-prem you have the capacity of whichever system that you have.

00:26:12.623 --> 00:26:16.240
And, as you had mentioned, disk space now is relatively cheap.

00:26:16.240 --> 00:26:30.426
I remember when memory I remember when remember I was outside I bought a four gig chip and I think I spent several hundred dollars for it, right, and I even remember I was I was so happy and excited that now I had like a four gig, uh, four gig, of ram in my machine.

00:26:30.426 --> 00:26:39.721
And in the same thing with disk drives, remember you talked about disk drives like, oh, I have a gig, I have, uh, 10 gig, and now it's you know, a little ssd card you can get.

00:26:39.721 --> 00:26:49.586
You know 128, 256 gig, for you know less than 20, so it's uh us don't get stuck in the 90s bread.

00:26:52.211 --> 00:26:52.592
It was.

00:26:52.592 --> 00:26:55.133
It was a good decade, it was a.

00:26:55.133 --> 00:26:56.433
It was a very good decade.

00:26:56.433 --> 00:26:57.835
I'm trying to bring it back still.

00:26:58.615 --> 00:27:06.099
I'm trying to bring back the 90s because for many reasons, for many reasons, but no, thank you.

00:27:06.099 --> 00:27:19.167
That's another consideration for on-prem, for the storage I hear often as well and I hear others talk about, is the data access.

00:27:24.570 --> 00:27:25.192
Let's clear up that.

00:27:25.192 --> 00:27:33.961
To be able to have access to the data directly between on-prem and online, yeah, well, in the on-prem you can put the fingers into SQL Server and you can even deep dive into changing even the triggers.

00:27:33.961 --> 00:27:39.041
But right now it changes since a couple of versions.

00:27:39.041 --> 00:27:47.000
It might also give you an error, from what I remember, but you can even change what it does in the trigger.

00:27:47.000 --> 00:27:51.026
If you insert in one table, then you can trigger something else in your premise.

00:27:51.026 --> 00:27:59.840
Don't do this because Microsoft also stated this is the worst way to do it because otherwise it might give you unpredictable results.

00:27:59.840 --> 00:28:02.979
But in on-premise, you really have access to anything.

00:28:02.979 --> 00:28:05.116
I'll give you just one example.

00:28:05.116 --> 00:28:19.046
Another example Microsoft just recently announced that they want to introduce in upcoming version 27, that it is 2025, wave 2, in October recordtruncate.

00:28:19.046 --> 00:28:36.936
So well, yes, but with some if, if, if, and then in the on-prem version, if you do truncate, well, it would mean it's the truncate that it is on that you can do into SQL Server 11.

00:28:36.936 --> 00:28:38.676
Truncate means that, okay, this is the table.

00:28:38.676 --> 00:28:42.617
Okay, remove everything that you have inside in a femtosecond.

00:28:42.617 --> 00:29:01.711
So if you have 1 million of records, 10 million of records, 20 million of records, five seconds, four seconds, right, alexander, with a truncate blink of an eye, your change log, your job queue entry log or the log that you have of everything, I don't know.

00:29:01.711 --> 00:29:08.176
Maybe you have sending web services and then you want to stay and you want to store the payload there.

00:29:08.176 --> 00:29:18.576
So tables, even with less record, but with big blobs inside of it, completely flushed away, and Microsoft want to introduce this recordtruncate.

00:29:18.776 --> 00:29:22.223
That it is just a winning things, but they have limitation.

00:29:22.223 --> 00:29:23.436
So it doesn't work.

00:29:23.436 --> 00:29:29.733
If you have, from what I've read, media, media set fields, because then you have a reference and then you might have orphaned.

00:29:29.733 --> 00:29:52.166
Then if you have on delete code or even events on and after this kind so there are some if this one is not truncated In the on-premise, still, you want to go with this finger snap thingy so you delete, but then you have to handle the media set orphaned by your own.

00:29:52.166 --> 00:29:53.935
So you just have to do the clean up after.

00:29:53.935 --> 00:29:58.277
So you have much more degrees of freedom in the on-premise.

00:29:58.277 --> 00:30:02.961
But this comes with great power, comes with great responsibility.

00:30:02.961 --> 00:30:05.297
You know what I mean.

00:30:05.297 --> 00:30:06.815
I know what that means.

00:30:07.056 --> 00:30:12.020
I know it is true and a lot of times individuals don't remember that.

00:30:12.020 --> 00:30:22.903
As you mentioned, if you're just doing a quick truncate, you do also have the media sets or other links that may be associated with those records as well, that uh could get orphaned and create some problems.

00:30:22.903 --> 00:30:24.612
I go back to the record truncate.

00:30:24.612 --> 00:30:32.757
I read that recently, uh, and I was excited when I read it and also it took me a moment to get my head around it, because I think you can also use filters on that too.

00:30:32.757 --> 00:30:34.121
Right?

00:30:34.121 --> 00:30:36.574
If I read it correctly, it's not the same trunccated as.

00:30:36.615 --> 00:30:52.957
SQL, you can filter records and you can still delete a large number of records while using a filter, instead of having to loop through and delete them or I don't know where If you did delete all.

00:30:55.835 --> 00:31:06.548
Yes, I have to still play with this, but from what it is written, written, the things that it does it takes all the remaining record into a temporary table, does the truncate and then inflate them there.

00:31:06.548 --> 00:31:12.758
So if you have, if you want to delete 10 records over 10 million, then it is a bad idea.

00:31:12.758 --> 00:31:27.195
Again, I haven't played with that right now, but if it is that way then maybe it might be the way around, but anyway, I did remember reading that as well.

00:31:27.257 --> 00:31:34.713
Now that you mentioned that, that it copies the data off, cleans the table and then copies the data back or transfers the data back.

00:31:34.713 --> 00:31:39.153
I guess you could say yeah, yeah but it's okay.

00:31:40.451 --> 00:31:40.854
Yes, me too.

00:31:40.854 --> 00:31:41.817
I'm really excited.

00:31:41.817 --> 00:31:49.997
This works super well with, overall, your custom table, the one where you store logs or something that well, where you completely have the handle.

00:31:49.997 --> 00:31:56.098
And maybe you forget about this after one, two, three months and say, okay, how much records I have inside?

00:31:56.098 --> 00:32:00.279
Oh, 25 million, million, half of the database, oh gosh.

00:32:00.279 --> 00:32:04.650
And then in the online version it would be hard to have them deleted.

00:32:04.650 --> 00:32:14.575
If you forget also to apply retention policies since the beginning, that might happen yeah, no, that's that's good.

00:32:14.634 --> 00:32:20.679
To go back to even what Alexander mentioned in the beginning, if you have a sandbox environment, it goes towards the capacity.

00:32:20.679 --> 00:32:26.560
So if you need to copy your production to your sandbox, you can truncate some of those tables that you may not need for testing.

00:32:26.560 --> 00:32:51.742
Again, I'd be very careful to do any of that in production because of the data that you have and the other records that you need, but from a sandbox point of view, you may not need to have all of those entries or all of those transactions to do testing and that way you're not using a lot of space that is limited and expensive online with those sandbox environments, which is good.

00:32:51.742 --> 00:32:53.833
Yeah, that's so.

00:32:53.833 --> 00:32:58.510
You know, it's like Christmas Whenever they publish the list of what's new or what's coming or what's planned.

00:32:58.510 --> 00:32:59.750
I guess you could say it's like a Christmas list for me, and it's like Christmas Whenever they publish the list of what's new or what's coming or what's planned.

00:32:59.700 --> 00:33:06.135
I guess you could say it's like a Christmas list for me and it's twice a year, so Christmas does come twice a year, just so everybody knows.

00:33:06.135 --> 00:33:11.392
It's when they release the what's new and planned for wave one or wave two.

00:33:11.933 --> 00:33:12.715
Christmas wave.

00:33:15.241 --> 00:33:17.432
Yes, it is.

00:33:17.512 --> 00:33:21.678
It is, we'll have to ride that wave.

00:33:21.678 --> 00:33:26.317
Another thing thing, and I'll throw this out there if you have anything else to add, you can jump in and add it as well.

00:33:26.317 --> 00:33:35.637
But my mind races with all of the questions that I get asked, because I get the opportunity, thankfully, to speak with many people and I get asked many questions.

00:33:35.637 --> 00:33:44.181
Uh, and Duilio will hit this one Are there any performance differences between online and on-premise?

00:33:44.181 --> 00:33:46.875
Actually, I have to go.

00:33:46.915 --> 00:33:56.849
Sorry, I have to go the moment you answer that, we'll just mute you the entire time.

00:33:56.849 --> 00:33:59.751
The moment you answer that, we'll just mute you the entire time.

00:33:59.771 --> 00:34:01.834
This question is very much linked to the previous one.

00:34:01.834 --> 00:34:09.519
For me and it's my pain actually, because Julio said we can't define triggers when we're working on-premise.

00:34:09.519 --> 00:34:12.382
We can't define triggers directly in the SQL tables.

00:34:12.382 --> 00:34:13.382
Never do this.

00:34:13.382 --> 00:34:17.385
But I must admit I've done this and that's only me.

00:34:17.385 --> 00:34:18.206
You did it.

00:34:21.313 --> 00:34:24.762
You did it Guilty, guilty, yeah, I am guilty.

00:34:26.331 --> 00:34:28.599
I am guilty, yeah, but why I did this?

00:34:28.599 --> 00:34:33.273
Exactly because of performance problem.

00:34:33.273 --> 00:35:13.514
It was a project where pretty large database running something around 100 companies ATE or something like that and there was a job task that was aggregating data from all these companies into one single table that must contain all the aggregated data for reporting, basically because if we try to set up any kind of Power BI aggregations or JetReports or whatever from dozens of 80, 100 companies, it will be well, let's say, will not perform.

00:35:13.514 --> 00:35:17.543
So it was a nightly talk.

00:35:17.543 --> 00:35:24.820
It was collecting data from all these companies into one aggregated table and, yes, it was a SQL stored procedure.

00:35:24.820 --> 00:35:27.034
It wasn't a trigger, by the way, it was a stored procedure.

00:35:28.813 --> 00:35:44.489
And I know when we're talking about migration, for example, from on-prem to cloud, at least there is at least one category of customers I know of who don't want to do this, exactly because of performance problems and direct data access.

00:35:44.489 --> 00:35:59.041
They have their own stored procedures because they have large, large jobs running overnight, like stock planning, for example, inventory plan, stock planning, for example, inventory plan.

00:35:59.041 --> 00:36:04.840
Al is never going to perform as well as fine-tuned stored procedure written specifically for a task.

00:36:04.840 --> 00:36:08.117
Right, because we steal from AL.

00:36:08.117 --> 00:36:11.057
We can't work with small bits of data.

00:36:11.057 --> 00:36:15.599
We need to send a large number of queries to the database.

00:36:16.001 --> 00:36:21.795
Well, when it's a stored procedure, it's going to be faster anyway and, yes, they have their own stored procedures.

00:36:21.795 --> 00:36:26.711
In my case, I found a way around it, let's say, still managed to do it.

00:36:26.711 --> 00:36:37.818
I ditched that stored procedure, so did it, did it, moved it to online somehow.

00:36:37.818 --> 00:36:52.242
But there are clients who are really very reluctant to move to SaaS because they have their favorite stored procedures fine-tuned very fast and if they move to SaaS they are limited to L and it's much slower.

00:36:52.242 --> 00:37:01.858
That's a problem of lack of the direct access and why it's very much linked to performance.

00:37:03.315 --> 00:37:09.099
And this is not only a YAL, even with the classic client or other ones, will be the same thing, this whole procedure.

00:37:09.099 --> 00:37:18.431
If you go down, like Alexander stated, you cannot be faster than this because it is all, everything is done server side, everything completely, so you don't have any kind of interaction between a client.

00:37:18.431 --> 00:37:32.679
And faster than this because it is all, everything, it is done server side, everything, completely, so you don't have any kind of interaction between a client and then server yeah, don't move any data between business center on sql, everything down there completely server side and, yes, we also have some, some kind of seed remaining this one.

00:37:32.880 --> 00:37:44.442
There is one that it is more or less doing the mrp during the night with third procedure, but but those are really corner cases from very, very releases in the back.

00:37:44.442 --> 00:37:51.641
I was joking when I was saying I have to go out, but it is the performance of the online version.

00:37:51.641 --> 00:37:59.914
It is getting better and better, release after release, and you're always running on the latest version of SQL Server and always running on the latest version of SQL Server.

00:37:59.914 --> 00:38:04.780
And SQL Server in the latest version always have goodies that you can take care of.

00:38:04.780 --> 00:38:06.894
And then also AL.

00:38:06.894 --> 00:38:11.235
It is right now that it is since NAV 2013,.

00:38:11.235 --> 00:38:12.440
It is SQL Server.

00:38:12.440 --> 00:38:18.032
Only it might take, with this short lifecycle that you have that it is one hour and a half.

00:38:18.032 --> 00:38:23.762
So I think it is the flexible.

00:38:23.762 --> 00:38:27.594
It is not modern lifecycle, the modern lifecycle.

00:38:27.594 --> 00:38:32.329
It is going out of support every two versions.

00:38:32.329 --> 00:38:36.280
So the third one will make it the third one out of support.

00:38:36.280 --> 00:38:49.480
This means that even the SQL Server version that in the SQL system requirements, or better, the compatibility version that was supported, it is moving higher and higher in a very lower timeframe.

00:38:49.480 --> 00:38:57.641
This means that you can support features that have been introduced with SQL Server 2016, 2017, and onwards.

00:38:57.641 --> 00:39:00.458
Otherwise, for compatibility reasons, you cannot do it.

00:39:00.458 --> 00:39:05.880
This means that you can support, I don't know.

00:39:06.650 --> 00:39:08.697
There is one thing that it is maxed up.

00:39:08.697 --> 00:39:20.077
It is DUP, dop feedback that it will suggest you the best degrees of parallelism when a query is executed.

00:39:20.077 --> 00:39:24.862
So we will execute with one degrees of parallelism.

00:39:24.862 --> 00:39:28.856
Let's say it will try with three and then it will execute, and then we'll get the result.

00:39:28.856 --> 00:39:40.373
Then it will try with two, and then we'll get the result with the same, and then we'll say, okay, I can discard the three from the two and retain the one from the two as an execution plan, then so on and so forth.

00:39:40.373 --> 00:39:41.737
So those are just small things.

00:39:41.737 --> 00:39:48.875
And maybe there is another one that is optimized locking, that it is actually SQL Server 2025.

00:39:48.875 --> 00:39:51.697
That still, we cannot use it, right, alexander?

00:39:51.929 --> 00:39:55.155
Yes, but now we still can't use it in Business Central.

00:39:55.155 --> 00:39:59.137
And anyway, now it's available even in SQL Server on-premise.

00:40:00.931 --> 00:40:10.556
Yes, but you never know if we change the transaction isolation level from the repeatable read into the read committed.

00:40:10.556 --> 00:40:11.177
You'll never know.

00:40:11.650 --> 00:40:12.072
Maybe.

00:40:12.072 --> 00:40:27.802
I know that the idea, the overall direction of the development of the way the platform team is working is towards reducing the strictness, the level of the isolation level.

00:40:27.802 --> 00:40:33.141
So repeatable read was introduced a while ago to solve certain problems in the platform.

00:40:33.141 --> 00:40:37.115
Now maybe it will be changed to read committed.

00:40:37.115 --> 00:40:39.659
If those problems can be solved in a different way, we don't know.

00:40:39.659 --> 00:40:40.541
Maybe.

00:40:42.324 --> 00:40:49.423
Yeah, I remember I think it was changed from serializable to repeatable read with NAV 5.0 SP1.

00:40:49.423 --> 00:40:54.442
There was a fix in 5.0 SP1 a long time ago, yeah.

00:40:54.442 --> 00:40:58.519
So from a performance perspective, it is evolving.

00:40:58.519 --> 00:41:02.893
It is really evolving quite fast and for me it is delicious.

00:41:02.893 --> 00:41:18.364
Honestly, I very, very, very, very highly prefer an online environment to work with, because I don't have to take care of many, many, many stuff to work with, because I don't have to take care of many, many, many stuff.

00:41:18.905 --> 00:41:26.981
If you start to have a performance problem or if you want to improve performance, then you have to look okay, let's have a look at the infrastructure.

00:41:26.981 --> 00:41:28.230
Then it comes that you have to run specific tools.

00:41:28.230 --> 00:41:43.054
You have to analyze all the configurations and then you have to analyze all of the maintenance plans that you have in place, which are the things that you do in the online version within the telemetry.

00:41:43.054 --> 00:41:46.295
Then you have to take care of all the other things that count most for you.

00:41:46.295 --> 00:41:51.963
All the other stuff are upon the product group and the product group.

00:41:52.130 --> 00:42:05.059
It is relying on a specific service behind the scene that it is taking care with very, very high profession, with something that most probably any mortal cannot do it exactly.

00:42:05.059 --> 00:42:07.184
It is very, very sophisticated.

00:42:07.184 --> 00:42:26.043
So I swear it is very, very sophisticated and they are taking care of this maintenance based on the information that they have of more than 45 000 right Right now I think it is more than 50,000 production environment that are evolving.

00:42:26.043 --> 00:42:29.235
I'm taking on the data tier and then they can determine.

00:42:29.235 --> 00:42:39.039
Okay, those are the things that mostly we have to apply in order to maintain the indexes or to update the statistics and so on and so forth.

00:42:39.039 --> 00:42:40.693
This kind of automation.

00:42:40.693 --> 00:42:45.190
For me it is super good and it is far easier to work with in performance.

00:42:45.190 --> 00:42:47.838
On the online version.

00:42:48.650 --> 00:42:51.159
Well, now we're touching the topic.

00:42:51.159 --> 00:42:58.050
We usually spend a lot of time with the video discussing, so if we start now, we can end tomorrow spend a lot of time with the video discussing.

00:42:58.050 --> 00:43:02.981
So if we start now we can end tomorrow.

00:43:03.001 --> 00:43:04.164
Just for the introduction.

00:43:04.164 --> 00:43:05.929
You mean Just for the introduction.

00:43:07.510 --> 00:43:14.181
Yes, and I would counter that when I work online, I kind of miss many things.

00:43:14.181 --> 00:43:21.590
I miss, you know, I can't see the execution plan, I miss my query store.

00:43:21.590 --> 00:43:23.856
I can't see it and I want to see the execution plan.

00:43:23.856 --> 00:43:29.333
Well, when I analyze performance cases, I need to mimic the data that client has exactly.

00:43:29.333 --> 00:43:42.833
I need to replicate the volume of data, the distribution, the histogram of the data distribution somehow to see, well, to hope, that the execution plan will be the same that the customer have While on-premise.

00:43:42.833 --> 00:43:51.398
I can connect, run this query, even on the production database or a copy of it, and I can see the execution plan.

00:43:51.398 --> 00:43:53.376
It will be executed exactly in this case.

00:43:53.376 --> 00:43:55.181
That's something I'm missing.

00:43:55.181 --> 00:43:56.273
And the query store?

00:43:56.273 --> 00:43:58.038
Of course Telemetry is good, it has a lot of statistics.

00:43:58.038 --> 00:43:58.519
And the query store.

00:43:58.519 --> 00:44:04.780
Of course, telemetry is good, it has a lot of statistics, but query store is much richer in features.

00:44:07.954 --> 00:44:12.255
So do you have the same level of telemetry access on-prem that you do have online?

00:44:13.710 --> 00:44:30.639
Well, telemetry, yeah Well, we can send the same telemetry from on-prem that we receive from SaaS, yes, but we don't have those analysis features, those troubleshooting features in SaaS that are available on-premise when we have direct access to a database to the back end.

00:44:32.570 --> 00:44:43.974
So, from the performance point of view, online is getting better and you don't have access to some of the features that you have online on prem.

00:44:43.974 --> 00:44:45.659
Excuse me for troubleshooting.

00:44:46.161 --> 00:44:46.360
Yes.

00:44:47.351 --> 00:44:48.275
So that's why you just called it.

00:44:52.637 --> 00:44:57.014
Yeah, exactly, exactly, exactly.

00:44:57.014 --> 00:45:13.144
Like Alexander, I'm, of course, missing the XML representation or the text, if you want, but I'm using the XML representation, because it is humanly readable of the estimated execution plan of the query.

00:45:13.144 --> 00:45:25.525
So this is what actually will be the next execution and what it is causing the biggest overhead, in order to optimize this in the less round trip.

00:45:25.525 --> 00:45:32.083
And I do agree that it would be great to have also the query execution plan.

00:45:32.083 --> 00:45:40.543
The problem of the execution plan is that you want to send this into telemetry because it might be super big.

00:45:41.793 --> 00:45:48.896
And if you send this for every long-running SQL query that it is higher than 750 milliseconds, maybe on demand, it would be good.

00:45:48.896 --> 00:45:56.677
I just want this, this, this, this and that and then just send me the query execution plan and then that would be a good compromise.

00:45:56.677 --> 00:46:01.809
Yeah, but yes, it is evolving.

00:46:01.809 --> 00:46:06.737
If you look at, this is just the first signal.

00:46:06.737 --> 00:46:08.699
Was with version.

00:46:08.699 --> 00:46:18.561
Was the first signal this is a question for you about telemetry when was the first signal introduced in telemetry in Business Central?

00:46:18.561 --> 00:46:19.943
I know?

00:46:21.269 --> 00:46:22.996
14, maybe.

00:46:24.213 --> 00:46:25.317
Is it 14?

00:46:25.336 --> 00:46:29.356
I know it exists in 2018 and they keep adding signals to each version.

00:46:29.356 --> 00:46:30.994
Which version, I don't know.

00:46:30.994 --> 00:46:31.876
Alexander, what do you think?

00:46:33.240 --> 00:46:34.083
I don't remember.

00:46:34.847 --> 00:46:37.717
Version 15 was the first one I was going to say that.

00:46:37.717 --> 00:46:40.237
Yes there were two seniors number up.

00:46:40.237 --> 00:46:41.612
Well, no, because version.

00:46:41.733 --> 00:46:53.557
Well, version 14 was the last version where you could use cal, and they switched it over to al completely in version 15 which don't even get me into the whole version number thing, because that will send us to a spiral.

00:46:53.757 --> 00:47:04.054
But version 15 when it became pure al definitely, and in version 15 they recognize okay, we need something, some telemetry, to let you know, to deflect cases to us.

00:47:04.054 --> 00:47:06.255
And the first and you.

00:47:06.255 --> 00:47:09.438
It was created for the authorization.

00:47:09.438 --> 00:47:21.123
The first one was the authorization because at the support they were receiving a lot of okay, I cannot get access, I cannot enter actually inside in my environment.

00:47:21.123 --> 00:47:29.820
But because there was probably more problem with credentials, then they added this signal Okay, within the signal you can recognize, okay, then there is an influx, it is a problem.

00:47:29.820 --> 00:47:32.730
Otherwise there is only one user that cannot enter, exactly.

00:47:35.496 --> 00:47:38.204
So that is a good little bit of history with telemetry.

00:47:40.494 --> 00:47:44.063
I thought it was designed for online, so that Microsoft can see everything.

00:47:48.210 --> 00:47:51.277
Before this, the instrumentation with telemetry.

00:47:51.277 --> 00:47:54.503
It was even before, before version 15.

00:47:54.503 --> 00:47:59.742
And Microsoft, if you imagine, you know, imagine Titanic, the iceberg, right.

00:47:59.742 --> 00:48:09.760
Yes yes, that's like in Titanic, so we just see, maybe from far distance, the peak of the iceberg.

00:48:09.760 --> 00:48:17.918
But Microsoft do have a lot of telemetry, so maybe we just have 500, 600 seniors I do not remember how much.

00:48:17.918 --> 00:48:22.873
We have it, microsoft, they have thousands and thousands of their seniors actually.

00:48:23.655 --> 00:48:36.565
Yes, the telemetry they have is great because they can see who uses which feature, which button, which, everything, which is good because it helps with the understanding of how the application is used and enhanced.

00:48:36.565 --> 00:48:45.003
But no, it wasn't invented just for that, chris, even a lot of other applications outside of business central use telemetry.

00:48:45.003 --> 00:48:46.030
Telemetry gets used on everything Now.

00:48:46.030 --> 00:48:52.280
Vehicles, when you're driving, emit telemetry and a lot of people don't realize that there's a lot there.

00:48:53.092 --> 00:48:55.730
So I know I'm saying just from a lot of people's perspective.

00:48:55.730 --> 00:48:56.632
I get that a lot.

00:48:56.632 --> 00:49:09.447
You know, it's like like I understand telemetry has been around, even with other erp systems as well, but uh, when it was sort of introduced to the end users a lot of end users I heard that from their feedback.

00:49:09.447 --> 00:49:19.003
It's like, oh, maybe because they just want to see more, and blah, blah, blah and say, well, I think they've always seen a lot more than what you had thought, but I appreciate the history.

00:49:21.052 --> 00:49:22.418
Yeah, we had a little history lesson.

00:49:22.891 --> 00:49:26.280
We should start a trivia in every discussion that we have.

00:49:26.280 --> 00:49:29.255
So to go back to.

00:49:29.255 --> 00:49:37.557
So the performance it seems to be questionable right Between the two, depending upon what you need.

00:49:37.557 --> 00:49:40.237
But Business Engine Alliance pretty performant.

00:49:40.237 --> 00:49:44.577
If you have large systems, maybe have a little bit more on-prem.

00:49:44.577 --> 00:49:45.480
Is that what I'm hearing?

00:49:46.931 --> 00:49:53.380
Yes, a little bit, but on the other hand, well, it's an exhaustible topic actually, because we haven't mentioned two things.

00:49:53.380 --> 00:50:01.295
First, scaling so when the system experiences high load it will be automatically scaled.

00:50:01.295 --> 00:50:06.481
So user sessions will be redistributed to another virtual machine automatically.

00:50:06.481 --> 00:50:08.766
That happens behind the scene in the cloud.

00:50:08.766 --> 00:50:28.510
Spikes in workload, so you don't have to keep always that backup system, I don't know additional extra confidential resources, additional virtual machines, just because you have a spike at some time.

00:50:28.510 --> 00:50:32.052
You expect it or it will be done automatically behind the scene.

00:50:32.052 --> 00:50:37.717
And another thing that we have is scale out.

00:50:37.717 --> 00:50:48.047
In SaaS we always have a copy of the database which can be accessed in read-only mode from queries and from pages.

00:50:48.047 --> 00:50:54.592
So these queries will be redirected to a copy of the database.

00:50:54.592 --> 00:50:56.918
That will not affect active users posting something or entering data.

00:50:57.581 --> 00:50:58.101
And reports.

00:50:58.490 --> 00:51:03.659
Reports yeah, yeah, reports as well so that's, that's a good call out because the scaling is important right.

00:51:03.659 --> 00:51:24.679
So, as you know, some organizations where they may have seasonality, where they have a lot more volume, rather than if you're an on-prem, you kind of have to manage that and expand that to accommodate that little small maybe a seasonal kind of component and you're not oversizing your environment just for that two months that you may need.

00:51:24.679 --> 00:51:29.846
Where Microsoft, if it's a business, the BC Online version, it would just do that for you.

00:51:37.054 --> 00:51:40.300
And so that's again another technical debt that you may not want for on-prem.

00:51:40.320 --> 00:51:43.088
I can tell you one word Black Friday that you may not want for on-prem.

00:51:43.108 --> 00:51:43.429
Go ahead, mr Sir.

00:51:43.429 --> 00:51:43.949
One word Black Friday.

00:51:45.543 --> 00:51:47.711
Yeah, exactly yes.

00:51:47.711 --> 00:51:57.324
During Black Friday there is this high volume everyone that is doing this kind of integration with webshops they have this kind of Black Friday craziness.

00:51:57.324 --> 00:52:02.512
Then you will see, we will touch.

00:52:02.512 --> 00:52:03.793
We don't end In a scalable system.

00:52:03.793 --> 00:52:11.264
What does it mean when you have to scale this kind of multi-tenant proposition?

00:52:17.190 --> 00:52:20.856
So they will add more and more and more horsepower in order to make it work during the Black Friday.

00:52:20.856 --> 00:52:26.224
Yeah, two key points that you mentioned, alexander, but I want to first go with them in order because I have a question on the scaling.

00:52:26.224 --> 00:52:33.239
So we understand that the system will scale based upon the spikes or the influx of volume or transaction or load.

00:52:33.239 --> 00:52:35.996
I guess you could say Is there a limit to that?

00:52:35.996 --> 00:52:38.070
Is there a limit to the duration?

00:52:38.070 --> 00:52:48.643
So, if you have a, or is it just scale to the use of your system as you use it, are you aware if there's a limit to how much it can scale?

00:52:49.646 --> 00:52:50.047
I don't know.

00:52:50.047 --> 00:52:55.166
I think we spoke about this, I'm sorry.

00:52:55.166 --> 00:52:55.947
Go on.

00:52:56.327 --> 00:52:58.521
Yeah, sorry, I didn't mean to cut you off, alexander.

00:52:58.521 --> 00:53:02.405
There was a session that I went to.

00:53:02.405 --> 00:53:18.197
They talked about that there's a threshold percentage where, if it I believe it was like 80% as it stays consistent at 80 utilize and as it creeps up, then they would go ahead and and create a vm for you and it's a specific duration of time.

00:53:18.197 --> 00:53:24.804
Where it goes below, that is, below a specific threshold, then they will go ahead and take that vm away because you're no longer using it.

00:53:24.804 --> 00:53:29.503
I remember seeing that slide somewhere, maybe a couple years ago directions.

00:53:29.503 --> 00:53:35.213
It's 60% actually and there is a perfect 60%.

00:53:35.077 --> 00:53:35.510
Oh yeah okay, even lower.

00:53:35.510 --> 00:53:45.407
Yeah, a series of podcasts under Business Central, under the hood, and there is one episode where Christian Heididam was talking about exactly this topic.

00:53:45.407 --> 00:53:47.342
He mentioned these thresholds.

00:53:47.342 --> 00:54:04.123
Yeah, when it's's consistently, when the virtual machine utilization is consistent over 60, there's another one uh created, uh, and the load balancer will start redirecting user, balancing user sessions between these two machines.

00:54:04.123 --> 00:54:14.960
If the two will be above 60, uh, now another one will be created, and so on, and theoretically.

00:54:14.960 --> 00:54:16.969
Well, they don't mention any limit to this.

00:54:16.969 --> 00:54:17.873
If there is any, sky's the limit.

00:54:17.873 --> 00:54:29.907
Probably Maybe there is some limit to how much resources the client can consume, but well, to the best of my knowledge, it's not published, at least.

00:54:30.909 --> 00:54:50.141
Okay, and the second part of this I want to understand and you said it's a key point and you talked through it in Dualio Combatant as well is if you're running queries or reports against the data, it's not running against your production system, it's running against a copy of the system.

00:54:50.141 --> 00:54:53.284
Therefore, it doesn't impact the performance.

00:54:54.197 --> 00:54:55.278
Yes, it's actually.

00:54:55.278 --> 00:55:01.721
There is a property in reports, queries and pages, as far as I remember, so we can specify exactly.

00:55:01.721 --> 00:55:11.264
So this report will be reading data from a scale-out copy, not accessing the actual production database, but will be accessing only the reporting copy.

00:55:13.657 --> 00:55:16.523
Only API, only API queries and API pages.

00:55:16.523 --> 00:55:17.706
Just to be precise.

00:55:17.706 --> 00:55:19.521
Okay so it's only the.

00:55:19.601 --> 00:55:22.034
API queries and only the API pages.

00:55:22.034 --> 00:55:26.806
If you specify that it's for the data, is it data intent?

00:55:26.806 --> 00:55:29.222
I think it's like the data intent access.

00:55:29.282 --> 00:55:33.960
Is that the property Data access intent yeah, database access intent.

00:55:34.041 --> 00:55:35.938
it is called, and then you can.

00:55:35.938 --> 00:55:49.041
There is also a page inside Business Central that is called database access intent and this will show pages, report and query and then you can determine there is the default behavior.

00:55:49.041 --> 00:55:52.840
And then you can determine there is the default behavior and then you can choose read only or read write.

00:55:52.840 --> 00:55:54.597
Okay, and this one.

00:55:54.597 --> 00:56:03.744
Let's say some of the reports are by default customer top 10, vendor top 10, and customer details.

00:56:03.744 --> 00:56:11.516
Those are already read only and they will go, if it is available in the online version, into the read only node those reports here, if it is available in the online version, into the read-only node those reports here.

00:56:11.516 --> 00:56:23.121
But you can choose what you want to move into the read-only node and this means that you're offloading your reading from the transactional node, you're offloading into the other SQL Server node.

00:56:23.121 --> 00:56:26.371
It's like having two SQL Server at the price of one.

00:56:26.992 --> 00:56:27.355
I like that.

00:56:28.996 --> 00:56:29.679
That is the thing.

00:56:29.679 --> 00:56:36.186
Remember one thing If you are on-premises, this is only possible if you have the SQL Server Enterprise SKU.

00:56:36.186 --> 00:56:40.860
This means that only if you spend quite a lot of money.

00:56:40.860 --> 00:56:45.240
This read-only replica does not work if you have the standard one.

00:56:45.240 --> 00:56:50.465
That is one thing, and I know this because we have enabled this.

00:56:50.465 --> 00:57:00.507
We have some on-prem customer big fishes that do have SQL Server enterprises and we have enabled this read-only replica also in the on-premises.

00:57:00.507 --> 00:57:10.742
So it is really an added value in the online version to have this read-only replica, Because you're offloading all the loads, let's say API.

00:57:10.742 --> 00:57:17.146
If you have a lot of get, those are going and those are redirected into the other node.

00:57:18.916 --> 00:57:20.141
My mind is racing with that.

00:57:20.195 --> 00:57:21.244
That's a lot to consider.

00:57:22.478 --> 00:57:37.726
That's a big one for anyone who works with any development to understand the intent of what they're writing and how it works to be to help, not necessarily cause some performance issues with the users.

00:57:37.726 --> 00:57:42.235
Um, I I have more questions that I have.

00:57:42.235 --> 00:57:44.643
Is there anything else to add to the performance key?

00:57:44.724 --> 00:58:03.195
I mean we can I know we can unpack performance for days but I think from a business perspective it's really hard to maybe an edge case where you would want to be on-prem but you really have to be intentional of wanting to be on-prem.

00:58:03.195 --> 00:58:14.563
Or Business Central Online really gives you a lot of this flexibility and if you look at it from a business perspective cost it just doesn't make sense.

00:58:14.563 --> 00:58:26.362
If I was to make a decision of which direction I'm going the cost of saving long-term it's got to be Business Central Online.

00:58:26.362 --> 00:58:29.440
I just don't see it.

00:58:29.440 --> 00:58:42.485
I mean, like I said, you guys mentioned a lot of the benefits of maybe some of the on-prem capabilities and a little bit more control, but you really got to be intentional of staying in it.

00:58:42.715 --> 00:58:43.436
Yes, I would say.

00:58:43.436 --> 00:58:48.266
If there are customers who want to stay on-prem, there are.

00:58:48.266 --> 00:58:53.820
To me, from my experience, there are two maybe categories I mentioned already mentioned.

00:58:53.820 --> 00:59:02.724
One is big client, who runs big tasks in the background and they want to get maximum performance.

00:59:02.724 --> 00:59:10.422
Or maybe they have integrations with internal in-house systems on-premise and they don't want to go in the cloud.

00:59:10.422 --> 00:59:14.425
They have maybe their SQL stored procedures.

00:59:14.425 --> 00:59:21.505
They run in the background and there is another edge to it is internet connection.

00:59:21.505 --> 00:59:34.300
Not every client has completely 100% stable internet connection and sometimes they must be online, uh well, just to be able to do, to perform, to do any job.

00:59:34.300 --> 00:59:40.500
Uh, in talking from the retailer perspective, we have point of sale, pos terminals running.

00:59:40.500 --> 01:00:08.128
If it is online, you lose internet connection, you lose sales, your store doesn't work, it just stops uh, uh, okay, yeah, of course we can talk about a backup connection, but sometimes in some places internet connection can be so unreliable and unstable that users stay offline for days, weeks, and I'm not exaggerating.

01:00:08.128 --> 01:00:09.516
Really it's a real customer pain.

01:00:09.516 --> 01:00:10.331
There was a real customer pain.

01:00:10.351 --> 01:00:53.851
There was a case when their store was offline for a week and they can't afford it, of course that's a very good point to bring up that that we hadn't talked about is that the business center requires a stable internet connection, and if you have locations that need to access or use the system if they don't have, if they're in a remote area, or if they're in an area where the internet connection is not stable due to the infrastructure, then online could be challenging for them to use, which, yeah I could see that that that is a consideration to have again to use between either or.

01:00:56.018 --> 01:01:00.277
I had a lot of questions that are coming to my mind as we were talking about that, but we went.

01:01:00.277 --> 01:01:01.983
I got a little sidetracked for it.

01:01:01.983 --> 01:01:07.139
The application we talked about.

01:01:07.139 --> 01:01:07.983
We have Wave 1, wave 2.

01:01:07.983 --> 01:01:10.583
I'm going to jump a little bit here just because I like to get these out.

01:01:10.583 --> 01:01:17.902
You have all these updates with the wave one, wave two and the minor updates every month.

01:01:17.902 --> 01:01:20.626
What is the update process?

01:01:20.626 --> 01:01:24.603
To stay current with the application for online versus on-prem?

01:01:25.496 --> 01:01:27.215
That's a super good question.

01:01:27.215 --> 01:01:49.588
In the online version there is a cadence where you can apply this update or upgrade and now that we have the so-called flexible update cadence right now you might want to do this once every five months.

01:01:49.588 --> 01:01:57.106
So it is 2.5 per year if you want to have this update cadence.

01:01:57.106 --> 01:02:04.146
Otherwise, microsoft, little by little, will kick in the application update.

01:02:04.146 --> 01:02:12.597
But it is important One thing it is the patching strategy If there is a medium to a severe application bug.

01:02:12.597 --> 01:02:13.976
But it is important One thing it is the patching strategy.

01:02:14.016 --> 01:02:19.338
If there is a medium to a severe application bug, microsoft is taking care of this and then it is deploying this through the pipeline.

01:02:19.338 --> 01:02:35.644
So this means that let's say that now you are in minor update 26.3, and then you find out that there is an application problem, microsoft will fix it and then deploy it worldwide in all 26, 23 environments.

01:02:35.644 --> 01:02:39.786
So you will have this fix between one to seven days or so.

01:02:39.786 --> 01:02:49.670
If you are on-premises and this kind of problem eats you, then you have to wait for the next cumulative update.

01:02:49.670 --> 01:03:09.782
So this means that if this one we discover this by, let's say, the first of this month, then the application update for the on-premises version you have to wait for September in order to have this available, then you have to pick it up and then you have to deploy this yourself available.

01:03:09.782 --> 01:03:11.815
Then you have to pick it up and then you have to deploy this yourself.

01:03:11.815 --> 01:03:21.675
That is one of the big goodies where the online version is working far better and flawlessly compared to the on-premises version.

01:03:21.757 --> 01:03:26.822
Big goody, which comes with a pinch of salt, I would say, exactly one that we discussed yesterday.

01:03:26.822 --> 01:03:32.085
You're not in control of these updates completely allowed.

01:03:32.085 --> 01:03:36.222
You have your and you don't even know if it's going to be applied next night.

01:03:36.222 --> 01:03:50.201
Because if you're running your night heavy job, your MRP planning, your stock planning, aggregation, whatever it is, the moment this patch comes in, your job stops, it's interrupted, rolled back.

01:03:50.201 --> 01:04:04.704
If you don't have a strategy, some kind of commit in the middle, if it can't recover, you're losing your job, just fails and stops, and you don't know when it's going to happen.

01:04:06.688 --> 01:04:09.322
Yeah, there are two kinds of fixes.

01:04:09.322 --> 01:04:14.266
The application of fixes runs typically very rarely outside the Windows update.

01:04:14.266 --> 01:04:24.750
The platform hotfixes the one that Alexander mentioned are something in the bits in the platform, in the DLL or in the component version that are used in the online version.

01:04:24.750 --> 01:04:57.460
This one, since you have to patch one node at a time, you cannot rely on the update window because there are many customers with different night and if you're running mrp or some business critical process that it is very heavy and you're forced to run it overnight, then maybe this one will interrupt you.

01:04:57.460 --> 01:05:02.239
And just to add on the alexander comment that it is, I just fully support the.

01:05:03.420 --> 01:05:05.324
The one that maybe is hitting you.

01:05:05.324 --> 01:05:08.157
It is stopping the queue and then this one is not starting.

01:05:08.157 --> 01:05:18.306
The worst things it is happens is that when it is eating and then it is rolling back and starting once again because the task address is very resilient.

01:05:18.306 --> 01:05:28.166
But when it starts and then maybe it spans from three, four, five hours, then it goes when all the users start working and maybe if it is MRP it is blocking everything.

01:05:28.166 --> 01:05:30.780
Then you have to try to stop it.

01:05:30.780 --> 01:05:36.706
But the biggest advantage in DOLA, this is one of the biggest advantages.

01:05:36.706 --> 01:05:47.704
You just have to slightly maintain or take care of when the platform or application of success has to be deployed.

01:05:47.704 --> 01:05:53.802
But this flexible update and the fact that there is a continuous update, this one it is a good thing.

01:05:53.802 --> 01:05:58.318
Otherwise, on-premises, you have to care about this by your own.

01:05:59.663 --> 01:06:04.378
So you'd have to run platform and application updates yourself?

01:06:04.378 --> 01:06:08.563
Yeah, and you could.

01:06:08.563 --> 01:06:14.916
Also you have a little more control then on-prem, when those updates get installed as well.

01:06:14.916 --> 01:06:19.023
So it's it's with online.

01:06:19.023 --> 01:06:29.960
Uh, those application hot fixes are sent to your environment as they release them because of uh, each of those nodes is shared by many customers, as you had mentioned, and and they need to.

01:06:29.960 --> 01:06:33.164
Well, they can't separate the customers that way.

01:06:33.164 --> 01:06:37.744
I mean, if you have 50,000 customers, you could have 50,000 variations of Windows.

01:06:37.744 --> 01:06:41.141
So I don't think they have 50,000 machines that they could run that on.

01:06:41.914 --> 01:06:49.403
And then for the application excuse me, yes, for the application updates they have the monthly cadence, but now they've changed the way you can delay it.

01:06:49.403 --> 01:06:53.967
Updates they have the monthly cadence, but now they've changed the way you can delay it, the delay schedule, to give you some more flexibility to know when it is.

01:06:53.967 --> 01:07:05.827
But eventually you will have to update, whereas if you have on-prem you have some more control if there is a reason why you may not want to upgrade at a particular point.

01:07:05.827 --> 01:07:11.027
That's the only struggle with that is if you go too far behind.

01:07:11.074 --> 01:07:17.759
I think what it sounds like to me is it gets a little more troublesome to get current right.

01:07:17.759 --> 01:07:20.599
If you, if you stay close to it, you can get to it rather quickly.

01:07:20.599 --> 01:07:26.949
But if you defer staying current, it could be a little more challenging.

01:07:26.949 --> 01:07:36.375
And then, as you had mentioned, you have to up, you have to apply those updates yourself at that point, or somebody has to do it for you, which could include data migrations.

01:07:36.375 --> 01:07:42.284
If the schema has changed or there's some step that you have to go through, so the upgrade could be.

01:07:42.284 --> 01:07:47.824
There could be some time involved as well, too, depending upon the size of your system, am I correct?

01:07:49.557 --> 01:07:50.420
Yeah, that's correct.

01:07:51.282 --> 01:08:00.068
Okay, okay, I'm trying to just think of all these things because, again, this is one of those questions that, like I said, I get asked quite often.

01:08:00.068 --> 01:08:09.846
Are there any other major differences or points to bring between choosing to go on-prem or online that come to light?

01:08:10.936 --> 01:08:12.682
Are there differences in compliances too?

01:08:13.034 --> 01:08:15.804
That was the question I was going to ask, but not the compliance.

01:08:15.804 --> 01:08:18.480
You hit me, thank you, just I have to remember now what I was going to ask.

01:08:18.662 --> 01:08:20.962
Cause we get that, I get but maybe it's related to compliance.

01:08:20.962 --> 01:08:25.525
Cause I get, we get that question, so I at least I get that question where like, okay, what's the compliances?

01:08:31.914 --> 01:08:32.817
I'm like oh and other things to decide.

01:08:32.817 --> 01:08:35.442
It is where my data are, so people are thinking about the security.

01:08:35.483 --> 01:08:37.646
Actually, I'm thinking about, well, in the US.

01:08:37.646 --> 01:08:40.158
It is also a very, very sensible argument.

01:08:40.158 --> 01:08:48.641
But even in Italy, let's say Italy, at the moment, it is served with West Europe actually.

01:08:48.641 --> 01:08:52.609
So we are in Netherlands the data.

01:08:52.609 --> 01:09:23.301
So it might be that sometimes you want this in your own local subsidiaries In Italy, there is a brand new data center in North Italy that actually is in Milan, and we are just waiting in order to move the cluster out from the West Europe and then use it with North Italy, like it happened, for example, for Switzerland, for Norway, for Germany and other ones, where the data is stored within the same country.

01:09:23.301 --> 01:09:25.541
That is the thing.

01:09:26.158 --> 01:09:31.445
Another matter of choosing online versus on-premises is the security.

01:09:31.445 --> 01:09:38.588
So people are asking quite a lot of questions about how much it is secure the online version compared to on-prem.

01:09:38.588 --> 01:09:50.202
Then when they ask, I revert so how much you are secure that you are one, how many people you are one, two, three, four, five, six people that are One, two, three, four, five, six people.

01:09:50.202 --> 01:09:55.386
That are six people, 10 people in the IT department that are securing your environment.

01:09:55.386 --> 01:10:05.479
In Microsoft, there is a peloton of people only for the security purposes and the security of Business Central Online.

01:10:05.498 --> 01:10:10.689
It is really a matter that counts towards 50,000 environment all over the world.

01:10:10.689 --> 01:10:19.020
So this security, it is taken serious quite, sometimes close to the paranoid right, sometimes close to the paranoid.

01:10:19.020 --> 01:10:24.828
For example, you see this new feature that it is using this certificate validation.

01:10:24.828 --> 01:10:30.327
It is always wants to okay, is the certificate valid or not valid?

01:10:30.327 --> 01:10:52.073
This one it is not to make it just take it just into small consideration, but this one it is to keep the environment very, very more secure and it is not something to say okay, now you're restricting the capabilities, no, we are making the things more secure the capabilities.

01:10:48.675 --> 01:10:58.743
No, we are making the things more secure, with the security going to security you talk about the security from the application point of view and someone being able to access your data.

01:10:58.743 --> 01:11:06.900
I want to take that a step further because and, chris, that's where you came to, because my question was in between the security and the compliance is who has access to the data?

01:11:06.900 --> 01:11:08.104
That's another question.

01:11:08.104 --> 01:11:10.079
So with on-prem, you can control who has access to the data.

01:11:10.079 --> 01:11:10.742
That's another question.

01:11:10.742 --> 01:11:16.802
So with on-prem, you can control who has access to your data from your infrastructure.

01:11:16.802 --> 01:11:21.926
Who has access to your data or who can see your data, based upon security of your SQL server.

01:11:22.775 --> 01:11:25.064
What about online?

01:11:25.064 --> 01:11:33.485
What considerations are to make sure because that goes into some compliance issues and also some security issues is who can see my data?

01:11:33.485 --> 01:11:37.000
So now I have my data stored online somewhere and again, this could be with.

01:11:37.000 --> 01:11:39.390
This is a question for any application.

01:11:39.390 --> 01:11:48.534
That's online, right, it's not just Business Central online, because we are all just trusting that we're putting our data in the cloud somewhere and the data that we're storing may be sensitive.

01:11:48.534 --> 01:11:55.341
It could be personal identifying information, could be banking information, could be all sorts of information like that.

01:11:55.341 --> 01:12:04.890
So now what's in place to control that for online versus on-prem?

01:12:07.416 --> 01:12:07.837
I don't know.

01:12:07.837 --> 01:12:13.908
Let me see who exactly has access from Azure, because it's all stored somewhere in Azure.

01:12:13.908 --> 01:12:20.408
I can say that nobody in Microsoft development or support team has access to customer data for sure.

01:12:20.408 --> 01:12:33.222
Even when you raise a support ticket to Microsoft because you have problems with the data or some issues, support team cannot access this data, even for troubleshooting or whatever.

01:12:33.222 --> 01:12:35.884
They just don't have it successfully.

01:12:36.416 --> 01:12:37.279
I can confirm this.

01:12:37.279 --> 01:12:40.824
So they never, ever, resolve cases.

01:12:40.824 --> 01:12:44.945
I remember I was in Lyon at Directions two years ago.

01:12:44.945 --> 01:12:56.529
So the first, talking about telemetry, the first thing that I told people it is that if you think that Microsoft have access to your data, microsoft doesn't.

01:12:56.529 --> 01:13:03.048
And how they resolve the problem, it is every single case it is resolved through telemetry.

01:13:03.048 --> 01:13:31.837
That is why I have used this kind of metaphor of the iceberg we just can see the peak of it, but behind the water there are really terabyte and terabyte and terabyte and terabyte of data every day that are sent into telemetry, and every single area server runtime, client runtime, application they have their own specific telemetry signal.

01:13:31.837 --> 01:13:38.002
Telemetry signals are, per definition, gdpr aware in Italy, in Europe.

01:13:38.002 --> 01:13:43.237
It means that they do not contain PII personal identified information Nowhere.

01:13:43.237 --> 01:13:49.524
So there is no way that Microsoft can spoil up your bank number or credit number.

01:13:49.524 --> 01:13:58.099
Maybe other people does it, maybe your wife or the people that are with you, but not the other ones.

01:14:00.546 --> 01:14:00.886
That's good.

01:14:00.886 --> 01:14:29.087
Now that is a big concern for some organizations that need to validate that their data is secure with that, whether it be data access controls and such Well, Mr Duilio and Alexander, I appreciate you taking the time to speak with us today about online and on-prem Business Central, and also, Duilio, I'm looking forward to seeing you again this October.

01:14:29.087 --> 01:14:31.722
Duilio and I are going to do Community.

01:14:31.743 --> 01:14:33.561
Summit, community Summit, north America.

01:14:33.561 --> 01:14:34.265
I'm really excited.

01:14:34.488 --> 01:14:35.332
I'm really excited too.

01:14:35.332 --> 01:14:42.706
We're doing another repeat, but improved, because a lot of new things are coming our way.

01:14:42.706 --> 01:14:46.945
We're doing a session on PageScript in a Community Summit, North America.

01:14:46.945 --> 01:14:49.743
Duilio has a few other sessions as well.

01:14:49.743 --> 01:14:51.854
Ruma has it.

01:14:51.875 --> 01:15:07.055
You might be doing something on performance yes, um, exactly, it is uh al profiling in the dynamic 365 business central, a sort of csi of al code that will be I hope they have a big room for that.

01:15:07.237 --> 01:15:08.645
I hope they have a big room for that.

01:15:08.645 --> 01:15:12.301
I'll be there, so I'm looking forward to you in october.

01:15:12.301 --> 01:15:15.570
Thank you, it's uh alexander.

01:15:15.570 --> 01:15:17.836
Will you be uh presenting anywhere soon?

01:15:18.356 --> 01:15:26.779
I don't think you're making it to orlando no, no, not in orlando and not going to be at directions probably excellent.

01:15:27.622 --> 01:15:34.091
No um, in the meantime, if anyone would like to reach out to either one of you, would you mind telling us what's the best way to contact you?

01:15:34.091 --> 01:15:34.494
Alexander?

01:15:36.100 --> 01:15:40.320
well, I think there is a guest intake form that I need to fill.

01:15:40.320 --> 01:15:41.375
Is it published?

01:15:41.375 --> 01:15:43.364
Is contact published somewhere?

01:15:44.056 --> 01:15:46.356
yes, yes the guest intake form.

01:15:46.356 --> 01:15:54.368
The guest information will be linked to each episode, so your contact information that you provide will be listed there and they can contact you to those means.

01:15:55.577 --> 01:16:00.956
Mr Duilio, sir, yes, you can contact me at duiliotaccone that is my name.

01:16:00.956 --> 01:16:08.429
Duiliotaccone at eos-solutionsit.

01:16:10.279 --> 01:16:10.521
Great.

01:16:10.521 --> 01:16:11.088
Thank you both.

01:16:11.088 --> 01:16:13.001
We appreciate you taking the time to speak with us.

01:16:13.001 --> 01:16:21.443
I truly appreciate that, because any time you spend doing one thing, you're not spending it doing another, and time is something that you don't get back.

01:16:21.443 --> 01:16:27.502
So I appreciate it and I look forward to speaking with you both again soon, and I'll talk with you later.

01:16:27.502 --> 01:16:27.783
Ciao, ciao.

01:16:28.936 --> 01:16:29.538
Thank you so much.

01:16:29.720 --> 01:16:31.706
Ciao, bye.

01:16:31.706 --> 01:16:40.922
Thank you, chris, for your time for another episode of In the Dynamics Corner Chair and thank you to our guests for participating.

01:16:41.225 --> 01:16:42.791
Thank you, brad, for your time.

01:16:42.791 --> 01:16:46.260
It is a wonderful episode of Dynamics Corner Chair.

01:16:46.260 --> 01:16:49.746
I would also like to thank our guests for joining us.

01:16:49.746 --> 01:16:52.756
Thank you for all of our listeners tuning in as well.

01:16:52.756 --> 01:17:07.362
You can find Brad at developerlifecom, that is D-V-L-P-R-L-I-F-Ecom, and you can interact with them via Twitter D-V-L-P-R-L-I-F-E.

01:17:07.362 --> 01:17:20.681
You can also find me at matalinoio, m-a-t-a-l-i-n-o dot I-O, and my Twitter handle is matalino16.

01:17:20.681 --> 01:17:24.328
And you can see those links down below in their show notes.

01:17:24.328 --> 01:17:25.698
Again, thank you everyone.

01:17:25.698 --> 01:17:27.243
Thank you and take care.