Episode 7 Jun 18, 2020

What is True Cloud-Native and Why Does it Matter for Business Outcomes?

Zilliant Chief Technology Officer Sham Chauthani joins the podcast to talk about cloud-native B2B solutions – what they are, why some that claim to be cloud-native are really not and, most importantly, how they drive better business outcomes. Shams details the role a microservices, cloud-based architecture plays in a business as it grows and evolves. Stay through the end for specific pricing and sales use cases that are solved via cloud-native technology.

Find the real-time market pricing video mentioned in this episode here.

Featuring
Shams Chauthani

Shams Chauthani

What you will see is a lot of the monolithic applications that are out there that may still claim to be SaaS will tend to have very infrequent release cycles. And that usually is a dead giveaway for me: if you're not getting an application update for six months, it's unlikely that it's a cloud-native platform.
- Shams Chauthani, Zilliant

Episode Transcript

Barrett Thompson: Welcome to B2B Reimagined. My name is Barrett Thompson. I lead the [00:01:00] business solutions consultants at Zilliant, and I'll be your host for this episode. I'm really excited today to be joined by Zilliant’s Chief Technology Officer and Senior VP of Engineering, Shams Chauthani. Shams, how are you doing today?

Shams Chauthani: Doing fine.

Barrett Thompson: Thank you so much. There's a topic that has been on my mind and I know you're the person that can help us sort through it. A lot of what goes on in the technology marketplace, market space, it's loaded with terms and labels. And software vendors out there - they're fond of picking them and trading them, if you will, in the marketplace with customers and so on. And over the last few years, I've seen the trend that's happening in technology, and I hear different kinds of labels on top of them.

And I want to get a better understanding so I can sort among them. For instance, I hear some people saying, “I've got a subscription offering.” That's what some software vendors will say. Some will say “I have a SaaS solution.” Others might go so far as to say: “I'm a cloud-native application.” [00:02:00] And I feel like there's some substance here.

Maybe we should spend a little time drawing that out and helping our audience understand what those differences are and how those differences might matter to them, if, and when they're in the place where they're searching for a modern, modern technology kind of solution. Is that something you can help us with?

Shams Chauthani: Yeah. I’m glad to do that. I agree with you that I think when it comes to technology marketing aspects of the technology itself, I think sometimes with terms get blended in terms of, what is SaaS, and SaaS in the past five years has been a very popular way of delivering software. Just about every company now offers a SaaS offering, but when you peel the onion a little bit, and you look at the layers underneath the covers, what you find is there's a lot of variation in terms of what these companies’ offerings really mean when they say it's a SaaS offering.

And for instance, some companies have taken their [00:03:00] traditional enterprise software and started hosting them into one of the hosting providers. And they called out a fast offering, which technically it is because they're charging for subscription, but in terms of the actual underlying technologies themselves, they still are that monolithic enterprise software that's always been.

 

Barrett Thompson: Could I ask on that first one? For instance, in that case where someone's taken their classic on-premise offering and just stood it up on their hardware, not yours, but then charge you a monthly fee. That really feels more like a financial model than a technology model than a technology model. Would that be fair to characterize that as a ‘subscription’ from a financial point of view, but it's certainly not a ‘SaaS offering’ from a technology point of view?

Shams Chauthani: That's correct. And I think ultimately where this becomes important, as from a technology perspective, when we talk about the new SaaS world, there are a lot of technologies out there and a lot of capabilities, especially on the cloud front that are coming to the market [00:04:00] that make the job of software developers and software delivery companies much, much easier than it has been in the past.

But in order to do that, you have to have the right architecture and the right underlying way of utilizing those cloud-native technologies. And so, when it comes to being SaaS, certainly there's a financial setup aspect of it in terms of, ‘is it a subscription-based business or is it a sort of a permanent licensing type situation?’ Certainly there are a lot of companies that are offering SaaS solutions, but they are more focused on the financial aspects of how that arrangement works. But then underneath the covers, they may or may not have the full cloud-native capabilities that really allow you to take advantage of all of the technological innovations that are coming down the pipe on the cloud-native.

Barrett Thompson: Shams, I like where this is going and what I'm learning. Let me ask this: Help us out with a characterization of what is a cloud-native [00:05:00] application? What do you think of first or foremost to know something's cloud native?

Shams Chauthani: Yeah, that's a great question, Barrett. The way I characterize something as a cloud-native application or platform is I look for three attributes:

The first attribute is the underlying architecture of the application, whether it's a traditional enterprise monolithic application or it's a modern microservices architecture. And we'll talk a little bit more, hopefully, about what are the benefits of one versus the other. The idea being, that you break down the components of your application into individual services that can all function together to deliver the value that you're delivering to your application or the platform, but they can individually be enhanced, can scale and other things that are possible to the microservices architecture. That's the first attribute that I look for in an application.

The second thing that I'm interested in seeing in that type of cloud-native environment is [00:06:00] whether we're leveraging the capabilities of the cloud. A lot of times, people simply take their application and host that into cloud computing. Again, from the perspective of actually deemed benefit or leveraging the benefits of the cloud, just hosting in the cloud doesn't give you any of the inherent benefits that you get from all of the different cloud technologies.

What I'm looking for is: Does the application or the backbone actually leverage it? …the underlying technologies and capabilities that the cloud has to offer… Ideally the whole aspect of the cloud is that it is being used underneath the cover, we’re leveraging a lot of different capabilities from there, and bringing that together in terms of how we are managing the application. That's the second attribute that I've looked for.

And the third thing I'm looking for is the concept of loose coupling. And the idea there is that I want to make sure that we're not technology-locked in terms of how we've architected the solution.

And specifically in terms of that there's a lot of [00:07:00] technical innovation going on. And especially in the big data space, there's a lot of new database technologies and other types of technologies that are coming out. And I want to make sure that we design the system in such a way that we can easily swap out different pieces of the puzzle and be able to continue to take advantage of the technologies that are coming out in the future. And being able to do that requires a specific way of putting together your solution and the technolog.; And certainly, that is different than how traditional software had been done.

Those are the three factors that I look for to understand if an application is truly a cloud-native application - as something that is going to be able to take advantage of all the different things that are coming together that can confluence of all of the different things in cloud that are happening in the marketplace.

Barrett Thompson: Right. Okay. Let me take that last one. You mentioned the loose coupling and not letting your technology get locked. Can you give me an example of where [00:08:00] that's happened in our world and the solution we put together for Zilliant? That might be one this audience could easily identify with.

Shams Chauthani: Yeah, I'm glad you asked about that because I think that's a great example and a great way to demonstrate the value of that particular attribute of a cloud-native application. I think you're familiar that, traditionally, we've used the relational database and Microsoft SQL server database: Bringing the data into our system, do some other data processing that we do, and even run the models off of a SQL server. As you can imagine, over the last 15, 20 years as we've grown, and we've worked with a very large set of institutions that are leveraging our solutions. The need to bring in more and more data and process larger amounts of data and become a real sort of challenge or even became a bottleneck for us to be able to be responsive to our customers.

And so specifically, in terms of very large customers, with billions of transactions [00:09:00] they were sending us on a regular basis, sometimes processing those billions of transactions took us 20, 25 hours in order to bring the data into the system, run some algorithms on it and things of that nature.

In the real-time world that we live in, that's a long time. One of the things that we looked at is: What are the advances that are being done in the marketplace, in terms of handling big data and the capabilities that were being offered? And being on the AWS platform, one of the things that we looked at is what their AWS is offering for data warehousing - called Redshift. And with that particular technology, we were able to see how that would fit into our solution. And because of the way we've architected our solutions, we were able to bring in Redshift into the architectural landscape that we have within our application and started transitioning some of the data load work that we were doing - and especially the types of things that we're doing in the data [00:10:00] cleansing and feature generation type work - where aggregations and other things were really important. And we offloaded that to the Redshift clusters that we brought on. What we were able to do is to reduce operations that used to take 20, 24 hours down to 20 minutes or less. And we were able to do that in a fairly seamless manner without having to rearchitect the application or completely redo how the applications that are underlying models and other things work.

It's a testament to the premise that I talked about, which is technology is going to evolve over time. You want to make sure that your applications can keep up with that technology innovation that's coming in and take advantage of it and to be able to do so without having to basically go back to square one and rearchitect your solution.

Barrett Thompson: Yeah, that's a great example. I had a mental image as you were talking, it's like swapping out the jet engine on the aircraft while you're flying, right? We're going to put a bigger engine on it. And by the way, [00:11:00] people sitting in rows 10, 11, 12? They're not going to notice anything. Right?

With our customers, we didn't take the solution down or have to reconfigure for them or anything. We just stood up a more powerful underpinning, and in one of those layers, because of our loose coupling, they were the beneficiaries of that. That’s fantastic.

Shams Chauthani: That's obviously very critical for us. Our solutions are mission critical for our customers.

Making sure that we can do this in a seamless manner is really important. And that's where some of the benefits of our microservices infrastructure comes into the picture a little bit. As I mentioned, one of the other tenants of a cloud-native application is our microservices architecture. And the reason is, an important factor that I look for in an application design is specifically for that knowledge, that you used about replacing engines in mid-flight, is because our application is broken up into a lot of different services.

Were you able to actually [00:12:00] create new services, and plug in those new services in parallel with what's currently there and make sure that things are good? Maybe try out parallel transactions and things of that nature? And then when we feel comfortable, be able to flip a switch to go to the new way of doing things? In the traditional monolithic world, you just don't have the luxury of being able to bring in a new service, have it have some sort of a burn-in time and be able to evaluate whether that thing is going to work the way you want it to work, and be able to swap over to it when it's appropriate. It’s just something that's really difficult to do in a model of the tech world. But it is a piece of cake and the microservices type environment.

Barrett Thompson: How about that second characteristic? I think you described it as leveraging the benefits of the cloud. Give me a little more on that.

Shams Chauthani: Yes, absolutely. In the example that we talked about of switching from SQL to Redshift, that [00:13:00] in itself, was an example of that, in terms of, we didn't go out there and try to build a massive cluster, like PostGrest services and things like that underneath the covers. We just leveraged an AWS offering where AWS manages all the complexities, or how to host that particular dataset, how to scale it and things of that nature. Another example that I'd like to point out in that regard is a marriage of both the microservices world, as well as the ability to leverage the underlying cloud infrastructure.

That's to talk a little bit about our scalability of our APIs, specifically in terms of… we've got customers that are leveraging our APIs to integrate our pricing guidance and sales guidance into their CPQ solutions, in some cases, their ERP systems and other things. And so, in that situation, what we run into is that the scalability of our solution has to be able to meet the needs of our customer. The [00:14:00] stability of our system is really important. We offer “four nines” (99.99%) SLA on our APIs, which literally means seconds of downtime a month. In order to deliver that, our API infrastructure is built on the microservices architecture.

And then underneath the covers, we're using Amazon's ECS container service to host our microservice containers. Using that ECS container service, we're able to leverage the capabilities that it offers. For instance, it has auto scaling built into it. The idea is, if you have a container that's serving up one piece of our API infrastructure, and we detect that we've got a heavier load on that particular service, using the ECS configuration that we've set up, we can auto scale that particular service and add additional containers to serve up that traffic. We can also do health monitoring of those containers to see if any of them are behaving erratically, or if [00:15:00] there are any issues that we see within those containers easiest and help us take them out of rotation and auto-generate new containers that can serve up that traffic.

So again, using a microservices architecture, and then leveraging the capabilities of the cloud platform, where things like ECS can really help us get all the right pieces in place to be able to serve our customers, and our API customers, provides them high level of reliability. And do that in a scalable manner.

And because of the way we're structured, we can offer a virtually unlimited amount of scalability. You've got customers that have thousands of salespeople that are using our pricing guidance on an ongoing basis. Being able to actually stand-up infrastructure and do it in a manner that allows us to scale and be reliable is something that we wouldn't be able to do if we weren't using underlying clock technologies in the micro services architecture.

Barrett Thompson: Yeah, [00:16:00] those are important things. We have so many customers who start with one continent or start with a few countries, and then when they get the vision, they're ready to go wide or they want to add another business unit or price mode. The ability to turn that on and double the scale or triple the scale certainly satisfies me, knowing that I can commit to them. Yes, we can do that. Our scalability is built to do that right from the start.

Shams, as we've been talking, I know that for IT teams and others who are close to technology, they have a pretty good background to appreciate the way that we've characterized what cloud-native is and how that it matters. But often, I'm talking to people who are not so close to the technology. They don't have that background. And I feel like there are some benefits that we can pull out and translate for someone who might be a vice-president of sales or a director of pricing, or a CFO who's looking at [00:17:00] the P& L and margin improvement and so on.

What are some of the things that cloud-native solutions will translate into a set of tangible or observable benefits that really anyone familiar with the business could appreciate? Are there some top-of-mind ideas that you have?

Shams Chauthani: Yeah, absolutely. We didn’t build a solution specifically to be an elegant solution that we can all be proud of. Ultimately, our goal was to drive business results. Right? And specifically, I think the key criteria that I think about, from a business perspective, is that our architecture cloud-native architecture allows us to deliver are things like scalability. Right?

The question that I think most business executives ask themselves is: “If I'm going to commit to a pricing solution or the other types of solutions that we offer, is it going to be able to scale to meet my needs?” Right? ‘Is it going to be able to [00:18:00] handle the types of load that I'm going to put into that system?”

“And as I grow the footprint of that solution, can it actually scale to meet those needs as well?” Right? And I think that's a very important question in people's minds. And I think they ought to look at that and look at it in the light of, not just ‘do what I need to do today,’ but as ‘what we need to do that in the future.’

That's one aspect of why I think, from a business perspective, it's really important to look at the underlying architecture.

The other thing is: How reliable is a system? Right? A lot of the solutions, because they're replication of their on-premise solutions being hosted in the cloud, the question I would ask is: If you're going to be doing things like embedding our APIs into your mission critical systems, like your ERP order processing or something along those lines, how stable or how reliable is the system underneath? [00:19:00] The example that I give is: If there's a single point of failure in the architecture, it is unlikely that it is going to be able to deliver the type of reliance that you need.

Understanding that or leveraging your technical resources to dig into that is really important to make sure that: Can the system really be reliable? And I'll give you an anecdote: Given our microservices architecture and leveraging some of the AWS capabilities or distributing our microservices across availability zones and leveraging a distributed database, we can guarantee the availability. And that's even in the case where a data center AWS goes down.

Barrett Thompson: Wow, you're saying if AWS data center completely disappears off the map, the cable's cut or whatever that is, that we're not going to see a hiccup.

Shams Chauthani: Yeah, absolutely. That's not because of just what we're doing. I think AWS [00:20:00] offers us services that allows us to do that. And as long as our architecture can take advantage of those things: Were you able to leverage the capabilities that they've offered? Right? Yeah, I think from our perspective, when we talk about our DR scenarios, we talk about two sets of DR scenarios.

One is a data center outage, in which case, our RPO and RTO times are zero. Because there is no downtime. And then there's a regional downtime that we talk about as well. So yeah, I think from the perspective of why it's important to their businesses - if you're leveraging the solution to drive business critical processes of your business - then it's really important to make sure that it can actually be robust and reliable when you need it to be.

And the third thing I would say is: this is a big investment for a lot of companies. And it's something that hopefully they're looking at as a long-term partnership with somebody. When it comes to that, hopefully your company is going to grow. Your business is going to grow. Your needs are [00:21:00] going to change, and you want to make sure that the department that you've selected can continue to innovate and deliver solutions that are going to meet your needs even in the future.

And that requires somebody to be able to take advantage of the technological innovations that are happening in the marketplace. That starts from basically being able to do simple things like swap out the database technologies when the data sets get large. Or you can imagine that in the next five years, there's some new-fangled way of doing data processing or a new type of AI ML algorithm or deep learning type system that comes out.

You want to incorporate that into your overall solution. Can that solution actually do that? Does it have the ability to bring in your technology and plug it into the overall solution? I think that's an important thing for you to consider as well.

And then, from a cost-of-ownership perspective, it’s also important to [00:22:00] understand that, leveraging a lot of the underlying cloud technologies, we continue to invest in their business processes and the business application deliverables, while we offload a lot of the sort of infrastructure and managing stuff to third parties like AWS, for instance. And we can leverage thousands of people that they have invested, in terms of building out these technologies and capabilities. And we can take advantage of that.

We can then make sure that all of our R& D resources are focused on learning business value and the applications that we're building. Whereas, I think for companies that are showing that monolithic approach end up spending a lot of their resources and time, in terms of just managing the infrastructure, and the ability to be able to deliver just the basic services that they have.

Barrett Thompson: This innovation angle that you mentioned - that's near and dear to me. I had an example here recently back over the holidays. My family purchased, for [00:23:00] me, a new LED television. And you have to understand, that was replacing a technology that was still a rear projector. If you remember what those are: those light projectors from big boxes. Right?

There was an example where I was experiencing episodic innovation. Right?

I bought in at a certain point and then I stayed with that. I was locked in for 15 years. And in fact, I was 10 years behind everybody else in making this change. But eventually, yes, the time was right. I caught up and I made the episodic jump. Boom. Hey, now I have a modern TV!

But you know what? Innovation continues and that TV is going to fall behind and behind and behind. If I contrast that with something like my mobile phone: Several times a year, I get a new update to my operating system and their new features and new things are coming out. And it feels like I'm getting more of a continuous stream of innovations.

I don't have to wait until my next major purchase [00:24:00] event, over on the mobile phone, in order to feel like I'm keeping up with the tech. And I hear that in what you're saying. Right? In these cloud-native platforms, you should expect - it's your entitlement - to keep up with continuous innovation.

Back to our Sales VPs to our pricing directors, to our CFOs: If you need this solution to run fast today and scale with where you're going tomorrow, if you need it to be reliable, if it counts, if it matters and you're going to run your business on it, and if you understand that you want to be in a place of continuous innovation, you don't want to get landlocked and be three generations back before you can finally get another budget allocation, then you should be looking for cloud-native right out of the gate. Am I getting that right?

Shams Chauthani: Absolutely. I think that the key there is, while you don't want to be landlocked, number two, it takes a lot of effort to make a shift later on. Right? As you talked about the [00:25:00] innovations on the phone where it's seamless to you - that things are getting updated and new features and new technologies are coming out - similarly in an architecture like ours, we're constantly innovating our platform. We're doing 170 plus releases a year and our platform is constantly evolving. And then the second layer of that is EWS is constantly evolving. So, we're taking advantage of the pieces that they're bringing to bare.

It's not a question of: “Am I buying something today, that three years from now, I can continue using?” It's: “Tomorrow, you're going to get something new out of that.”

Barrett Thompson: Yeah.

Shams Chauthani: The other piece of that is, traditionally, what you will see is a lot of the monolithic applications that are out there that may still claim to be SaaS will tend to have very infrequent release cycles. Right? And that [00:26:00] usually is a dead giveaway for me is: If you're not getting an application for six months, it's unlikely that you're a cloud-native platform. Right?

You probably have a very heavy model application that takes a long time for you to update. One aspect of that is: Are you getting constant innovation coming out or are you having to wait six months? And at the end of that six months is a heavy lift to upgrade to a newer version. And in some cases, not everybody's getting upgraded at the same time, so you are being left behind.

Those are the kinds of things and horror stories that we hear a lot out there. And for that reason, in our cloud-native approach, we have one code base that runs for all our customers. Right? We don't have different code bases that we're running for our customers where somebody is six or seven versions back.

Everybody's on the same version. Everybody's getting the benefits of all of the technological innovations that we're putting out there. And obviously, we built a lot of quality assurance processes, and things of [00:27:00] that nature, in place, to make sure that there's a zero impact to our customers as we're making these innovations now. And we make sure that they're available to our customers to take advantage, when and if they want to take advantage of it.

Barrett Thompson: Those are great because I think they're straightforward questions and answers that someone who's looking for a solution can ask prospective vendors. And I heard you mentioned two. One is that you could ask that vendor: “Are all of your customers on the identical release of your application?” If not, it might not be cloud native. Probably isn’t.

And then in the second one: “How often do you update? How often do you release new features?” And if the answer is “twice a year” or “some cadence,” other than approximating continuously, then it might not be cloud-native. Probably isn’t. Is there anything else you’d put on that list?

Shams Chauthani: I think those are, from a continuous delivery, continuous [00:28:00] integration perspective, the two ideal questions to ask.

And then the scalability question and the reliability question can also give you pretty good indications whether they can. A simple question could be: “If a data center goes down, what happens to my application?” Right? Hopefully you will get some answer and that might give you an indication of what they're doing under the covers.

Barrett Thompson: That's a great one. That's a great one. Shams, I have one other dimension I'd like to ask you about. I don't know if it's a characteristic of cloud-native, or maybe just the benefit you get when you are cloud-native, but I find more and more businesses that I'm speaking with have a pretty clear vision that they want their technology solutions, their applications especially, that are being used by field teams, to run on any device, anywhere, at any time.

Because sometimes the user is in the office and they're on their PC and they're connected to the browser, I need that. And then a little [00:29:00] bit later, or the next day, “I'm out in the field and I've got my iPad or my mobile phone. I need to be able to do something there.” They want it to work for people inside the firewall and outside the firewall. They want it to work on the phone. They want it to work on the tablet. They want it to work on the web browser.

Is cloud-native giving me some advantage in being that ubiquitous that I'm not going to get if I'm buying into any other architectural approach?

Shams Chauthani: Absolutely. And the specific question you asked about the ability to be omni-channel in terms of how I access the application and work with the application: The answer is absolutely, yes.

In our specific case, we actually leverage the force.com cloud platform to build a lot of our user interfaces and the application logic. And the benefit that we get out of that is that all of the innovations and capabilities that forest.com platform is bringing to the table.

For instance, for us to be able to implement our functionality once and have the ability to deliver that [00:30:00] through mobile channels, tablet channels, or even in some cases, voice-activated processes as well, leveraging that force.com platform allows us to do the innovations in terms of delivering the business value in our applications, but then automatically get the advantage of being able to be omni-channel and leverage a lot of the capabilities that they bring to the table.

Barrett Thompson: And take me a little deeper there. For us, do we have two branches in the code tree? We've got this effort to do the desktop. And then an effort to do the mobile. And the mobile lags behind the desktop and features and capabilities by six months? Or are we talking about one app, the same app showing up at the same time everywhere?

Shams Chauthani: Yeah, it's the latter. We basically have one code base we're dropping our lightning components and other technologies to plug into the forest.com ecosystem in through the mobile app that's available on the force.com platform. [00:31:00] As soon as we deliver the functionality in the desktop, it's also available in mobile, and in other channels that are available to them.

Barrett Thompson: Sham's, this has been great. I really appreciate you taking the time to get into these topics with us and put it down in a language that we can all understand and appreciate. Thank you so much.

Shams Chauthani: Thanks, Barrett. It was a lot of fun. Hopefully, we’ll do it again soon.

Barrett Thompson: This concludes our podcast for today. If you would like to learn more about how these ideas around cloud-native solutions can be brought together to solve emerging problems in pricing, for example, how we can deliver real-time pricing into your business using these ideas. Please take a look into the show notes where we have a link for you to a video on real-time pricing.

Thank you again for joining us. And we look forward to speaking with you again on the next podcast.

Are you ready to learn how Zilliant can help you overcome your pricing challenges?

Reach out to us today to learn how we can help!