TRANSCRIPT 🔗
WEBVTT
00:00:20.815 --> 00:00:22.996
Tech Unboxed with.
00:00:23.097 --> 00:00:23.797
BBD.
00:00:24.160 --> 00:00:25.321
Tech Unboxed with BBD.
00:00:26.641 --> 00:00:36.392
Here we are, another Tech Unboxed from BBD, and I have a special guest today with me, werner, and Werner is going to talk about managed cloud services at BBD.
00:00:36.392 --> 00:00:41.176
So, werner, can you please introduce yourself and tell a little bit about BBD?
00:00:47.579 --> 00:00:49.122
Yeah, sure, great to meet you and happy to be here.
00:00:49.122 --> 00:00:50.786
Um, so my name is banner the author.
00:00:50.786 --> 00:01:06.668
I'm part of the, the bbd software development organization, but specifically within our, our cloud space, and I head up our cloud managed service division, which also, coincidentally, service division, which also coincidentally does migrations, modernization.
00:01:06.668 --> 00:01:19.096
So really we are an enablement factory for cloud in BVD but, yeah, like you say, more specialized on the managed service front which we are discussing today.
00:01:19.737 --> 00:01:27.227
Oh great, and I'm happy to hear that there's many other topics that will come to the surface, so let's explore them one by one.
00:01:27.227 --> 00:01:35.109
But there was a little bird that told me that just recently you created a dedicated managed cloud service within BBD.
00:01:35.109 --> 00:01:37.147
Could you explain us a bit more about that?
00:01:37.700 --> 00:01:55.191
Yeah, so that's actually an interesting one, because even though we've recently sort of formalized and split it out into a uh like its own sort of brand within within bbd, that was really more of a a marketing focus on it.
00:01:55.191 --> 00:01:59.704
So how do we, how do we present our, our cloud services, a bit better?
00:01:59.704 --> 00:02:05.072
So the service itself has existed within bbd for uh for quite some time.
00:02:05.072 --> 00:02:26.098
Uh, quite a few years was really just more of a market positioning of that and the um, the idea of that is, uh, just to to highlight the, the offering, a bit better is that because there's a a new trend in cloud adoption?
00:02:26.158 --> 00:02:28.604
is that something changed in the last few months?
00:02:28.604 --> 00:02:31.950
That, uh, this carve out happened?
00:02:32.372 --> 00:02:36.647
it's not necessarily that there's a a new trend in in the market, but what we?
00:02:36.707 --> 00:03:11.414
We have definitely found that there is a requirement for uh for the service, and it is a bit bit different, in the way that we approach it, to the traditional business that we do In the sense of we are a purely multi-tenanted environment and it's almost like a subscription model or a software as a service, where we've built out the tooling, we've built out the processes, all the monitoring, etc.
00:03:11.414 --> 00:03:14.039
And we just plug it into your environment.
00:03:14.039 --> 00:03:23.528
And this is something that we have found in the market is something that many clients don't necessarily have internally.
00:03:23.528 --> 00:03:24.850
Many clients don't necessarily have internally.
00:03:24.850 --> 00:03:44.068
So not having proper monitoring and observability, not having the ability to respond to incidents that arise and also not necessarily knowing enough about the cloud in order to respond to these things well and, in some cases, not even being able to identify if there is a problem.
00:03:44.068 --> 00:04:02.615
So, yeah, that was really the rationale behind it is to make it a bit easier, position it for what it is, which is the subscription-based managed service, and just highlighting the values behind that.
00:04:02.780 --> 00:04:03.943
Just highlighting the values behind that.
00:04:03.943 --> 00:04:05.889
And how far does subscription-based go?
00:04:05.889 --> 00:04:16.350
Because you mentioned a couple of practical things that are very handy, like incident management and stuff, but how does it actually practically work on a technical level?
00:04:16.350 --> 00:04:25.262
Does that mean that the technical capacity or the CPU that you use on the cloud is also something on subscription-based, or is that you buy a lot and that's it?
00:04:27.266 --> 00:04:37.326
so a customer or any company would have their own cloud environment with all their services in there, their compute, database, storage.
00:04:37.326 --> 00:04:55.488
Um, all we do is we plug in an observability stack into that so we make sure that we can see all of the resources that you are running, and then we've got a predefined set of metrics that we monitor constantly.
00:04:55.488 --> 00:05:12.190
If anything breaches a threshold that we've defined as either the system is impaired or the system is down, that'll automatically flag on our help desk, and then we've got a team that does the incident response on our side.
00:05:12.190 --> 00:05:23.413
So what we're really taking the responsibility for here is how do we identify and respond to any technical issues?
00:05:24.442 --> 00:05:29.629
So that's where the manage part comes in, because you don't have to have your own team doing this.
00:05:29.629 --> 00:05:31.644
That's, in essence, what you're saying, right?
00:05:32.567 --> 00:05:33.170
Yeah, correct.
00:05:33.339 --> 00:05:45.740
And what that allows us to do as well is we don't just do incident response that's just, more often than not, the burning problem but we do a lot of proactive services as well.
00:05:45.860 --> 00:06:18.613
So one of the things is that we implement a security posture monitoring and if we use AWS as an example here, that'll be with Security Hub so we define what your security frameworks are that you need to comply to, or what compliance frameworks you need to comply to, and we will constantly monitor those from an infrastructure and security perspective to make sure that we maintain you above 80% of that score at a minimum.
00:06:18.613 --> 00:06:23.067
So that's one thing, and
Load full transcript
there's a lot of proactive work that goes into that.
00:06:23.067 --> 00:06:33.346
So constantly assessing where can we improve, if there are any findings that are generated, because these tools do also scan and alert.
00:06:33.346 --> 00:06:42.548
If there are any changes in the environment that would impact your compliance, then we would action that as well.
00:06:42.548 --> 00:06:58.968
And then, from an optimization perspective, there are tools that do this for you as well, but they do require some expertise behind them to really make the most of it.
00:06:58.968 --> 00:07:06.651
But that's for your cost optimization or your performance optimization.
00:07:09.041 --> 00:07:24.430
Well, I'm wondering what would be the ideal customer or the ideal user to use such managed service, because there's arguments to say, if you're small, you start off with this, and there's arguments to say, when I'm big, it replaces and it makes things more efficient.
00:07:24.430 --> 00:07:25.860
So where is the sweet spot?
00:07:27.684 --> 00:07:28.285
yeah, that's a.
00:07:28.285 --> 00:07:31.730
That's a very good question um it.
00:07:31.730 --> 00:07:34.781
It does depend from organization to organization.
00:07:34.781 --> 00:07:48.100
So we we've actually got quite a spread in uh in in our customers some uh, large, uh, financial institutions, that that we've got, and then some small startup companies as well.
00:07:48.100 --> 00:07:56.074
I think what makes you an ideal candidate for the service is not necessarily your size.
00:07:56.074 --> 00:08:11.031
It's how much of your business is dependent on this cloud environment and how how much skill do you have internally to make sure that this is operating efficiently and properly all the time?
00:08:13.204 --> 00:08:16.593
and if you could define those skills, what would they be?
00:08:16.593 --> 00:08:24.108
If you had to list, like a couple of roles and titles, which would be the titles that are impacted, um?
00:08:25.130 --> 00:08:44.210
So our team consists of cloud architects, cloud engineers, sysops administrators, cloud analysts and then, depending on some other services that you want to use, we've got cloud migration consultants, cloud operations specialists and then DevOps engineers.
00:08:44.210 --> 00:08:57.721
So it's quite a spread, in that also, you have individuals that will be focused on security, some will be focused on networking, storage, compute, serverless.
00:08:57.721 --> 00:09:21.140
So it literally depends on what you actually have in the environment and what direction you are wanting to go in, because you might only need, say, two or three of those roles, but the commonalities are always your cloud engineers, the soft administrators, and we find analysts are invaluable to the process as well.
00:09:22.591 --> 00:09:31.966
Maybe could you walk us through how a typical onboarding would look like with BBD and managed services onboarding would look like with BBD and managed services.
00:09:32.529 --> 00:09:39.941
Yeah, that's actually quite a nice one because we've automated the onboarding process on our side, because it's pretty much the same process each time.
00:09:39.941 --> 00:09:50.240
But once a customer decides to go ahead, there's access that we need to the environment.
00:09:50.240 --> 00:10:14.541
We've written in AWS CloudFormation script which someone deploys within the environment that will then alert us to say that you now have access, and that literally only gives access to our onboarding tool, which we will then use to deploy some of the prerequisite services that we have.
00:10:14.541 --> 00:10:23.000
So we obviously have a baseline of things that we require information from within the cloud environment in order to know what's happening there.
00:10:23.000 --> 00:10:31.019
So it's either the native services or if you have third-party tooling, but let's say this is just a straightforward native service.
00:10:31.059 --> 00:10:31.721
Clean vanilla.
00:10:32.789 --> 00:10:33.836
Yeah, completely vanilla.
00:10:33.836 --> 00:10:36.658
These will be enabled.
00:10:36.658 --> 00:10:44.177
Through that, all of your metrics and alerts are set up automatically on our monitoring platform.
00:10:44.177 --> 00:10:47.720
The content is created on our help desk.
00:10:47.720 --> 00:11:05.740
So there's an onboarding call that will happen as well where we define all of these things who are the contact people, who are the people that need access, who gets alerted when something with cost goes wrong or something with operation goes wrong.
00:11:05.740 --> 00:11:12.602
And then we also define your backup policies.
00:11:12.602 --> 00:11:27.561
Your patching, anything that's policy-based will be defined in that call and that also gets set up together with this onboarding tool, and it's a matter of, I think 30 minutes.
00:11:28.450 --> 00:11:29.937
Wow, only 30 minutes.
00:11:31.030 --> 00:11:36.198
Yeah, from when that role is deployed to when you're actually live with the service.
00:11:37.231 --> 00:11:40.240
It sounded to me like a lot of technical steps, which makes sense.
00:11:40.240 --> 00:11:47.120
So I was wondering how does the technical part marry with the decision takers on the business side?
00:11:47.120 --> 00:11:58.135
What would be your advice for the business side to understand managed services and how to maybe come to you and and apply for that service?
00:11:58.135 --> 00:11:59.575
What's what's in it for them?
00:12:01.951 --> 00:12:12.440
From a, from a business perspective, there's I mean, we always have the, I think any, any company will have the business versus technical.
00:12:12.549 --> 00:12:18.639
How do you sort of appease both sides and how do you showcase value to both sides?
00:12:19.750 --> 00:12:30.445
Something that I think has changed the perception, or the divide me let me rather phrase it that way as as reduce.
00:12:30.445 --> 00:12:55.326
That divide is um, is cloud and and devops,
because it's much easier for a, a business, uh, like a line of business or a head of business, to say that this is the sort of functionality that I want, um, for my project, or this piece of tech that I look after or that services my business.
00:12:55.326 --> 00:13:04.571
They're a lot more involved from a technical perspective than what they were, let's say, five, 10 years ago.
00:13:04.571 --> 00:13:35.340
So, very often the decision makers or the people and scalability of the portion of the platform that they are serviced with.
00:13:35.340 --> 00:14:05.313
So, yeah, I think the main consideration that we usually see from a business perspective is wanting to manage costs better and wanting to make sure that scaling can happen as and when needed, and there's a lot more technical that goes on behind the scenes to orchestrate all of this, but those are the sort of the basics, the bridges between the two, that we see.
00:14:06.024 --> 00:14:26.355
Yeah, and by calling it the bridge, I think you also called it, in this occasion, a trigger, because if scalability and growth is on your roadmap in a very technical driven company, then this is potentially what you need to look at, as it touches so many domains within your business.
00:14:28.147 --> 00:14:28.890
Yeah, absolutely.
00:14:28.890 --> 00:14:33.831
The reliability and scalability aspect of it has.
00:14:33.831 --> 00:14:45.725
I think, just as cloud becomes more commonplace, it's no longer a disruptive model in technology anymore.
00:14:45.725 --> 00:14:50.692
It's more a case of all the new technologies that are becoming available on cloud.
00:14:50.692 --> 00:14:56.850
Those are the disruptors, but cloud is just a different way of consuming things that exist already.
00:14:56.850 --> 00:15:15.875
There is obviously a lot more sort of central innovation that can happen, because once you start aggregating everyone's usage into a certain place, you know you can put in more of the the top minds to manage and build this out.
00:15:15.875 --> 00:15:25.504
Um, so there is a lot of benefit to to going, uh, just the you know, full-on, full-on cloud cloud has become a commodity.
00:15:26.408 --> 00:15:26.708
It's a.
00:15:26.708 --> 00:15:28.173
It's a logical step to take.
00:15:28.173 --> 00:15:35.177
But if you would look forward, maybe 10, 15 years ahead, what would you think the world of cloud would look like?
00:15:35.605 --> 00:15:35.846
the.
00:15:35.846 --> 00:15:41.937
The rate of change at the moment is um in in certain areas.
00:15:41.937 --> 00:15:43.399
I think the obviously the.
00:15:43.399 --> 00:15:48.375
The most striking one of that is ai, um, the.
00:15:48.375 --> 00:16:00.297
The rate of change there is just exponential and I think for a lot of analysts even it's difficult to predict what's going to come next.
00:16:00.297 --> 00:16:08.296
But if I look back on what are the sort of things that have been changing the industry over time?
00:16:08.846 --> 00:16:11.615
It's always
layers of extrapolation.
00:16:11.615 --> 00:16:16.777
So we started with on-prem individual servers.
00:16:16.777 --> 00:16:18.270
You manage each one individually.
00:16:18.270 --> 00:16:23.211
At some point there was a layer of extrapolation which was your hypervisor.
00:16:23.211 --> 00:16:28.327
Now you can manage a fleet from a single point With cloud.
00:16:28.327 --> 00:16:40.953
That's just amplified a lot more and you're doing all of this through a, you know, either through code or through a console in any part of the world.
00:16:40.953 --> 00:16:45.817
Ai is sort of the next step.
00:16:45.817 --> 00:16:49.712
That's happened where you can can in natural language.
00:16:49.712 --> 00:17:13.291
Instead of having to know anything or click anywhere, you orchestrate a lot of the stuff just in natural, natural language and I think it's going to uh get to a point where it's things are so fluid that you don't really you know your knowledge of what happens in the back end will be so far removed because of all these innovations that you know.
00:17:13.291 --> 00:17:31.038
I just think that the way that we know to manage, deploy and use your cloud environment any environment actually will change so drastically that it might not be recognizable to us in 15 years.
00:17:31.945 --> 00:17:43.414
I was thinking while you were explaining that I agree with you, and if you look at AI, then it usually starts with a good foundation and data is very often used as then the answer.
00:17:43.414 --> 00:18:00.058
But in this case, if I heard your story about managed services in the cloud, then what you're actually doing is you're standardizing, you're improving, you'll make it more efficient and it almost sounds like this is a good base also to apply ai yeah, absolutely.
00:18:00.865 --> 00:18:07.432
Um, you know, any anything that you build is only as as good as the foundation that it's built on.
00:18:07.432 --> 00:18:10.016
Ai is no different.
00:18:10.016 --> 00:18:21.431
There's definitely a lot of use case where I think, with cloud services specifically, they sort of tend to live outside of your infrastructure.
00:18:21.431 --> 00:18:29.258
If you look at the pure serverless sort of technologies, ai is one of those things that in many cases can stand alone.
00:18:29.258 --> 00:18:33.411
Um, but you know the data that it's accessing that still needs to.
00:18:33.411 --> 00:18:47.308
You know it needs solid foundation and, um, I think everything is not at the point yet where it can seamlessly consume any sort of data in any sort of format.
00:18:47.308 --> 00:18:59.450
There is still preparation that needs to happen cleaning up, making sure that whatever you're feeding in into these models is accurate, because if you put nonsense in, you're going to get nonsense out.
00:19:00.025 --> 00:19:06.155
We cannot do LLMs without the cloud, unless all LLMs would be very limited in scope.
00:19:06.155 --> 00:19:09.094
So the two sort of go hand in hand too.
00:19:09.625 --> 00:19:14.951
Yeah, and I think adoption of it definitely will be very limited if it wasn't for cloud.
00:19:14.951 --> 00:19:18.394
Any consumption model just makes things so much more accessible.
00:19:18.394 --> 00:19:41.698
If you look at some of the technologies that are available, I would say something like 60, 70% even of companies wouldn't be able to use these things if it wasn't for the cloud model, which made it more cost effective as well as easier to consume than building it yourself.
00:19:42.545 --> 00:19:50.736
Werner, just as a last question to you, because you gave us a lot of insights on how to handle cloud managed services.
00:19:50.736 --> 00:19:52.990
How can people contact you?
00:19:53.545 --> 00:19:58.785
The easiest way is to reach us via the, via the website.
00:19:58.785 --> 00:20:01.615
It's cloudbbdsoftwarecom.
00:20:01.615 --> 00:20:07.049
Any one of the pages will link you through to, to to a contact us.
00:20:07.049 --> 00:20:11.372
But that's cool, that's's the easiest.
00:20:11.372 --> 00:20:12.314
Come straight to us.
00:20:13.056 --> 00:20:13.376
Excellent.
00:20:13.376 --> 00:20:15.792
So thank you very much for your insight.
00:20:15.792 --> 00:20:22.037
Thank you also to the audience and please stay tuned, as we're going to give you more tech unboxed in this channel.
00:20:22.037 --> 00:20:23.185
Thank you so much.