Sai: Thanks for tuning in to one other interesting, engaging session of the Digital Dialogue podcast series that Cigniti Technologies proudly presents. I’m Sairam Vedam, the host for the show and today I have an exciting, extremely intensive topic that is at the forefront of an enterprise’s modern-day digital transformation paradigms and particularly confluencing two compelling aspects of one, all about microservices and more so the context of the role of microservices on Amazon Web Services and together how could they accelerate enterprise digital transformation. To speak about that and share some real insights and treatise experiences, we have two eminent engineering leaders. Joining me today is Amar Deep Singh, Director for Software Engineering at a leading financial enterprise with an experience that I would love him to talk about. He’s joining us from Dallas. Then we have Ram Mamidana, Senior Global Vice President at the delivery organization in Cigniti. All things API, software, modernization, and application architecture are some things that, Ram and his teams spearhead in terms of helping customers reimagine the power of software-led digital transformation, so to speak. Both of them, amongst them, have immaculate experience. I’m going to take a pause for a moment. I’m requesting both Amar and Ram to join me. Welcome, Amar. How have you been doing today?

Amar: Oh, thank you, Sai. It has been a great day so far. It just started here in Dallas.

Sai: Ram, how’s the evening today? I know you’re joining us from Hyderabad today.

Ram: It’s a pretty good day so far. And it can only get from here on.

Sai: Lovely. Amar, would you help with a little bit of introduction about your profile and experience that would be of good use to our audience?

Amar: Yeah, sure. My name is Amar Deep Singh. I’m the Director of Software Engineering for one of the leading financial organizations. I’m also the author of Building and Delivering Microservices book on AWS. I have like 16 years plus experience working in technology. In the last seven to eight years, I have been completely focused on microservices-based architecture and cloud migrations for different organizations. I’m AWS certified solution architect at a professional level and also a certified enterprise architect. I also have like around 11 to 12 cloud-related certifications. And my experience goes really deep into cloud technologies.

Sai: Fantastic. We could have not asked for anything better. We have an eminent engineering leader with us. All the progress getting translated into a wonderful book that he seems to have authored. I hope to get a copy of that at some point in time to read myself. Why don’t I have now Ram take over? Ram, would you like to help us walk through your profile and some of your experience that will be of help to us?

Ram: Sure, Sai. I come from an enterprise architect background. I’ve been working in IT for almost 20 years now, playing various roles across the development and architecture life cycles. I moved into enterprise architecture and integration a few years back, where I specialized in initially creating service-oriented architecture types of implementations at enterprises, which then gradually migrated into a microservices architecture. Most of my time is spent on defining how microservices can get. But other than that, I’ve had the experience of running a blockchain startup and I have my hands dirty in Gen AI and blockchain and other things as well. Looking forward to the conversation.

Sai: Between the two of us, I’ve not yet seen what is that you guys haven’t touched. I’m hopefully having a lot of goosebumps to start this conversation. But yeah, let’s get going. Maybe I would start with Amar. To the benefit of our listeners, would you help us contextualize software architecture trends that are being leveraged, particularly by the banking and fintech industry, more so in the context of the cloud? And what are those customer demands that they need to be able to address? I mean, the end customers. If you could throw some light, that would be a great start to today’s conversation.

Amar: Sure. The banking industry is very vast and complex. There are different types of use cases available in the banking industry. And the last five to six years the trend I’m seeing is banking is more going into microservices-based and even driven architectures. There are some use cases for serverless architecture. In the past, they have used SOA as well and monolithic architecture exists there, maintenance applications. Now all or most of the banks are going through a transformation journey when they are trying to break down their monolithic applications and modernize those architectures to more like microservices or serverless architecture or even driven architectures. Time to market and changing demand from the customer perspective are the biggest challenges in the banking industry. If I give you an example, like in the last 2020, all of a sudden, we were hit by the coronavirus. All the sudden changes happened in real life, which impacted the finance industry as well. If I take a few examples like a lot of small businesses were impacted by the coronavirus. People stopped going out, which immediately started impacting the real estate and restaurant businesses or different related businesses. The US government runs a program called Paycheck Protection Program for small businesses. That’s a kind of different loan the government was offering through banks to these small organizations to keep their employees on the payroll. That was the change, which, as a banking industry, you have to adapt quickly. If you have been a monolithic architecture, if you have to supply this new kind of loan program, you need to be very agile in your architecture. That’s where microservices architecture has a lot of banks to make those changes very quickly and offer that new loan to your customers. One of the financial organizations I was working with within a month, they have to deliver a new application of capability in their application to offer this kind of role. I’ll take another example from related events, that same way like mortgage rates in the US were falling almost close to 1.5%. Earlier, it used to be around 5%. There was a sudden demand for mortgage refinancing in the industry. And so banks started seeing a lot of applications to refinance their homes, which we had never seen in the industry in the past. If you don’t have a very agile or very robust architecture, you can’t support the scalability of that kind of demand, which is coming all of a sudden. Another example is if you have a monolithic application, you are going through trading and day-to-day business transactions, but all of a sudden, your mortgage starts shooting up. You have to scale the entire application. But if you have microservices, this kind of architecture, where you’re making changes into either your loan segment or your mortgage segment, you are not impacting the entire application, you can scale independently, and you can make changes independently. These are the kinds of customer demands and real-life challenges and events that impact the banking industry. You need to have robust and great architecture.

Sai: Yeah, fantastic. As I gather, what I get to understand is microservices could enable you to scale, and then sort of bring in enterprise-class applications and breadth next speed. And we don’t need to worry about the composability, right? The subcomponents can also be scaled. And then without disturbing the entire architecture and great start and very light example, so to speak, phenomenally useful. I’ll probably go back once to Ram and then come back to you. As a global leader, CignitI, I understand we all know that we work in the composite frontier of both digital assurance and digital engineering services, and then sort of promulgate its quality first approach, right? We’ve helped some of our customers leverage microservices. The end digital customer experience has to be frictionless. Can you talk about some of those digital outcomes that you help customers achieve? Just to add to what Amar said?

Ram: Sure, Sai. I think Amar spoke very well about some of the use cases that we typically encounter when we are doing our work for customers in the digital space. One thing that we have seen is there is a lot of maturity now around the topic of microservices architecture in general, there are a lot of generally available architectures and frameworks that can be utilized. At Cigniti, what we have been seeing is a constant stream of a lot of work in the breaking down of monolithic applications into microservices. In a lot of cases, what happens here is that a lot of thought process and actual implementation of microservice comes in very late in the stage. The important area where we are helping a lot of our customers across sectors is in defining what the microservice architecture should be like. Traditionally, when people are used to the NTR type of application architecture, where you’ve got the UI and you’ve got your business layer, or if you’re talking about a domain-driven path, you’re talking about your repository layers and your databases. And what people then generally try to do is to cut across all of those things and create a miniature event of a miniature component of business logic into a microservice, miniature even of a depository into a microservice. That usually results in fairly long-term failures. One of the areas where we specialize and where we are doing a lot of work is in setting out the parameters and the design, what we call inverting the dependency, where we try and look at the use case. If it is a banking use case, we look at a customer for the front office might mean a different thing compared to a customer to the field force or field service kind of an agent. We try and define the context around which the microservice needs to be developed, and then identify the frameworks and tools that need to be applied to achieve such outcomes. In this case, I’m glad to report that we have been working on at least eight to 10 large-scale microservice projects, where we have implemented and across cloud technologies like AWS and Azure, and technologies such as C sharp, Java and JavaScript type of applications like Node and other such frameworks. What we have seen is that microservices architecture has finally reached a stage of maturity where people know now as to what the benefits are and more importantly, they know now as to when not to go for a microservice. That’s the kind of the work that we’re doing from a consulting and advisory standpoint, and then actually implementing it from a technology standpoint using Dapper or Spring Boot or any such frameworks, and then testing and deploying of these applications into cloud and edge kind of environments, containerization and all that. Then also supports the continuous integration and deployment of these applications on various clouds.

Sai: Got it. It’s gone mainstream. That’s what I gathered from whatever you spoke. It’s the age of microservices to be here for a long time with its innovation. Amar, it’s fabulous to understand the fact that you’ve authored a book of such depth, a book, Building and Delivering Microservices on AWS. First and foremost, congratulations on its release, and we understand it’s been well received by the IT community. In this book, you’ve delved into the modern architectures that we were speaking about. What’s the evolving role of microservices here in ensuring that the digital transformation, which is software-led, particularly in banks and financial enterprises, is getting reimagined? Can you throw some light?

Amar: Sure. In this book, I try to summarize the different architecture patterns and I cover a wide variety of architecture, but my focus has been more on the microservices-based architecture in this book. It all depends on your use cases. Banks include different types of use cases and these architecture patterns help you to solve particular use cases. You need to identify what kind of use case you have, and what kind of problem you are trying to solve, and then choose your architecture based on that. In this book, my focus has been on the microservices-based architecture. One of the challenges of every organization, when they go through the transformation journey, they face it that how to break down their applications into microservices, and what is the right size of the microservices. In banks, you deal all day with money and money has been very attractive to human beings. You have to be sure that you are picking the right architecture, you are picking the right size of your microservice, and you are building the security from scratch in your applications, because that has been very attractive to a lot of hackers also security is going to be one of crucial pillars for your application. In this book, the way I took the approach, I took it that first define what are different software architecture patterns, and what is microservices, then go deep into the microservices-based architecture, understanding the different patterns in microservices, learning how to break down your application, that there can be different different approaches to break down your application, then how to successfully deliver these microservices to products or AWS environment. I have used a lot of tool sets available from the AWS as a service offering and built a robust pipeline, which goes through different phases where you are building your code, scanning, doing peer code reviews, you are deploying it to different types of workload like you can deploy to EC2 instances, you can deploy it to container-based application, you can deploy to Kubernetes, ECS, and also if you want to just utilize it to deploy to your infrastructure, all of those aspects. And build security as a foundation to scan all types of code, like either static scanning or dynamic scanning. You will get to learn every aspect of your application delivery in this book.

Sai: Got it. Just to continue that on the microservices deployments, the Gartner analyst Annie Thomas reports that the two issues that trip the software engineering teams are complexity and cultural disruption, right? So given your in-depth experience, can you talk about these aspects and any other pitfalls that IT leaders need to be prepared better?

Amar: I completely agree with Annie Thomas that when you are going through the technology transformation journey, you deal with two types of challenges. One is your technology-related challenges, which I believe are easier to solve because there are a lot of patterns available. These problems have been solved in the industry. Another is changing the mindset of the people because you can bring some new people, but ultimately the people who have the knowledge, who have been working with your applications, their mindset, and there needs to be skill up. With the changes in the technology side understanding the application is important and how you are going to break down. There are different patterns available, you can decompose an application by business capabilities, you can decompose by subdomains, and you can decompose by transaction boundaries. These are all like kind of different challenges and doing the right size of these applications. But the main challenge is to get people aligned to do things in a newer way. The challenges you will face are like people are used to working on a single application. Now you can break it down into the monolithic, into a microservices-based architecture. Now the same application has been divided into hundreds of services. So how are you going to troubleshoot it? You need certain patterns to follow because now you go and log into a server, you can see all the logs, and what is happening with your application. But once you break it down, the same task is being performed by maybe five or ten services. You have to have some solutions to aggregate all of those nodes in one place. And then going through that load, how you trace one request from to another service. Those kinds of challenges, which kind of people freak out with, they feel like, okay, earlier it was much easier for them. Two challenges, one is upscaling and another one is changing their mindset of doing things in an agile way. Because now you can deliver more, you can have people specialized in a particular area of the application. And then you bring all of them together. And as soon as microservices come, you bring new technology too. Understanding the newer technology, you need to encourage these folks. The way I go about it through the transformation journey, I like to encourage people to explore a new way of doing things. I try to find people who are very passionate about technology. I ignite them, I guide them, I do office hours meetings with them, I encourage them to learn more, track them down, and give them necessary tools, and examples. And once you ignite these folks, they are your angels to drive the change. They will go and talk to their peers, they encourage them. And then you start feeling the peer pressure. Others who are resistant start getting encouragement. That’s how the change starts happening within the organizations. That’s the real way where you are changing the people along with your technology.

Sai: Got it. Maybe just to add up to that, are there any new process adoption at the enterprise level, where these are practical challenges in the context of CI/CD? What are those challenges that you’ve observed as IT leaders face in the cloud? Particularly as they start to do AWS adoption?

Amar: There are different phases of CI/CD. One is continuous integration, then continuous delivery and continuous deployment. The organizations where I have worked at most of the organization already have continuous integration part, and some continuous delivery, but continuous deployment is very hard to do. You need to build that confidence within your pipeline so that people are empowered to do automated deployments. The way I like to do is banking, it is much more complex because your applications are very critical. You don’t want a $100 transfer without the knowledge of someone else’s account. You have to make sure that quality gates are being there. Also, you have all security-related concerns addressed before you deploy into products. The applications I have worked on, mostly have been 30 days or 15 days, they have to be in a UAT environment where different lines of business come and they’re performing their UAT and providing sign-off. Taking those kinds of applications to CI/CD, you need to go through a lot of challenges and also convince your business leaders that whatever we are building and trying to deliver, it is having the same quality, as what a human will do by testing it 15-20 times. Automated testing is a crucial part of it, you need to build that automated testing in your delivery pipelines, and you need to build the security scans in the pipeline. Then you build the confidence in the people that whatever we are doing, it is going to work. In case something unexpected things happens, it can roll back to the previous world. You try to go with the blue-green deployment or canary deployments where you are reducing the risk in case something is a failure. When we go to the cloud all those tools are built into those cloud platforms, which makes your life easier. And you can utilize the global infrastructure and securities provided by these platforms.

Sai: Ram, Just to add to what Amar has been speaking. You are in the middle of several large client implementations, particularly in the BFS domain, right? As they embark or have they been in the process of various stages of cloud migration journeys, so to speak? How have you, when I see you, the teams, and your perspectives in terms of helping clients adopt, and leverage the whole fundamental principle of continuous engineering, be it continuous integration or continuous delivery, while they get to accelerate those cloud-based capabilities? If you could share some experiences, I’m sure it will be enriching.

Ram: Sure. I’d like to quickly address the point Amar made earlier, a very good point about the cultural aspect of mindset, where developers who are traditionally used to thinking in terms of the entire or three-tier architectures, kind of thinking about things like manageability, inter-process communication, message passing, circuit breaker kind of logic. All of these things are very nuanced in a lot of ways. One of the areas where we at Cigniti are helping our customers is creating that center of excellence, if you like, within the client organization, and training key people within their teams about implementing, about adopting the microservices mindset for their project, and where they bring in the business expertise, we bring in the technical expertise. That’s how we’re able to kind of create an impact on the cultural aspect of implementation and adaptation of microservices. Now, coming to the continuous integration and delivery, it’s also, one of those points that Amar mentioned, which is about, it’s a whole new world in microservices, right? You’ve got so many things that can go wrong. The importance of quality first approach to doing things is paramount, especially in key critical applications, which like in the banking and financial services domain, even one application not functioning as it should has massive ramifications downstream. If you’re talking about microservice architecture, that is some sort of an RPC, remote procedure call integration with another three or four services, impacting any one of them has got impact on the whole customer experience and has got downstream implications in terms of things like financial models are all taking a hit. One of the things we have done is the implementation of frameworks like Azure DevOps, where we build a lot of pipelines for continuous integration and delivery of containerized applications, implementation of GitHub or GitLab kind of tool sets, Flux kind of tools, Flux is a very up and coming framework for CI/CD implementation of microservices. It has been adopted as one of the 24 live projects by the Cloud Native Foundation. It’s a very robust platform that we’re using for some of our customers in terms of creating a culture of continuous deployment. Because we also have a strong background in testing, especially in the quality side of security testing and the performance testing side of areas, we are able to bring in a 360-degree view towards continuous integration and delivery of microservices, because it’s not just about checking in a line of code and that impacting customers on the line. So, blue-green deployments like Amar said a kind of a closely related concept of A and B testing, for example. These are all patterns we are using for delivering some experience. I’ll just take an example of a customer that we’re working with. It’s a bank based out of the UK, where we are implementing a microservices platform that does everything around the core banking system. The core banking is a commercial product, it is API driven commercial product that we are integrating with, and we have created an entire ecosystem of microservices that are around the core banking platform, which does the connected services for the bank, right from decision engines to their mortgage origination to their reporting platforms and all of that are services that we have built and we’ve managed for them. One of the key aspects is we were able to deliver a turnaround time of less than one week per deployment, from what was previously a three to six-month deployment time frame. For any change that they had to do, they would typically wait three to four months before that went live. We are able to cut that down to weekly deployments as of now. That is the kind of change we are able to bring using implementing CI/CD tooling and microservices architecture for that one customer. We have similar use cases where we are able to cut down on the release cycles, we’re able to provide better quality because the testing happens in a much more micro sense of each of these services, and the overall product and customer experience is thereby better as a kind of a combined effect of all of these things.

Sai: Understood Ram. I think that was quite elaborative, so to speak, and it added a lot of impetus further from a practitioner’s perspective that Amar spoke about from an architectural perspective to a service provider perspective and what you’re seeing right from a customer’s angle. Getting back to Amar, microservices architectures deliver great benefits, which is to be seen, which is very evident from all the experiences that both of you are sharing. However, success is often elusive due to misconceptions about why and when to use it. Having led multiple programs and designed architectures for many large financial enterprises in the US, what is your process for identifying the best-suited applications, particularly for microservices in the cloud, or even specifically AWS?

Amar: I think microservices architecture is very flexible. It just depends on how you are implementing it. Getting the microservices of the right size is what is important for the architecture to be successful. There are different methodologies to find out what is the right architecture. I will take an example from one of the places where I work sometimes you go to money to decompose your services and you try to follow some patterns. Patterns are great but you need to have the right understanding of the pattern whether it is suitable or fitting to your need or not. I will take an example. In one of the credit card applications, whenever you are traveling abroad, you can set up travel notifications. If you are going to some country where your credit card company is not expecting and they suddenly see the transaction, they will try to block the transaction. Upfront you try to set up your travel notification. When a transaction is coming in, they validate you have any travel notification set up so that they don’t block your transaction. That’s very good functionality but not a lot of people or credit card consumers are aware of it and not many try to set up those alerts. That’s a very less used functionality in the banking industry, very useful. I’ve seen one application where developers went to two-minute or nano labels that they created. They tried to use the CQRS patterns which there is a command and query responsibility segregation pattern and they created different microservices just to read those travel notifications separate microservices to update those travel notifications separate microservices which is not the right use case because that pattern is basically when you have like varied demand where your reads are right or exponentially different that time you want to use that pattern. But in this case, it is very clearly used functionality and your demand is pretty much equal on the right side and setting up the alert and also reading those alerts. That was not a very good use case to separate that functionality because now you start running into the maintenance issue but whenever you have to make changes to that particular place you have to make changes into two microservices and then you have to worry about deployment of two microservices. That would have been a great choice if they just kept a single microservice. So, picking the right size for your service is the key to being successful in the microservices architecture also I have you know been part of applications where the team broke down the applications into microservices but didn’t have the right way of testing or the right tools to deliver it in an automated fashion. It becomes a challenge because instead of managing the delivery of one monolithic application now you have to worry about hundreds of applications. From scratch when you are building your foundational work or doing your architecture you need to think about those aspects that how you’re going to solve those challenges like delivering two products and challenges, how you’re going to test it out, how you’re going to build security in it, how you’re going to trace your log across the services and how you’re going to troubleshoot the application because now your message instead of going into one application it has to travel through three or four services to complete one task. Those are the different challenges that come with the microservices architecture and then to solve those you need to have the right tooling, the right skills, and the right people to do the job. These are some of the challenges you will face with the architecture.

Sai: Very well articulated and highly relevant insights I must admit. Getting back to Ram, beyond the banking and financial services industry can you share some fundamentals about microservices-led application development architectures that have proven true and busted myths across several industries considering that you sort of work with multiple verticals not just the financial services? Are there some of these examples that you could further add upon which will further highlight why and how microservices are truly leading the way particularly in a cloud environment and more so in a context like AWS?

Ram: Right, let me answer the second part of the question first, and in terms of everything today is customer experience driven whether it is internal customers or external customers. What we are seeing in microservices architecture caters best for such kind of a scenario where customer experience is key and you’re having to kind of independently scale the flexibility that the microservices architecture provides to you means it is probably the best architecture and so it has kind of won over a lot of its initial troubles back when it started. Now going back to the question about myths, it’s interesting and Amar hit the nail on the head when he spoke about some of the decision-making that is involved and it is very interesting. Initial days of microservices there was a shift from what we used to joke about that was a shift from service-oriented architecture to Netflix-oriented architecture because Netflix was the first people who come up with the whole microservice and they popularized it like anything saying this is how we have done microservices and then everybody was after that. Whether it applied to them or not people ended up jumping on the bandwagon and they started doing the Netflix way of implementing things which backfired because like Amar said it is important to know when to use microservice and what pattern to use within microservice before you jump on it and what we have seen in some of the implementations is like a lot of miscalculation happens especially people take things for granted like for example they think network is always going to be reliable well it is not going to be reliable they think latency is zero but again latency is not zero especially in HTTP web API based implementations. There is this popular case about bell.com so here there’s a talk at NDC I was in London a few years back when we heard this talk and people were talking about how they just assume that you know each HTTP call doesn’t have any sort of latency so they set an SLA first saying that my service SLA should be 0.95 milliseconds or something so the popular mistake that a lot of people do is if you don’t own the SLAs will own you so it is important to set the context of the SLA to understand what we are trying to achieve and then try and define and derive the microservices rather than going with a preconceived notion of this is what I want to achieve that is one myth or one problem that we have seen. The other thing that we have seen is a lot of cases functionality and performance seem to take precedence over security in microservices implementation especially performance more than functionality because when people talk about microservices they subconsciously Start thinking about performance and how to get this like you know super performance super compliant etc and oftentimes what happens is they tend to lose focus of the more critical aspects that I mentioned like security, testability, maintainability and so the fundamental tenets of software architecture being reusability, performance, security and all that many of them take a back seat and microservices engineers seem to focus more and more on performance. This I’m glad is changing slightly with the adoption of some frameworks like Springboot or Dapr kind of showing the best practices in terms of implementing some of these aspects so hopefully it will change. Now what has proven true is an important question Sai that you mentioned which is what has microservices proven true. I think what microservices have proven true is that it is the most flexible architecture that you can aspire to. It will improve your time to market, it will improve the ability to make quick decisions. For example, if you take a framework like Dapr and if you write your entire code based on the fact that you are using let’s say Azure Blob Storage today and for some technical reason or operational reasons you’ve got to shift from Azure Blob Storage to something on AWS, the change is simply one change to a YAML file which will take effect downstream. So the flexibility that these frameworks give you and that flexibility that microservices and architecture give you has been proven true and the time to market is also something that is substantially better compared to traditional models of development. Those are what came true and so interesting times from a microservices architecture point of view because it can only get better from here on.

Sai: Got it. I think that was quite intense, to be honest, which tells about the depth to which you both have been exploring microservices to their fullest potential and I’m glad the results are to be seen so impactfully both in the examples that you cited as much as what Amar was speaking. Probably we’ve sort of come to towards the end of the conversation maybe I would like to go back to Amar once again before we end the conversation. For those looking to effectively tap into microservices on AWS, what do you think Amar are the key takeaways that they can expect particularly from your book that will help them fast-track the go-to-market in an enterprise leveraging the power of microservices because software leading the way, software accelerating and going to market faster with software-led innovation is the way forward right. Give us some takeaways.

Amar: Yeah sure. In my book, there have been tons of books on microservices. So, I didn’t try to cover what has been already there in the industry people have written about it. The approach I took to write this book is to first give a summary of what architecture patterns are available in the industry. In the first chapter, you will get a summary to understand what software architecture in itself, and what are the different architecture patterns then it goes deep into the microservice architecture because this book has been focused on the microservices and then it talks about a lot of patterns to break down your monolithic into microservices architecture then it talks about what are the different patterns you need to use when you are breaking down your databases. What are the different patterns you have to see when you are trying to integrate the data from different microservices and then what are the different unique patterns are there to overcome the challenges microservices bring because instead of managing one application now you are managing hundreds of them and in some cases you know one of the team I work they have like you know 500 microservices for one small application. These are the challenges that come so how you can overcome these challenges by using these patterns. Then I talk in the next chapters like to understand about CI/CD. You can design your north star where everything is automated as soon as you commit the code all types of compilation, building your artifacts, code reviews, all types of your security-related scanning, and vulnerability management everything will happen through the pipeline and you deploy your workload toblue green CICD compliant everything. This book takes you on the journey that is all your north star but how you go about it step by step. This book is much more focused on this. It uses different services available from the AWS tool set like code commit you can use as a git repository replacement then you have code build service to build the artifacts for your application. You store these artifacts in their repositories and then it takes a step-by-step on how to deploy these artifacts to different types of workload AWS support like either EC2 instances or your AKS, your ECS, and in fact, if you want to just deliver to your prem just by using these tool set you don’t want to use the infrastructure AWS is providing you can do that too by learning this so it takes you step by step to starting from the scratch of writing a sample you know microservice. It also talks about terraforming and cloud formation to help you create your infrastructure in an automated way.

Sai: Got it. Thank you very much Amar as they say somewhere I read maybe Martin Fowler often the true consequences of architectural decisions are only evident several years after you made them. Looks like microservices is laying a long road and that is hopefully late then a well manageable hopefully great software applications are getting built accelerated leveraging the power of the architecture that you all spoke about and of course being cloud first helping companies to become truly digital first. This has been a phenomenal conversation looks like Ram has one final comment to make which I am absolutely waiting to hear.

Ram: One final point I just to add to what you were saying.

Sai: Please go ahead.

Ram: Microservices has moved on from what used to be consequential decision-making to categorical decision-making. What I mean by that is usually it was like microservice one person would come up with the idea and the team would say okay let’s try it out with this and based on the consequences of that we will choose whether to adopt or not. The default position seems to be a categorically microservice yes we’re going for it so that’s interesting.

Sai: Maybe for a layman like me, it’s like what I understand is from reactive to being proactive looks like that’s an analogy. I could not have asked for a better conversation than this on this Friday evening before we end the week. It has been a treatise of experiences wonderfully articulated well-crafted engineering experiences that we could hear from. Cigniti will keep coming in. I request all our audience to keep their input requests and suggestions coming in so that we can improve and if you have anything else to ask do write to us or visit us on our social channels and website we will get back to our experts answering as many as them as we could and thank you once again, Amar and Ram. It’s been really nice having you both on the show today. Thank you.