TPM Podcast: Vidya Vrat Agarwal on Microservices – Part II

A very interesting TPM Podcast with Vidya Vrat Agarwal on Microservices.  We talk about large enterprises moving from a monolithic application patterns on to microservices what that entails. We go on to talk about various microservices best practices.

TPM Podcast with Vidya Vrat Agarwal on Microservices

This has been split into three eposodes:-

• Part I: Lives here.
• Part II: Lives here.
• Part III: Lives here. 

Vidya’s LinkedIn Profile – https://www.linkedin.com/in/vidyavrat/

Also, read my previous post on microservices here – https://www.mariogerard.com/microservices/ 

We talk about :-

1. What is a microservice?
2. Advantages of microservices
3. Monolithic applications vs microservices ?
4. Why is there is renewed uptick in organizations using Microservices ?
5. Pain points of microservices
6. How do you break down monolithic applications into microservices
7. Microservices Advanced Topics

Vidya’s Interesting LinkedIn Posts

• Microservices Architecture 
• Single Team Owned Service Architecture
• Building A CI/CD  Pipeline

Thank you ! Hope you enjoed it !

————****************———–

Vidya’s Linkedin Post (Extract)

Abstract

The microservices architecture style is an evolution of the Monolith SOA (Service Oriented Architecture) architecture style. The difference between the SOA and microservice approach is how these are being developed and operationalized. With every new technology addition, our responsibility also increases to be abreast of pros-and-cons the new member has, and the pain points it is designed to solve.

Monolith

Think of any MVC pattern-based API codebase, where all your controllers and POJOs (Plain Old Java Objects) or POCOs (Plain Old C# Objects) were developed, build and deployed as a single unit, and for almost all the times a single data store was used for the enterprise. I.e. One database is housing all the tables for various responsibilities, for example, Customer, Payment, Order, Inventory, Shipping, Billing, etc. as shown in the logical architecture diagram below. I.e. all the various responsibilities are together.

Monolith Pros:

• Less Cross-cutting Concerns: Being monolith and having all the responsibilities together, single or few implementations can cover all the major cross-cutting concerns such as security, logging.

• Less Operational Overhead: Having one large monolith application means there’s only one application you need to set up logging, monitoring, testing for. It’s also generally less complex to deploy, scale, secure and operationalize.

• Performance: There can also be performance advantages since shared-memory access is faster than inter-process communication (IPC).

Monolith Cons:

• Tightly Coupled: Monolithic app services tend to get tightly coupled and entangled as the application evolves, making it difficult to isolate services for purposes such as independent scaling or code maintainability.

• Harder to Understand: Due to many dependencies, monolithic architecture easily become harder to understand.

• Deploy all or none: When a new change needs to be pushed, all the services need to be deployed. I.e. if something changed in OrderController and you want to proceed with deployment, all other controllers and code will be deployed unwantedly.

• Scale all or none: Scale up/out/down, it’s for entire functionality.

Microservice

Gartner defines a “Microservice as a small autonomous, tightly scoped, loosely coupled, strongly encapsulated, independently deployable, and independently scalable application component. “ Microservice has a key role to play in distributed system architecture, and it has brought a fresh perspective.

Unlike monolith, a microservice strictly follows the Single Responsibility Principle (SRP) due to being tightly scoped around the business capability/domain for example Payment. Think of an MVC pattern-based API codebase where a controller and POJOs (Plain Old Java Objects) or POCOs (Plain Old C# Objects) were developed, build and deployed for just one single responsibility i.e. business capability. This microservice architecture will then lead to having many such projects and each business capability having its own database.

Microservice Pros:

• Easier Deployments: Monolith was deploying all or none. Microservice is a small service, the dev team has complete control on what needs to be deployed and leave another feature’s code untouched. I.e. if changes made in Payment service, only payment can be deployed. This was not possible with a monolith.
• Scalability: Being a small tightly scoped service design, it gives freedom and flexibility to scale whichever service you want. For example, if needed only Payment can be scaled up/down/out.
• Easier maintainability: Each microservice service is autonomous and so being small service it’s much easier to maintain than a monolith.
• Problem isolation: Each service has its own codebase and deployed in its own space. Hence, any problem with self or other services remains completely isolated.
• Single Responsibility: Single Responsibility Principle is at the core of microservice design. This drives all other goodness microservice architecture offers.
• Separation of Concern: Microservices architecture leads towards building tightly scoped services with distinct features having zero overlaps with other functions.
• Deep domain knowledge: Microservice encourages the product mindset and leads towards establishing deep domain knowledge with “you build it, you run it” mantra.

Microservice Cons:

• Cultural Changes: It requires a cultural shift and organizational alignment to adapt microservice architecture, and the organization will require a mature agile and DevOps culture. With a microservices based application, service team needs to be enabled to manage the entire lifecycle of a service. Read my article on STOSA (Single Team Owned Service Architecture)
• More Expensive: Microservice architecture leads to growing costs, as there are multiple services. Services will need to communicate with each other, resulting in a lot of remote calls. These remote calls result in higher costs associated with network latency and processing than with traditional monolith architecture.
• Complexity: Microservices architecture by nature has increased complexity over a monolith architecture. The complexity of a microservices-based application is directly correlated with the number of services involved, and a number of databases.
• Less Productivity: Microservice architecture is complex. Increased complexity impacts productivity and it starts falling. Microservice development team usually requires more time to collaborate, test, deploy and operationalize the service which certainly requires more time.

Summary

Microservice and monolith architecture, both have their pros and cons. Microservice architecture is not a silver bullet, but teams which aspire to be digitally transformed and writing services with a product mindset, microservice architecture is certainly worth consideration.

Podcast Transcript

Hello, and welcome to the TPM podcast with your host Mario Gerard. This is part two of the three part microservices podcast recorded with Vidya Agarwal. If you’ve not listened to part one, I highly recommend you start there.

Mario Gerard: So let’s talk a little bit about why there’s a, an uptick of organizations using microservices. And I think new age organizations, organizations, which have just grown in the last five years are all microservice based. When I think about this, I think about something like Uber, right? Who have come into the market in the last five or seven years or 10 years, there are 100% microservice-based. And then you have a legacy or old world organizations who are trying to make a leap and they’re moving towards a Microservice architecture from a monolithic architecture. So why is there a new uptick in microservices in general?

Vidya Agarwal: So my viewpoint to ours, this is that all these new upcoming organizations, first of all, they are product-based. That’s the first thing which we need to understand. So they are not building a project. They are building a product. Second thing is any organization, which is really trying to build a product. They need three things to be successful, speed, scale, and agility. These three things are the key motivation in order to have, or adopt microservice architecture. Other thing with microservices is, as we were talking earlier, the two pizza team, DevOps culture, agile mindset, all that good stuff is only for those teams and organization, which are really aligning themselves and thinking in terms of a product, they are not saying I’m making a project. They are calling their API as a product. So in T-Mobile, we have different product teams. My team, we have our own product. We have a payment team. There’s a separate product. Address team, there’s a separate product, billing teams, a different product. So you will see your API even, microservice,

You’re not thinking in terms of a project where you run for two, three, four, five months. Then you just launch everything. Then you just disband the team. And then it goes into the ops team to maintenance and all that is stuff. That’s not what the, you know, the mindset is. The mindset here is we build it. We own it. And we continuously evolve. When you are building a product, your customer base increases, your customer needs evolve, and you want to add more and more. You are observing the needs. You are having monitoring on your services and you want to improvise Day-By-Day. Now, that’s why all these new age companies and startups and whatnot, other thing is they do not have any legacy behind.

Since they are starting so fresh, there’s nothing. They just want to invest into something real quick and say, Oh, you know what? We learned so much from the industry. They were building monolith. Let’s not get into that rabbit hole. Let’s start fresh and do the things right from the beginning. That’s why I think it’s a little bit easier for them if they are doing it. But otherwise there are ways to migrate from Monolith to microservice. But I think in my view, that’s a little bit low-hanging for them because it’s a fresh start. And other thing is, in these last few years, technology market evolved a lot. Cloud become very cheap. Cloud evolved so much, serverless is coming. Docker containers are coming. People are now thinking about containers. They are moving out of VMs. They are going serverless.

They are deploying in containers. All these new technologies as your service fabric. Spring goat, PCF, pivotal cloud Foundry, all these things. They are having multiple nodes when you deploy a container. So all these things are coming out of those platforms, which are given to you on AWS or Azure or whatever cloud solution provider you have to build that infrastructure automatically for you. You don’t need to think about duplicacy, redundancy for high availability. All those modes you deploy in one container it’s automatically replicated. So these things has become very easy to adopt and evolve in last few years. And that’s why these companies are able to take that [04:19 inaudible] in comparison to the companies who did monoliths deployed in their own VMs and hosted in their own servers and things like that.

Mario Gerard: And their own infrastructure and all that. Yeah. I think you made a very good point of speed, scale, and agility, right? When you talk about speed, it’s speed to market, right? And scale, you can build to any scale, you might today have as a small startup, you might have 200 customers. It might go viral completely and it might have 200,000 customers tomorrow. And for you, you actually are not buying any new servers. If it’s all in the cloud, it has auto scaling enabled. It’s a very simple decision to do. In the other hand, if you’re a monolithic application and if it was 10 years ago, you’d have to go procure new servers, have the servers ship to your data center, it will take you, the lead time is nearly two months maybe for you to get those servers. In the meantime, you can only serve X amount of customers you had originally provisioned for, right.

Vidya Agarwal: As you just made the point, we are now out of those things where you really procure servers and all that. Only thing, which companies need to be cognizant and aware of is, when the need will grow. So for example, T-Mobile, we were very successful in the latest T-Mobile launch. Our website didn’t go down, even all of the prominent websites in the area and the country, they all went down because there are so much load on the website. Our didn’t, our team did amazing job. We are very proud of that. The reason is that we knew how to scale services. We know what we build, what we own and how to scale it, how to cater the needs of the customer. And that customer mindset is the key. If you are having customer mindset, then you know, the product you are making is supposed to scale. You are not making a service for 200 customers. You are making it maybe for 200,000, maybe 2 million. So you need to have that mindset that if tomorrow I need to scale it, how do I do it?

Mario Gerard: And you’re thinking about that from the very beginning.

Vidya Agarwal: Beginning is the key. So rather than me procuring a server, deploying it under my desk, and then one fine day of an Apple launch comes, I say, okay, here is the order. Buy me a new, better server. Maybe that launch will go. Then your server will come into your office.

Mario Gerard: Or the launch might fail, the product might not be that successful, but you have 20 you know, servers sitting there, which were never used. And then you don’t know what to do with that. So you can never predict customer demand. It’s very hard to predict customer demand.

Vidya Agarwal: And as you said, the auto scaling is only possible with this cloud solutions and all.

Mario Gerard: Yeah. Yeah. And I think with microservices, another dimension, which I’m seeing is using multiple cloud providers instead of just using one cloud provider, which could go down or you might have a problem with one if you can deploy microservices into multiple cloud providers or use a combination of two as one as a backup or one DR solution versus one of the live solution. I think there are so many innovative ways. And that’s where I think you made a very good point of being the North star, right? If you want to do all of that in the first go, it’s almost impossible. It takes multiple years to get to a place where you’re hundred percent scalable and whatever redundancy you have built in if something goes down that there’s, something can be done with that.

 

Vidya Agarwal: So there is one thing which I want to tell our listeners, as you said that having multiple cloud providers, this may not sound very feasible to many people. So rather than they getting scared away with this and thinking we are not north star, what they need to do is they need to deploy their services in at least two different availability zones. So many organizations just do only East or West and things like that. So see your customer base, always try to be closest to where your customer is, and then deploy at least in multiple availability zones. If you cannot have Azure and AWS both as [08:29 inaudible] mentioning, at least have wherever you are, stay with that cloud solution provider, I am sure you selected the best as per your needs.

Just have at least two availability zones. And all these cloud solutions providers are top-notch. They are adhering to their SLA, available 24/7. And even if something goes down, then they are having very fast recovery path. But in that case, your load balancers will do the job to redirect it to the other region, if you are in East, East goes down, then it goes to West and vice versa. So that is another strategy or pattern, you know, companies and architects and TPMs can really think about it rather than really suggesting all the time too, because it could be cost intensive for many. And then it needs a little bit more infrastructure and code and all these things to be built that which one is down, where do I go? So it could be a little bit challenging.

Mario Gerard: Within a cloud provider, it’s easier to do a lot of things. Especially when you’re talking about database redundancy, right? The application is very simple because the same application deployed across two regions. But when we are talking about database, which needs to be synchronously maintained. It is a definitely an easier thing to do it with a single cloud provider, because you have a, most of these providers offer a good backup and redundancy or what do you call it? Mirroring techniques within the same, within the two regions, which kind of, it’s just a click off, literally a check box. Bill might be a little larger, but it’s literally a checkbox where in the old world, if you’re using a traditional RDBMS doing sharding and you know, [10:13 inaudible], you need a team of people to do that. But today it’s as simple as clicking a check box somewhere. And your data is a synchronously sync between two regions. Cool. So let’s talk a little bit about, I think we already spoke, but how do you break down a microservice?

Vidya Agarwal: So once again, for the benefit of listeners, I will repeat the two words one more time. When we talk about microservice, you will hear this term many times, it’s called bounded context. This term came from domain-driven design. Now what does boundary context mean is that you always have some sort of domain. Think about what domain this thing belongs to. So for any organization, you have different systems, call it whatever, customer is one domain, which almost every industry has. Call it airlines, Telecom, retail, whatever you have customer is always there. Without customer what will you do? Who are you selling it to? So customer consider it as a bounded context or a business capability. It’s a domain for your organization.

Now, wherever you are hosting that information, whatever APIs are giving you the information to get, post, put, delete, whatever you need. All those things are now clubbed together with one single database, which is hosting the information. Maybe you are doing CQRS, Kafka, event messaging, all that good stuff is now one microservice. So when in order to do it from your monolith, you think about those things. Then what is my bounded context? Let me slice and dice, but my bounded context and business capability, and then add the new stuff as needed one by one. So maybe as we discussed earlier, somebody may not want to do CQRS right away. They will host one database. Then they think, okay, our post is having 10 fields, because we are asking too much information, but for whatever reason, we are not showing all that information back to the UI. Hence my real database CQRS command, query, responsibility, segregation pattern. My reader schema is going to be different. I’m only going to put only five fields there. So when event is being published from a write database to read, it only sends five fields out. And those five goes and sit into the database row. And when you read it, only that information is being read.

Mario Gerard: Okay. So I’m going to try to visualize what you just said. You have a microservice application, which is taking customer data, and there are actually two databases underneath that. One could be a database, which is primarily used to write the information, which then uses a [12:54 inaudible] then send to another database, which is just the read. And the read database could also have things like caching mechanisms. Because the same customer information could be read multiple times, but the write database does not have any caching. It’s purely optimized for writes. And you have more fields in that write database. While in the read database, you might have lesser number of fields, which are not generally queried. And it has a very substantial caching layer because so that you don’t hit the database every single time you read and those kinds of things. So a single Microservice application, you’re envisioning that it could have two separate databases.

Vidya Agarwal: If you are implementing CQRS.

Mario Gerard: If you are implementing CQRS.

Vidya Agarwal: And there are benefits as you clearly called out. But many times what happens is if I’m the backend and you are the consumer, I may not have in my current roadmap to build cashing for you. So my read database, which I’m exposing the information to you, I’m not cashing it anywhere. So you, as a consumer, you may want to cash it, but then you need to talk to the backend, what does your roadmap look like? Why don’t you cache it? So sometimes you also have a say to influence to backend teams that this is my use case.

I am your API consumer. Why don’t you start cashing it? So rather than you really pull it from the database, you give me from the cache. And then there is another thing which can go wrong in this case, it’s the movement, write changes. Let’s say I read the information, but I called customer care. Or I go to my account and I say change my address. My address is changed. Then the cache invalidation needs to take. The more layers you add, the more complex it becomes, but there are solutions to everything, and all these things were beautifully envisioned and designed properly. But yes, I’m just bringing it to the table. So people know that, you know, it’s not automatic. You really need to work towards it. Because when, according to CQRS, when post happened, you need to set up an event first that something changed. That event will go out. Address changed event from your Kafka or whatever technology you have selected of your choice. And then your cache had the old address that cache now needs to be invalidated and new data needs to be put back.

Mario Gerard: Yeah. Yeah. Okay. Next question I think we have is how do you break down monolithic applications into microservice? And I think we spoke a little bit about it.

Vidya Agarwal: Again. I can say it for a short one more time, is that always do not try to break everything apart. That’s just my sincere advice to people who really are looking forward to it to get benefit out of this podcast is always try to take small steps, follow, crawl, walk, and run. Think in terms of business capabilities. And if they are still building monolith, try to align whatever new functionality they are making with the domain. So think about it this way. Let’s say I have a billing. Now, I subscribed for notifications to be sent whenever my bill is due. Now where would that functionality go? So many times it is very easy for us to go to the billing controller and start writing code for that notification thing.

But if you see notification by itself is a different business capability or think about it this way. I want to store my credit card information for my billing that auto pay use this whenever my bill is due. Now, many people can think since its billing, let me store my credit card information for autopay in the billing itself. That’s a wrong design. We are talking about two different business capabilities. One is billing. One is payment. Hence your credit card information supposed to go to the payment, not to the billing, but whenever time will come, billing will talk to the payment service and say, here is the bill information of this customer, which is due on this date, which this much amount kindly processed that and send us the confirmation back.

And if something goes wrong or fall through the cracks, then there are other monitoring services available. Then notifications will go out. For some reason, your credit card expired. We couldn’t run it and all these things. So if monolith people start thinking in that direction, if they are not immediately adopting microservices, at least they are aligning towards that. And when time comes, it will be easier for them to slice and dice and take that piece as is out of the big monolith project and put it in a separate code base and then build it and then deploy it and then operate it, maintain it and whatever.

Mario Gerard: So you’re just talking about like, when you have a new feature that we want to implement, right. Supposing we want to do notification, you wanted to push notifications or something like that. How do you decide where it falls and which team it’s going to fall under? Like who makes that call?

Vidya Agarwal: Usually like TPMs. Whoever owns the technical [17:52 inaudible], Technical spec, architect.

Mario Gerard: And then so supposing there’s a new feature you want to do. You might actually have to go and create a new team, right? There’s a new notification, notification as a function or as a feature wasn’t there yesterday, the product manager comes and says, Hey, we need to send out push notifications. So then you actually have to go spin up a new team, which is going to build, own and operate and deploy this microservice.

Vidya Agarwal: So there is a thing called a STOSA, single team owned service architecture. Many times in real world scenarios, it is very hard to spin a new team each and every time. Think about it this way. Your team is having seven to nine people, already spoke about two Pizza team, [18:38 inaudible] these days, that team is already building and owning whatever they do. They are excelling in that. If that team has bandwidth to do the notification thing and they are up for it, that team can still own it. The reason is they are not mixing the code base of these things in one project. When they will open the code base, it will be in two different Bitbucket, repos or whatever versioning system you use. It will be two different repos. Two different pipelines for CICD will be there. Two different jobs will run to build and deploy the code, two different container infrastructure or VM or serverless, whatever will be there.

The only thing is that now the third team should not own any of the service which this team owns. In that case, there will be a conflict. Think about it this way. You talked about notification, let’s say notification is assigned to you. Now I am not supposed to do anything about notification because I am only a consumer of notification. If new feature comes out, a new user story pops up in the product backlog. Now only you supposed to pick that user story into your sprint backlog, talking in terms of agile, real world scenario, how people do it on a daily basis. I’m not supposed to be the owner of that. Only you do, why? Because you know your code base, you built as we talked about the benefit, the domain alignment, the deep understanding of the domain, you know all these things, you will make decisions.

Am I going to buy some sort of notification system off the shelf, a commercial off the shelf system. Is that something I’m going to build? Is it something I can inner source and reuse within the organization? So you are the owner of that because business doesn’t really care and they don’t, even if they care, they do not own the technical design. My business, my customer should be able to set a credit card for auto-pay. That’s my problem statement. How elegantly you do it, how do you do it, but do it within the timelines is the key. Now that is up to the TPMs, architects, these people who own the technical reason, the technical roadmap and implementation of the dev teams of course, to decide who will own it and where would it go. Even if you’ve mixed payment system with billing, it’s not going to hurt. You can still do it, but then you violated the microservice architecture principles.

Mario Gerard: As long as they have two separate code bases, separate databases, ideally, separate CICD pipelines and separate monitoring in place. It should be fine.

Vidya Agarwal: It should be fine. As long as that team can continue to build and own previous service data, the team cannot say, Oh, you know what? Since now I own another thing, I cannot build this one. Since I’m building this one, I cannot own the other. Now they build and own two services. So it is very hard for organizations to really spin a new team every time of seven to nine people. Maybe there could be an addition to this team which will do it, but again, they have to have separate code base and everything’s separate, as you just mentioned.

Mario Gerard: And you brought up a very interesting point. I’ve seen agile fail and one of the various primary reasons I see agile fail and people are doing microservices, not having a very good CICB pipeline, right. They don’t have enough regression tests. They don’t have a good build and deploy pipeline. Or the deployment is very manual. How important the CICB in the microservices world you think.

Vidya Agarwal: Even in my view, even in monoliths, CICD is important. So CICD does not lose its significance even for monoliths. What happens is that continuous integration, continuous deployment are the key. There is one more thing, continuous delivery means deploying to production automatically, which is not advisable all the time. Because like in T-Mobile also, we do not deploy right away. We have our own nonproduction environment. We call it NP. We will test it over there. We will certify the bills over there. We will certify all the test cases ran. We have a separate dedicated team which does it.

I hope every organization has something similar setting. And once that sign off has been achieved from all the leaders, then only we have a sign off and go ahead to deploy to production. But are we really doing continuous integration whenever we are checking in something? Yes, we do. What is the beauty of that? The beauty is that whatever code you have been writing is getting into the main trunk. Let’s say master or main, whatever branch you call it. And now your code is hustling, jelling, and mashing with the rest of the code base. And once it goes in there, if it has any sort of polluted code in it, it might have some sort of issues with some sort of some unit test cases that it will fail some other test cases. And that’s why there is one more term, which I want to introduce, and many people might know is called CT.

There is another thing coming up these days, CICDCT, CT means continuous testing. Continuous testing is that the moment you check in, the test case keep running in the system. And you automatically know. So before your build is really decided to fail or successful it run on all the test cases, which you wrote, and that’s why teams need to have very disciplined mature and the product mindset is the key that whatever I am writing, I have well-rounded test cases, happy path, and sad path. Many people understand these two as positive testing, and negative testing. We need to cover both the scenarios based on your API contract or what your customer is looking for. Make those test cases, think out of the box, make sure every test case passes, and then only you go. And every time you check in, these test cases are being run. And that is what continuous testing is. And then monitor them of course, as you called them earlier.

Mario Gerard: And I think that’s so important when you’re doing microservices, because you want to bring it quickly into the market. You want to deploy it fairly quickly. You don’t want it to have a two-week test cycle or four week test cycle, because the code is already written. You already written your unit tests to that. You want to check it against all the previous unit tests and regression tests which are there to ensure that you’re not breaking anything, which has already been there for the customers. And you want to do this in a quick and continuous fashion, right? So having a mature CICD pipeline is almost as important when you start doing your microservices to keep having enough rigor to do that discipline, to have your test cases.

Vidya Agarwal: There is one more thing. I think the other viewpoint I have about this thing is, with monoliths your pipeline is a little bit more lengthy because you are building so much, there are so many things happening. I think adoption of CICD become a little bit more easier and low-hanging for microservice because the code base is so small. Think about it. You have been deploying address, customer, payment, billing, shipping, all these things in monolith. So your pipeline had a lot to do. Your build was a little bit running lengthier. Even one thing failed your entire build failed.

But in case of microservices, adoption of CICD become a little bit more low-hanging and easy to adopt because you are having just one responsibility, one bounded context based business capability in one service, hence your build runs really fast and you can easily deploy to containers and you can easily set maybe a dozen unit test cases for instance, to begin with. And then that set of doesn’t become one and a half dozen. And then you grow in number of unit test cases based on the features. But if you think about monolith, you might have few hundred unit test case which all needs to run. So that’s why adoption in microservices a little, that’s another viewpoint I’m presenting to the listeners that it’s little bit more easier for them to adapt.

Mario Gerard: Yeah. Yeah. I also remember when I was working on many years ago when I was working on monolithic application, the amount of tests that run, it might take you 48 hours for the test to finish. In a microservice based architecture, generally you have tests which are running, it might take an hour, maybe two hours, maybe three hours maximum, right?

Vidya Agarwal: If it’s taking that long, I think you need to break your microservices into smaller pieces.

Mario Gerard: Smaller piece. But the time to market is fairly fast with microservices. Cool.

This is the end of part two, a three part three is live. Do go ahead and listen to that. As I mentioned before, there’s a lot of information available on www.mariogerard.com in particular, regards to this podcast. Vidya has provided a lot of microservice architecture diagrams and also link to his LinkedIn profile where you can connect with him. And there are also several other articles that Vidya has written, which I’m linking from my website, www.mariogerard.com. So I’ll see you on the other side, with part three of three of the microservices podcast. Thank you so much.