Insights Podcasts The Testing Show: Infrastructure Assurance and Cloud Conversions

The Testing Show: Infrastructure Assurance and Cloud Conversions

August 17, 2022

Applications are moving rapidly from company datacenters to the Cloud. With these changes come new challenges with building applications and testing them effectively.

Sriram Sitaraman and Lamech Carnelian join Matthew Heusser and Michael Larsen to talk about “Infrastructure Assurance” and ways to get the most out of the methodologies around putting applications into the cloud and making sure they work optimally once they are there.














Michael Larsen (Intro):

Hello, and welcome to The Testing Show.

Episode 121.

Infrastructure Assurance and Cloud Conversions.

This podcast was recorded on Monday, August 15th, 2022.

In a world where applications are steadily moving from company datacenter to the Cloud (and perhaps overwhelmingly so in the coming years) there are new challenges and issues to be faced when it comes to not just building applications but also testing them effectively. To that end, Sriram Sitaraman and Lamech Carnelian join Matthew Heusser and Michael Larsen to talk about “Infrastructure Assurance” and ways to get the most out of the various methodologies related to putting applications into the cloud and working their best once they get there.

And with that, on with the show.

Matthew Heusser (00:00):
Thank you, Michael. Welcome back to the show, folks. Today, we’ve got a real treat for you. We have Qualitest Global Head of Automation, Sriram Sitaraman, and we have the manager in charge of that group, Lamech Carnelian, and… it’s easy to talk about test automation. We’ve been talking about test automation forever. Is that a thing? Is what a computer does the same thing as what a human does? How do you differentiate the two? How do you leverage the two? We’re not talking about clicking buttons on a screen anymore. Now, the entire development environment you’re working in, it’s not on a box anymore. It’s in the cloud. Where is it? It doesn’t matter. It’s in AWS. it’s serverless. And the components of that, like the microservices, the containers, the notification queue, the APIs, all of it. We’re talking about keeping that system up, running, and reliable and testing for it. You can keep on thinking the same way you are always thinking and continue to have your value diminished, or you can expand your concept of tooling in automation to include those subjects. We’ll start with Sriram Sitaraman, who is the Global Head of Automation for Qualitest. First of all, welcome to the show. Tell us a little bit about how you got into that role, and what do you do every day? What does a Global Head of Automation do?

Sriram Sitaraman (01:28):
Thanks, Matt. As a Global Head of Automation, I work with customers closely on test automation solutions, helping them from digital transformation, providing solutions related to cloud assurance, cloud automation, and also on helping for customers on taking the digital transformation at ease.

Matthew Heusser (01:55):
Okay, thanks. We also have Lamech Carnelian, who is a Senior Architect on the Knowledge and Innovation team for the UK and Europe. So that would be the knowledge of these practices and spreading ideas about good practices and how to do the work. Did I get that right? Welcome to the show, Lamech. Tell us about it.

Lamech Carnelian (02:14):
Thanks Matt. I have around two patents around automation testing. Those, actually helps in terms of solutioning, which helps customer provide automation script without any scripting or thought. And another one with respect to cloud infrastructure assurance. I started my career as a developer and I worked for various mobile operating systems and then a USB kernel driver, so on and so forth, then turned into an automation engineer. That helped me to become an architect. I’m a senior architect now, where I’m able to provide solutions and proactively pitch the right thing for the customers in order to increase their ROI or reduce their testing effort. So on and so forth.

Matthew Heusser (02:58):
So speaking of the right thing for the customer, today we’re talking about test tooling and automation in the cloud. I was blown away by this Gartner prediction saying, “Today, 30% of applications are in the cloud. And within three years, it’s gonna be 95% of data workloads hosted in the cloud.” Is that right? And how does that impact software testing?

Sriram Sitaraman (03:26):
Absolutely. That’s something which we are looking at the trends. And interestingly, there was a survey done with the CI roles as well. You have pointed out that 60 percentage of, what I would guess, they are in the process of migrating to the public cloud or expanding to private cloud as the top IT spending driver in the next two to three years. That’s pretty much the industry is looking towards and moving towards how fast the adoption of cloud is becoming more suited for them, looking at cost savings options for them to move into a cloud.

Matthew Heusser (04:05):
So you guys have provided me a little bit of background here that I’m looking at. It’s really helpful. One myth associated with Infrastructure Assurance is that if we already have test and automation, and we migrate to the cloud, all we have to do is run all of our scripts and if everything passes, we’re good. You’re saying there’s more to it than that?

Lamech Carnelian (04:26):
Yes, exactly Matt, because what happens is the method since cloud is having all monitoring and other stuff, people believe that after migration immediately cloud can spot their defects and highlight it. That isn’t the case. There are various levels of cloud migrations. Accordingly, the testing approach has to differ, which we need to focus on in today’s call.

Michael Larsen (04:47):
So I know that… this is something that is interesting to me because we went through a lot of this recently. I’ve had a chance to see what happens when you have some people that are in the cloud and some people that aren’t. There are a bunch of different types of migrations that you can do if you’re used to having something in a data center and all of a sudden you go up into the cloud. And, of course, the running joke is, “there is no cloud. You’re just using somebody else’s computer,” right? But to that effect, also, there are a number of ways that you can approach how you use the cloud. I think the most common… I don’t even know if it is the most common, but it’s the one I’m most familiar with, is what’s roughly referred to as a “Lift and Shift”, where you take your infrastructure, as it currently exists, on the servers and platforms you have now, and you just push it up to new machines. Well, then you test, of course, and hope that everything is connected together in doing what it’s supposed to do and you go on from there.
So my question is, is the Lift and Shift the most common approach, or are there other things that you do that are actually more common in this day and age?

Lamech Carnelian (05:59):
So you are right to some extent, Michael. So before three years, Lift and Shift was the most common approach, where people were considering to use cloud just as an infrastructure, instead of owning a server, just to avoid any down time within the local service, people shifted their applications to cloud. So this was two-three years ago, but later on, since they couldn’t provide the complete flexibility and utilize the capability of a cloud, people started slowly migrating to refactor bits and pieces of a small, small pieces of their code, where through Application Refactoring. Still, they retain their core application, but consumed one or two important factors like logging or monitoring of the clouds or data storage of the cloud, so on and so forth. Later, people realize that wasn’t even sufficient and now most of them are completely replatforming. So where they’re developing their own applications in the cloud, using the serverless components, notifications, queues, all those things. On the other side, there are also a few customers, insurance pricing determinations, banking, CDD stuff. They don’t want to own the complete heavy software. They shift to certain SaaS, who are already cloud-based. Just to reiterate. There are commonly four types of cloud migration; Lift and Shift, Application Refactoring, completely Replatforming, or the last one is Consume SaaS Options.

Matthew Heusser (07:33):
You tell us a little bit about Shift to SaaS. I’m not sure I understand. So I’ve got an application that I developed internally that I want to move to the cloud. I’m a manufacturer and I sell, and I have a warehouse and I track what goes in and outta my warehouse. How would going to SaaS help me?

Lamech Carnelian (07:56):
So we can consider a retail, how the warehouse things and logistics are taken care. And then we can also consider insurance or banking domain. Let’s start with a retail sector. So in warehouses, there are a huge number of logics that has to be taken care of. So for example, how the items has to be bundled together and from which warehouse it has to be picked, how it has to be delivered at the lowest cost, so on and so forth. Earlier each and every retailer had their own logics and tried improving it. But down the line market was so fast. They couldn’t run in parallel to upgrade their software that frequently. That’s where they tend to start consuming certain SaaS platforms, which are providing this capability and already hosted on cloud. Their existing application can consume these capabilities to dynamically decide how the warehousing model has to be taken care. In the case of insurance, earlier, if you remember, insurance pricing calculation was very unique to each and every insurance provider. They had extremely complex logics developed within the organization. Now it’s pretty common. The pricing logics are generalized, which has been consumed by the insurance provider to provide the right insurance price. They can just add some few customizations on top of it. That’s where SaaS is being commonly consumed. And most of the SaaS platforms are already being migrated to cloud environments.

Matthew Heusser (09:27):
So you’re saying that the actual modeling of the actuarial tables are available in the cloud and that the insurance carrier can tweak them, uploading or changing their data to change the numbers?

Lamech Carnelian (09:44):
Exactly. And what happens is the data that has been gathered by insurance provider is provided to the cloud platform and the cloud platform in turn use lots of third-party services and other things to consume this data and generate the exact pricing logic and provide the best competitive price. So down the line, in later, say technology so on and so forth, this pricing logic keeps on changing and upgrades. So you might have noticed suddenly if there are huge number of car accidents in a specific area, and you’re located in the particular area, your insurance cost would go up. All these things has taken care by existing SaaS platforms that are hosted in cloud. The insurance vendor may not worry about gathering data on each and every location and updating those.

Michael Larsen (10:33):
So this is all really interesting. And I’m guessing that for some people, this might be a new term. I will confess I hadn’t seen it that often, but maybe I just hadn’t been paying attention to it. And that’s the term Infrastructure Assurance. What does infrastructure assurance look like? What would a tester who’s maybe not familiar with that term, how would they come about this and be able to talk to this with half a brain?

Lamech Carnelian (11:02):
So as part of a replatforming exercise, our application would be completely built on top of a cloud platform. Most of the cloud components would be consumed. So let us take a Lambda which can take care of your functions, your API gateway, queues, message, all those things. Notifications have been built. So now what happens, earlier in terms of a web application, it is one complex web application bundle that is file-deployed into a server. Now there are N number of small components and as part of cloud serverless stuff, infrastructure is being spun up when you deploy the components. What happens if a component was not deployed or was not updated, or a container has reached its maximum capacity? The actual myth behind this is like, people feel like since monitoring is there in place, monitoring will immediately help us to monitor those things. But the catch is, yes, monitoring helps you a lot down the line, but initially when you migrate it, how do we ensure the necessary parameters or monitored? A notification alert is set. So on and so forth. One interesting example, one of the leading UK insurance provider have turned down their service for close to 48 hours. They weren’t able to sell any insurance policy because of a small infrastructure issue in the cloud. Literally the payment was consumed, but the policies were not generated because of the number of containers was less than what was expected. And it took close to two days for the team to identify in the early stages.

Michael Larsen (12:46):
Awesome. Thank you.

Matthew Heusser (12:48):
I’m gonna do a sort of check here. I understand the four different types of conversions, although we could probably dive a little bit more into the app refactoring, what exactly that is? I think most of us understand Lift and Shift in that it is literally taking the same architecture and putting it in the cloud. Can you gimme some examples of Application Refactoring? Cuz I understand that as modernizing the app. What are the pieces we’re taking out, what we’re putting in instead?

Lamech Carnelian (13:17):
So when it comes to Application Refactoring, predominantly the first or most important thing would be the database. When you lift your application and shift it to your cloud, you would tend to use cloud-native databases where the storage can be increased dynamically. So on and so forth. You might have used a SQL DB in your local in-house hosted server. When you migrate to the cloud, you might tend to consume AWS/S3 bucket. Similarly, in terms of logging or in terms of specific containers. So on and so forth. Small, small components, you can start consuming cloud-specific components, which helps you to scale pretty soon. And one key factor, which I would like to give here, how is your Lift and Shift testing or Application Refactor testing going to differ from your normal web application testing? Generally, what happens is if you are having your web application already automated and all those things, when you do a Lift and Shift test, immediately after the Lift and Shift migration, you can just go ahead and proceed executing your same set of scripts, just updating the endpoints alone. But when it comes to refactoring, it is important for you to ensure the code is consuming the refactored component. As I said earlier. So it should consume the AWS/S3 bucket instead of your SQL database and in the S3 bucket, it is important for you to ensure the right data is placed in the expected structure. So on and so forth. It’s important for us to validate the cloud-specific component that is being consumed and ensure the expected architecture is actually implemented in the cloud.

Michael Larsen (15:07):
Awesome. Thank you very much. So I would like to direct this question to Sriram, if I can. I’d like to get a little bit of your take on maybe more of a business benefit to cloud monitoring and why cloud monitoring is important and perhaps a neglected part of these migrations and what anybody who’s looking to do a migration here needs to sign up for, if you’re gonna say that, “We’ll monitor this in the cloud”, what exactly are we setting people up to do?

Sriram Sitaraman (15:37):
So the recent COVID pandemic has set a big job for most businesses. Businesses that did not have a digital strategy suffered a major setback with many shutting down their operations permanently. To sustain in the pandemic scenarios, organizations need to consider investing in digital and cloud solutions. Some companies that have recognized the potential of cloud technology invested in it during the initial days and reaped the benefits and experienced double-digit growth. Before even we look at cloud monitoring, probably worth looking at why migrate to the cloud. Most of the organizations look at cloud to save their infrastructure cost. On average, 30 percentage of their infrastructure cost can be saved by going onto cloud versus on-premise. It can help reduce unplanned downtimes. It can help to connect people from anywhere. Anytime on that cloud, there are various reasons to migrate to cloud. As I said, one is the reduced cost.
Collaboration is a second one. As I said, different parts of the country and world can simultaneously work and shared documents and files in real time, improve collaboration and efficiencies between organizations and employees, help enable collaboration and efficient working. Third one is it boosts the business scalability, and focuses and helps facilitate workforce mobility. Operating cost for the CIOs are reduced drastically by moving into a cloud. Another aspect to look at cloud is also an increased security. The biggest worry related to the migration in the earlier days was security. Over the years, cloud service providers have started providing higher levels of security and data integrity. Some of the players like Amazon Web Services offer inbuilt security capabilities that help protect resources. It products the data. It helps to monitor and access activities and sends automated notifications as well. With all these factors put into place, it becomes pivotal for CIOs and organizations to move to cloud. And 52 percentage of the apps that we use in daily life are cloud -hosted or cloud-based apps that we consume today. Probably Lamech can help answer the second portion, which is why we need cloud monitoring.

Lamech Carnelian (18:17):
Sure. What happens is cloud has the capability to monitor various things. You can continuously monitor your container CPU utilization, storage buckets, and how this helps us at any point of time. Even before a threshold has reached, it can provide notification to important stakeholders saying like currently your application is consuming too much of memory or too much of CPU utilization. Would you like to upscale it in order to provide continuous services? So that’s where monitoring is one of the important parameter in cloud assurance.

Michael Larsen (18:55):
Excellent. Okay. So a little bit of a shift here, if you don’t mind. And I guess there’s two ways we can look at this. Of course, Lift and Shift is we just take the whole thing and we just dump it on the server and we don’t really change anything. And when we’re looking to modernize, that’s when we’re considering the idea of, well, if we’re gonna be moving it to the cloud, we might as well update infrastructure and change some details about we’re doing, but we’ll do that incrementally or we’ll modernize certain things here and there. There’s another term here that we touched on and that’s Replatforming. Now, in my worldview, Replatforming means we’re basically gonna start from scratch or we’re gonna rearchitect this from the ground up and we’re gonna do it in the cloud. So if we’re gonna go to the cloud, we’re not gonna waste our time on doing just a pull over or do little changes here and there. We’ve got this whole new playground, let’s just update our app completely. And then when we’re ready to cut over, we just cut over. Is that a realistic way of looking at that? Or am I skipping over some things, maybe mangling/losing some things in translation here.

Lamech Carnelian (20:06):
You have got most of the things right. Again, we are going to look at this point from two different perspectives. From business side, wherever a human was sitting and processing the documents or so on and so forth, all these things have been converted into a software application, just to reduce the manual effort. Similarly, now one of the important reason for cloud migration is to reduce development effort or infrastructure maintenance effort. The second perspective, how cloud helps you to reduce your development effort or reduce your infrastructure maintenance effort is through your reusability and scalability. When someone wants to completely utilize the cloud’s capability of reusability and scalability, cloud demands them to completely migrate, replatform their application. How this is being done, you might have seen multiple applications from the same organization will do a small piece of work repeatedly. So for example, if you’re going to our insurance sector, again, you take a home insurance, you take a motor insurance or you take your personal health insurance, you’ll provide your postcode or door number to do address lookup.
So what cloud says says is, address lookup is a small piece of component, build it separately, so that any application within your organization can consume this to fetch an address. Similarly, if you want to fit the customer’s credit history and other stuff, build one reusable component, which can be invoked by many different applications. So while doing this, there are multiple small, small components being implemented, which helps you to fasten your development, as well as reduce your testing effort. The reason being, during development, you can just focus on a small chunk, a very core point, which is going to focus on a specific functionality or activity. Similarly, during testing, whenever any change happens, only this specific component is going to be updated in your live [environment]. So you can focus testing only around this component instead of testing the complete application as a bundle. So this cloud helps you reduce your dev effort, test effort, info maintenance effort through your reusability, which also provides you good scaling.

Matthew Heusser (22:32):
Yeah. I get that an application wasn’t developed with microservices in mind, for instance. We’re really breaking it apart into these independent small components that we reassemble and that’s replatforming for reuse. Can you distinguish that a little bit from refactoring or application modernization? Cuz aren’t you doing a lot of the same things? You mentioned the database is one big difference, but it seems to me there’s a lot of layers of gray, cuz you could just put it in the cloud, but we’re gonna change the database. Inevitably, you wanna start breaking apart little pieces and eventually you’re Replatforming. How do we decide how much to do in the middle?

Lamech Carnelian (23:14):
So Application Refactoring is something between your Lift and Shift and Replatforming. So in Replatforming, as I said, everything is going to be developed from scratch. Let us say like the UI from storyboard, the back ends as part of microservices, serverless components, so on and so forth. In terms of Lift and Shift, it’s just going to Lift and Shift it in total. But in Refactoring you have the flexibility. So assume today your major concern is around volume of data. You can start consuming cloud data storage instead of inbuilt SQL server. So on and so forth. Similarly, assume after a month you want to move the logging mechanism to cloud. That can be migrated. Later on, assume like one service alone from your application, you want to consume cloud’s microservice, you can focus on that microservice alone to deploy. That part can be consumed from your application. So in terms of Refactoring, it gives you the flexibility to choose the most important component that’s going to help you in terms of reusability and scalability and migrate only those to cloud. It could be a functional block or it could be a technical block like data storage or logging.

Matthew Heusser (24:35):
Okay, well thanks. I think we’ve covered the differences with Infrastructure Assurance versus traditional Quality Assurance. We’ve talked about the four types of cloud migrations and why those cloud migrations are happening. This is a part of the show where we ask for your final thoughts and where people can go for more. But I would ask kind of the, “How does my life change now?” question. So we’ve got a lot of things are changing. A lot of stuff is happening and the pace of it seems to be accelerating. What should testers test managers, people that care about quality, be doing different, be looking different? And after that, your final thoughts.

Lamech Carnelian (25:16):
So, to summarize, when it comes to cloud assurance, it’s no longer testing like a application from the UI, entering all the details to check whether a policy has been created or not. It’s focusing on the cloud component. When we understand the level of change, which small cloud component has been modified, the testing team will be able to focus that test around that specific component. And in a limited span, we’ll be able to ensure that modified component is thoroughly tested and it can continue to work in an integrated fashion to be more specific. It’s going to be testing specific around like whether you’re message queues are working fine. If you are notifications are being properly received and consumed. The Lambda function has done its correct job or not, so on and so forth. Going forward, testing is also going to focus more around specific cloud components, which will tremendously help you to reduce your testing effort and provide a better quality product.

Sriram Sitaraman (26:23):
I’d like to add on to that. What we also have as part of Qualitest is we provide end-to-end services and cloud testing environment for hosting the industry specific solutions with expert knowledge. We also enable our customers to become digital ready and, hello, smooth transition from legacy environment to our cloud platforms without compromising on the quality at every step.

Michael Larsen (26:49):
Fantastic. Thank you so much, Sriram and Lamech, for being here. At this given point in time, I think it’s time for us to appreciate your time and respect your time, and to our listeners, thank you so much for joining us for another episode of The Testing Show and we will see you next time. Thank you, and take care, everybody.

Lamech Carnelian (27:10):
Thank you

Sriram Sitaraman (27:10):
Thank you.

Matthew Heusser (27:11):
Thanks, Michael.

Michael Larsen (OUTRO):
That concludes this episode of The Testing Show. We also want to encourage you, our listeners, to give us a rating and a review on Apple podcasts, Google Podcasts, and we are also available on Spotify. Those ratings and reviews, as well as word of mouth and sharing, help raise the visibility of the show and let more people find us. Also, we want to invite you to come join us on The Testing Show Slack channel, as a way to communicate about the show. Talk to us about what you like and what you’d like to hear, and also to help us shape future shows. Please email us at thetestingshow (at) qualitestgroup (dot) com and we will send you an invite to join group. The Testing Show is produced and edited by Michael Larsen, moderated by Matt Heusser, with frequent contributions from our many featured guests who bring the topics and expertise to make the show happen. Additionally, if you have questions you’d like to see addressed on The Testing Show, or if you would like to be a guest on the podcast, please email us at thetestingshow (at) qualitestgroup (dot) com.