This automatically-generated transcript is taken from the IT Pro Podcast episode ‘Building recession-proof architecture'. We apologise for any errors.
Rory Bathgate
Hi, I'm Rory Bathgate.
Jane McCallion
And I'm Jane McCallion.
Rory
And you're listening to the IT Pro Podcast, where this week we're discussing recession-proofing.
Jane
As we enter what is set to be a long recession, businesses are looking to manage and reduce costs wherever possible – including in the IT department.
Rory
More than ever, companies are evaluating the benefits and drawbacks of serverless architecture, the best payment models for their business, and the risks associated with vendor lock-in amidst uncertain financial conditions.
Jane
Today, we're speaking to Tom Fairbairn, distinguished engineer at event broker Solace, to explore the financial risks associated with lock-in, and how businesses can use low-code, serverless solutions to upskill people.
Tom Fairbairn
Hi, Rory. Hi, Jane. Thanks for inviting me on. I'm excited to be talking to you guys about this.
Rory
Thanks for being here. So late last year, the Bank of England said we're officially in a recession, and they expect it to last for about two years. Many companies have been taking steps to prepare for this even before the official announcement was made. So what are some of the main ways that this is translating into decisions in IT departments right now?
Tom
Yeah, that's a really interesting question. One of the things I think we're going to see going forward is that IT and technology has been seen up to this recession as kind of the big growth area, especially during the pandemic, I think this may flip us into a situation in which our IT departments and our technology departments are going to face much bigger constraints, especially around financial constraints in a way that probably we've not been used to for, who knows two, five, ten years. It's going to be quite an adjustment for us all, I think.
Rory
So some of our listeners might be familiar with the term serverless, some might not. So just for those who aren't, could you go over sort of a basic definition of what serverless really means?
Tom
Sure, it's interesting. I looked up a few definitions, and there doesn't appear to be one single phrase you can use. But really how I think of serverless is an evolution of the cloud model, and a kind of, at the moment it's kind of the ultimate cloud model. And what serverless is, it's a cloud technology of an execution model for your business. So what that means is, instead of paying the cloud vendor for some computing resource, you're paying them to execute something you give them. Now generally what that is, and this is the power of serverless, is you can just write some business logic and give that to the cloud vendor and say "execute that". That's really powerful, because you're not worrying about operating systems and storage and stuff like that, the environment takes care of that for you. So if you think about it, in kind of owning a car versus hiring a car versus hiring a taxi, obviously your on premise data centre is owning your own car, your on demand compute, is hiring a car, I'm going to hire a car for a day. And what you do with it is up to you. Versus hiring a taxi. When you hire a taxi, you say where you want to start, where you want to go, and all you're paying for is that particular trip. And that particular trip in this case, is executing your business logic.
Rory
So it's a far more focused sort of narrow model than even a sort of elasticity model.
Tom
It is yeah, one of the key points of that is that you're only paying for your execution time, right? So like the taxi trip, you're paying just to get from A to B, you're not paying for the fact that you have a car available to you for a certain period of time. And that's a key point. One of the things about it is that it's elastic. So that's different from scalability, right? It's not just that the processing of the execution increases the more than demands you make of it, you only pay for the execution when it happens. So it scales down when you don't need to execute. So it's a great model for businesses with seasonal demand, for instance, so retail sector. You know, Happy New Year, everyone we've just come out of the Christmas period and I doubt the run up to that, hopefully, for most of us was busy, right? If your demand tails off for the rest of the year, it's a great model for being able to kind of elastically scale with that without you needing to worry about what scaling needs to happen.
Jane
So serverless solutions, and particularly those that are available on consumption based models, everybody will be familiar with from any kind of cloud type stuff. They'd already been increasing in popularity recently. Is this something that might appeal to companies more during hard financial times such as these or is it a business or a technology choice or a bit of both? I guess.
Tom
So it's like the cloud itself. Actually, it's a business model that has driven a technology change, just in terms of kind of adoption. I saw a survey from Datadog that was saying that 50% of organisations that are in the cloud, have already adopted serverless in one way or the other, right? And whether that's from your kind of your bottom, basic serverless, which is you know, your function as a service, something like AWS Lambda or Google Cloud Functions, all the way through to the more advanced things like app runners and stuff like that. So it's tempting to think of this as, like one of the things I always talk to people about is if your CIO, CTO, CFO comes to you and says, "we want to adopt serverless, as an operational cost reduction", you're in for a hard ride. Okay, so serverless, the benefits of serverless around cost aren't really around operational cost. The benefits of serverless, I think people should think of them are more around agility, time to market and moving quickly, right? If you've got an existing application landscape, and you want to reduce the operational cost of that, just moving that to serverless is not the right way to go in the same way that in existing legacy infrastructure, if you just lift and shift that to the cloud that's not probably not going to give you an immediate operational cost, operational saving rather, that's probably going to disappoint your stakeholders. Where serverless really, really helps out organisations is getting to market quickly. And whether that's through an entire application suite or adopting, coming to a new use case bringing in some new kind of digital transformation. So engagement with customers, for instance, it enables you to do that a lot quicker. Now the kicker is, what many organisations I've spoken to is, yes it gets you there quicker but there's a cost associated with that. So we talked about the idea of vendor lock-in. There's also often, funnily enough, an operational cost in that, you know, you're buying a lot of abstraction and you're buying a lot of risk reduction in your live queue. And that kind of doing this execution, in an environment that's provided for you on an on demand basis, generally on demand, things are going to be more expensive, right? Once you start scaling them up. So a good example is it's like owning a car, versus hiring a car for a day, which is kind of your elastic compute model, versus hiring a taxi for a particular job, which is kind of your, you know, your serverless model. If you just have that one trip to go and get some groceries because your cars in the garage. That's, you know, that's probably economically worthwhile. But if you're running the children to school every day, maybe hiring a taxi every time is not the way to go.
Jane
You'd be surprised. So if I go back to the beginning of your answer really, if there isn't a direct cost saving as such, it's slightly more abstract for want of a better word. How can you either as an IT professional make that case to line of business serverless is the way to go? Or conversely, explain to line of business if they come crashing in and say "we want to do this thing that we just read about that there isn't a direct cost saving, but that it's probably still worth doing it" and, you know, good on them for their enthusiasm.
Tom
Yes. Congratulations, Mr. CIO, you know, I'm glad to see you got the pulse on things. It's like everything, right, this comes down to what is the benefit for the business? What is the business use case? What is the business business plan for this? So on the subject of like, how do we get, how do we get an organisation that maybe isn't thinking about this to adopt this? Well, it comes down to simply okay, here's the use case, we want to improve our customer engagement, improve our omni-channel experience. We need to maybe integrate, you know, a couple of different channels. Simply the use case for serverless here is we will get this project done quicker. Because we're not going to have to stand up servers, we don't have to capacity plan, it's going to be elastically scaling, so we don't have to worry about quiet periods because it will scale down as well as scale up right? So we're we're going to get this project done in three months rather than six months.
Jane
So I guess in some ways, it's sort of a go to market type thing then really.
Tom
It's entirely around go to market. If you look at the really successful people who ever who have adopted serverless, not just as a tactical kind of glue logic thing, which is to my mind what I've seen is actually the majority of use cases so far, because adoption is, you know, kind of going through that maturity curve. If you look at the the organisations that have adopted serverless strategically, the reason they've picked it strategically is entirely around time to market. You know, opportunity cost, and not around operational cost. So it's easy to think, oh this is the problem we sometimes get when you're talking to people is they're all thinking about operating cost. They're not thinking about opportunity cost.
Jane
That's been the gospel of cloud, hasn't it? Move from CapEx to OpEx. And now we're moving from OpEx. Onwards, onwards We go. Yeah.
Rory
So it sounds like serverless is currently a balance between that speed and reaction time and the long term economic sustainability of such a model for business. Would you say that serverless is maybe a good way of reacting to uncertain economic conditions, but not something that businesses are looking to apply to absolutely everything in their architecture long term?
Tom
Yeah, that's a great summary. So it is a brilliant enabler of dealing with uncertainty, because it scales down very easily and the costs scale down very easily, almost without you trying. And in uncertain times, often, you need to react quickly as you say, to perhaps new opportunities in the market. Perhaps these new opportunities in the market are short lived. And so you need to get to them quickly. That's a great time to use a serverless approach to things.
Jane
So turning to another sort of more recent technology, or more recent way of doing things, let's have a talk about low code and no code. So once again, could you just explain this a little bit to our audience? Because I remember the first time I came across the idea of no code, much like the first time I came across the idea of serverless, I was like, "well... how do you do this? You're not writing any code, you're not getting the infrastructure?" Yes, low code, no code.
Tom
Yeah, so low code, no code solutions typically present the developer with an interface that enables them to implement their business logic without having to write specific code. So typically, what you have is some kind of graphical palette, where you will implement whatever function you need to, you need to implement it but in a graphical way. So it's more of a configuration rather than writing code. And the environment takes care of providing what needs to happen for that graphical shape, if you like, to run. So this is often really useful in things like integration spaces, for instance, where you need to take something that's happening in say, a third-party tool and feed that into some internal tool, for instance. Rather than writing a whole bunch of code it can be quite simple to, say, bring a connector shape onto your pallet to connect out to your third-party service, bring in some kind of transformation shape that takes that data and does — let's take an example — masking a credit card number field or a CVC field or something like that. And then output that to another connector shape, which is then going to feed it into, say, an analytics platform. Something like that.
Jane
So it's almost like a flowchart type thing.
Tom
That's probably the easiest way to think about some of the more common approaches to this. Yeah.
Jane
And who will be, I guess, using low code / no code? Have we put all our programmers in the bin, and everyone's had it? Or is it still sort of their, their domain?
Tom
Yeah, so who's using these platforms? So on the low code side, are we binning kind of coders developers? Probably not. This is more for organisations that have tactical needs, typically around things like integration. So you see, the iPaaS vendors, like Boomi for instance, will provide these kinds of platforms. So these are not companies generally, these are not use cases maybe that are seen as completely strategic to the business, in providing a functionality that nobody else can provide. It's more typically used, you know, in integration style of use cases. I mean, possibly a technology in this space is things like RPA, where you're looking at automating what a human would have done, as opposed to writing a completely new piece of code that does something that's either unique, or there is no tool in this space. Right? If you look at the serverless space, it's a mistake to think of serverless as a kind of low code. Actually, in terms of development serverless is pretty tricky. You know, developing for serverless is actually probably harder than developing on your own machine. It's difficult to debug, it's difficult to understand the performance implications. You know, the cloud vendors do a great job of providing that information. But you need to know what you're doing, right? In the serverless space, you have to think about how your serverless thing is going to be triggered. And that leads people on to this whole idea of event-driven architectures, right? Serverless is generally triggered by events, event driven is seeing a lot of adoption recently. But you know, for many organisations, it's very new. And it's a different way of thinking for developers. So generally, it's more advanced organisations, advanced developers that are adopting EDAs, which allow them to really get the most benefit out of serverless. Low code, on the other hand, that's more citizen that's aimed at the citizen developer. Right? So that's more aimed at organisations that don't have a lot of developers, maybe they would have contracted an SI, for instance, to build some code for them. And to, you know, maybe to operationalise it for them. Low code enables them, especially in kind of you know the iPaaS space, it enables them to give their business people who maybe understand data, you know, it gives them an environment that maybe they might find that easier to do.
Rory
So, on that point of the citizen developer, it's been suggested by some that low code could be a good route for training, for upskilling. And even for reskilling. I know we mentioned it briefly in the introduction, but do you think that this is a viable pathway for maybe training up a new cohort of developers, or even avoiding the need of hiring more developers all together?
Tom
So I think it's certainly a good approach to get people who wouldn't traditionally have seen themselves as developers into that, not developing space, but certainly the more IT space. So I see low code as potentially a way of integrating IT into business. I see low code as a way of integrating what were traditionally seen as IT functions more into the business, because you're bringing kind of people from the business into this space. As long as they understand the data and have a basic understanding of where data should flow from, what are important parts of the data, how data needs to be manipulated, they can probably use these no code platforms, right? So on the subject of upskilling, I don't think low code is a way of getting green employees into the IT department. But it is a way of extending businesses' reach into it, and IT's reach into the business.
Jane
So I guess is the benefit then of low code and no code, in this economic climate that we're entering into now or did at the end of last year, similar in some ways to serverless? That it's not about getting rid of people, it's not about replacing people, it is about speeding things up a bit, taking the load off your IT department and allowing them to do other stuff. Or indeed potentially not having to fork out so much for external contractors.
Tom
Yeah, so I think there's several aspects there. There's the idea that maybe you wouldn't be employing quite so many SIs to write code for you, because you can do low code yourself. Maybe the management aspects of it are simpler, because you're not having to commission an IT project to do this, maybe you can hand this over to perhaps there's some people in the business that are maybe less busy than they were. And so they can get more involved in this. I've got personal experience with this, actually, my brother is getting involved in kind of an IT-style project much to his disgust and my delight, for this kind of reason, right? So I think low code enables a lot more flexibility in the business, because as we talked about the kind of the skill aspects, it does extend out. Not to a huge degree, you're not going to have everybody in the business suddenly writing low code stuff, right? You do need, you know, a certain mathematical skill set that you would need to kind of interact with computers in this way anyway. But it does give a lot more flexibility. So IT people that are maybe really focusing on reducing the operational cost of a legacy system can maybe concentrate on that, while guiding their business colleagues using this low code environment to maybe move some new projects on forward.
Jane
So I guess, you know, from the point of view of these other employees, that might be a bit of an opportunity for them as well if they're a bit sort of technically minded but in another department. You know, I've seen this myself with people who I know moving from, let's say accounts actually into the IT department, because they have the aptitude and the willing for it even if they don't have the training. Is it a pathway, I guess, for those kinds of people?
Tom
Yeah, I'd say so. And it's interesting you say accounts, right? So immediately, I'm thinking, you know people in finance departments generally they're numerate, generally they are used to abstract thinking. So, you know, it's ideal for people like that. And as you say, I mean, personal experience here with my brother right? That's exactly the path he's following. He's in a finance department. He's able to draw up dashboards and understand what the data is that feeds that dashboard, right. And he's using a low code environment to do that. Yeah, another kind of cohort of people that will find this kind of concept appealing, are maybe those in the scientific or data domains, right? So anybody that's in economics, statistics, anybody in the science domains that aren't already using things like MATLAB to do a lot of scientific and statistical analysis, right? If they're needing to feed things into the business, they will probably find this low code kind of platform, useful too.
Rory
So it really has to be done maybe has more of a cross-silo operation within the same company, less than maybe an onboarding thing? I know that a lot of companies looking at hiring freezes right now, as we've been saying in kind of in a recession, looking at actually cutting spending. But that maybe they can assess moving some people around within the company into positions that are more more beneficial, as long as they've already got that kind of core skill set that we've discussed.
Tom
Yeah, I wouldn't say this has to be cross silo. But I would say that it's a good opportunity for that. A danger is when you're dealing with more regulated entities, organisations that have a lot of privacy concerns. There is obviously some danger here about how this data is used in the awareness of privacy concerns and regulatory concerns. So we talked about the idea that this might be, you know, attractive to people in the scientific domain. You can imagine in a pharmaceutical company, there is a risk there for instance that you don't want to leak, leaking clinical data or patient information. Right? So while it is attractive, as with everything, there are risks to it too.
Rory
So we've talked about serverless architecture, we've talked a bit about some of the different options that businesses are having to assess. And in the intro, we briefly discussed vendor lock-in. In the current economic climate, would you say that it's better for businesses to embrace a diverse range of architectures or really to sort of concentrate on one and put all their efforts into it? While keeping in mind this, maybe this worry about vendor lock-in?
Tom
Yeah, it's as with all these answers, it depends right? If you're attacking the time to market challenge, let's say you're a startup. And you you're coming up with a completely new feature, you need to write a lot of your own code. That's an ideal use case for a serverless architecture. And that's going to build on you're probably, because this sounds like a kind of greenfield thing, you're probably going to build that on top of an event-driven architecture right? Now, in my experience, what happens is you grab a bunch of market and then the, you know, the organisation expands, and what often happens is operational costs, in this particular case, cloud costs of running this serverless architecture. They start to explode, right, because you're moving from a very bursty and very on-demand model into a business that's maturing, the demand is becoming more, you know, more plateaued, hopefully growing but it's going to become more steady. And that's the point typically, at which CFOs, start getting itchy and we need to start architecting re-architecting a little, maybe we'll start to back off some of our more core functions that are running more at the time. Maybe we need to re-architect them, refactor them to be less serverless and more kind of static services sitting there servicing requests. So like a micro service or something like that running on elastic compute. But that's fine. That's part of the inevitable maturation of any architecture, right? And we should be doing this, we should be constantly looking at our architecture and deciding what is the best approach going forward. Now that's for, you know, an organisation that has a deep technical challenge that they're trying to solve that potentially hasn't been solved by anybody else. And so they're writing big chunks of code that just happens to be running in a service architecture, because that is the best way of dealing with the business model. If you look at more mature organisations and organisations that perhaps aren't as technically led, so you look at your typical manufacturing shop, or consumer goods manufacturer, or logistics providers. People like those, obviously, they have big technical needs, but their technical needs that are probably better served by third-party applications. And they're the probably, it's going to be more the low code approach. Now, with serverless, there is at the moment, a large degree of vendor lock-in. There are standards around this, but as far as I can see they're not being widely deployed or adhered to. On the low code side of things, you do have a less degree of locking, because basically you're picking a low code solution. If that one works for you, great. If you feel that there's a problem with that, you can always adopt another low-code solution and run them side to side. And that's, I'm not gonna say it's easy to do. But I'd say it's easier to do than deploy necessarily to serverless solutions. There is a third way in between this. I think we're seeing in the market a lot more maturity around cloud models, and the move to hybrid cloud, and multi cloud, where you see that one cloud vendor provides a particularly good service service and another cloud provider perhaps provides a particularly good data analytics kind of capability. The idea of being able to operate in that multi-cloud model is becoming more, it's gaining popularity. The key there is how you communicate between your on-premise cloud and multi-cloud environment, especially in an event driven architecture, right? And there are solutions that enable you to do this, helps to mitigate the vendor lock-in problem. It doesn't deal with it completely, but it certainly gives you a lot more options.
Jane
So another sort of buzzword, trend, however you want to think about it for the past couple of years has been digital transformation. Is serverless architecture, or indeed low code / no code, a long-term cure I guess, for firms who are struggling with digital transformation? Or is it a false hope?
Tom
Interesting question. I mean, the first thing I'd say is, if a firm is struggling with digital transformation, serverless is not the way to go. Not yet. Right? You need to be, with respect to digital transformation, you need to be quite mature, have a good developer team and a good architecture team to really make the use of serverless strategically. You may find there's some tactical uses, a bit of glue here or there that you might use serverless for, but what would I would advise that kind of organisation is you probably want to be looking at a low code solution. Because it will be a lot easier for you, there's less architectural things you need to think about, and it gives you more opportunity to just concentrate on fulfilling one particular use case at a time. Now, is it a magic bullet that enables you to do digital transformation? No. But then again, I don't think anything really is. Digital transformation, a bit like people think of cloud as a technology where actually it's more of a business model, digital transformation I think is more of a cultural thing. It's about how the business operates than it is a technology. And we need to think about these technologies as enabling digital transformation, rather than being the digital transformation.
Jane
Yeah.
Rory
So as with kind of the range of things that we've discussed throughout the episode, it's more of a business strategy, business culture that each individual company is going to have to very carefully assess, rather than just stick it on as a kind of a sticking plaster for the recession and hope that things just 'get more digital' and improve in that way.
Tom
Yes, exactly. I mean perhaps, I don't know, I'm kind of speculating here. But perhaps the recession is an excellent opportunity for companies to really focus on what digital transformation is and what it can do for the business. So one of the problems with any, you know, initiative is that it's going to cost money to do. Digital transformation is going to cost money to do. Now what it can do, is it can unlock value in your customers and suppliers, and it can produce operational efficiencies. Maybe you know, because times have been good, maybe you've let the operational efficiency slide while you try to grab market. Maybe this is good opportunity to look at your operational costs and not look at, you know, low-code digital transformation or service as an opportunity to reduce your IT costs. But maybe it's a good opportunity to say we need to transform these parts of the business in a way that enables us to cut out manual processing, in a way that enables us to engage with customers without having to build up huge customer support teams.
Jane
So I suppose it's one of those things with the business, it depends on their strategy for dealing with the economic climate, you know are you going to batten down the hatches hold on, and open the doors again in two years time, or whenever we get out of this. Or are you going to try and invest your way out of a recession?
Tom
Exactly. Right. And if... digital transformation is disruptive, and it's going to disrupt your business, in that you know, you're implementing a new way of dealing with your employees, your customers, your suppliers, your business processes, and everything. So perhaps this is a golden opportunity to hopefully take some of that cash you've built up during the good times, to make yourself more lean and agile during the recession. I mean, this reminds me actually, it's probably a bit off topic. But I remember seeing an advert on TV years ago about TV advertising. I've noticed the TV is now advertising for TV advertising again. But it had a really nice metaphor, and that was a kind of basketball bouncing up and down. And the hand that was bouncing the basketball up and down was TV advertising. In this case, it could be it and digital transformation, right? If you stop investing, yeah, you don't have to put so much effort into bouncing the ball. But the ball is going to slowly reduce the size of its bouncing. And if you think about that, in terms of your business that's a good metaphor.
Rory
Well Tom, thank you so much for being on the show.
Tom
Thank you very much. It's been really great to talk to you guys, really interesting discussion.
Jane
As always, you can find links to all of the topics we've spoken about today in the show notes, and even more on our website, it pro.co.uk
Rory
You can also follow us on social media, as well as subscribe to our daily newsletter. Don't forget to subscribe to the IT Pro podcast wherever you find podcasts. And if you're enjoying the show, why not tell a friend or colleague about us.
Jane
We'll be back next week with more from the world of it. But until then, goodbye goodbye.
