The Architect’s Dilemma: Control vs Convenience - Mandeep Singh

This talk addresses the architect's dilemma of control versus convenience, providing insights from the speaker's experience as a software engineer and author. Mandeep Singh explores the concepts of control, which refers to defining every aspect of a system, and convenience, which involves offloading responsibilities to managed services or external teams. He illustrates these concepts with personal anecdotes and technical examples, such as choosing between self-managed environments and serverless offerings like AWS Lambda. The discussion also emphasizes the importance of making informed decisions by evaluating custom optimization needs, team expertise, and potential vendor lock-ins. Ultimately, the speaker advocates for a balanced approach that aligns architectural choices with business strategies while continuously reassessing decisions based on changing circumstances.

The title of today's discussion is the architect's dilemma, control versus convenience. But since I'm not that famous, I will quickly introduce myself. I'm Mandeep Singh. I'm a software engineer. I'm author of a book called System Design on AWS, the cover page which you see on the screen right now. I also manage a YouTube channel called MSDN Singh where I teach people around software architecture, system design, and

how you deploy and manage solutions on cloud. And you can definitely connect with me on LinkedIn and all. If you have anything to discuss and all. Okay. So, let's get started. So, this is April, right? What do What does April stand for? It's an increment season, right? We want high raise raise per salary. But what do we get instead? I mean, not every one of us, but

yeah, most of us get low raise and then the common discussion which is there is that why does I get a low raise, okay? Or why didn't I get too much of increment, okay? Or you might say that, okay, my CEO is getting this much exponentially high and I'm getting this much of low salary, but I am doing all the heavy lifting. But I mean, there can

be lot of reasons, but one reason is which I mean, I'm just sharing from my experience that the people who are at a higher position, okay? Be it your architect, be your CTO, be it your CEO, they help with the decision-making. And that is the critical part. They help you to come out of dilemmas. Like, do I have to go into this direction or do I have

to go into that direction? So, that's the critical part and that's one of the reason. And today also we are discussing one such dilemma, which is control versus convenience. And throughout the session uh we will be trying to understand what control is, what convenience is, in which context we are talking about them. Uh what are some of the use cases? Like how will you decide uh which

option do I have to go to? Okay? But let's start with a simple example. Uh non-tech example per se. Uh how do I explain control and convenience in very simple and not so fashionable way, not in technical terms. So, this example is from my book uh system design on AWS. So, while I was working on this book, uh I I stayed in Bangalore, okay? So, like these

days I uh work from Rajasthan, which is my hometown. But I was in Bangalore for close to 1.5 years uh uh as part of my previous company, and I used to cook my own food. Now, you might ask what's fancy in that. So, nothing fancy, but if you are Indian and if you are working, and let's say you and your partner both are working, then generally you

get domestic help. Uh the reason is pretty simple, uh it's cheaper. So, that's the only reason you get domestic help, but I used to cook my own food, and I used to do my daily chores on my own, and I used to get questions like, "Okay, why do you do it?" So, the simple reason was uh I got used to it. Okay? Uh and I over the

time I enjoyed the process. It was just part of my routine. But the primary reason was that if I'm cooking my own food, I'm controlling all the ingredients. Uh what is my cooking time, okay? How do I chop my vegetables? Uh what kind of vegetables or like what kind of you Anything, okay? But that is hard if you have maid or domestic help to uh do that

purpose, right? Uh so, that's control for you. You are controlling the aspect of So, the cooking is one example here. Uh it could be anything. You are con- controlling that aspect of your life. But since I was working uh like other like I was also pursuing some other interest in my life at that time. Like I was working on book as well. I was trying to manage

my YouTube channel. I was also working full-time in a company. So, there are a lot of things, right? And I was also trying to cook food. So, how do you manage time? So, sometimes uh mostly Sunday afternoons, I used to order biryani from Zomato. Zomato, if you don't know, I see most of the Indian audience, but yeah. Zomato, if you don't uh it's an online food delivery

application where you uh order food uh from your restaurant like a specific dish you want to order, and then it's get delivered to your location, okay? So, I used to order biryani. So, that's what convenience means, okay? So, it could be control uh one aspect of your life, and for some part of your life, you are choosing convenience over control, okay? So, that's the idea of our

today's talk, that how would you choose this control and convenience if you have to make that decision. Okay, let's go to technical terms. So, what's control? Well, no no not this control which you see on screen right now. Uh control basically means that you define every aspect of the system. Whatever system you're designing, you describe it uh end to end. Uh it could be anything, okay? Uh

but, you define the every aspect of your system. Uh some of the examples, if I take, the first example could be your self-managed environment or the infrastructure. Uh like let's say you are installing your software on on your own, right? Uh you are not dependent on anyone, okay? That could be one of the example. Another example could be fine-grained configurations. Uh if I compare it with some

of the solutions, let's say either am I using AWS EC2, which is a virtual machine, or I'm using some function as a service such as AWS Lambda, okay? If I talk about Lambda, you are defining very less configurations there. Let's say you define CPU cores and memory. But, in case of EC2, you can define much higher level of configurations as well. Let's say what kind of heap

memory I want to have, okay? So, there are lot level of operating system level configurations we can manage. Now, what about convenience? Convenience basically means you are offloading that responsibility to others, okay? You are not doing that extra work. So, for my case earlier, I was giving that cooking responsibility to Zomato for a day that, okay, cook my own food and get it delivered to my home,

right? But for the system use case, it could be anything like, let's say you have external team. Most of the service providers, like service companies, work on this model. You have Infosys, TCS. All these companies work on a model that they manage the system for you. They will develop the system for you. All those things. So, it could be development team, it could be support team, it

could be DevOps team, it could be anything. This is one of the example. Another example could be you could be using managed services or serverless offerings, right? In all these use cases, you are not managing the infrastructure. Let's say you are using Amazon DynamoDB, okay? Or you are using managed version of PostgreSQL. It could be Amazon Aurora. Okay? So, you are using managed services instead of managing

on their own, okay? Next example could be SaaS tools. Let's say trying to build your own application for messaging versus using Slack, okay? It's much simpler as that. So, there are lot lot of SaaS tools which are out there and which one makes sense to your use case, you use accordingly, okay? So, that's convenience for you. So, these are some of the examples. But having said that,

the definition is still contextual, okay? We define what's control, what's convenience, but it's very much true that something is which is control for one person is convenience for other. Let's take an example, okay? Let's say for control, control means uh you are you are taking an open source, let's say a database binary, and then installing on a virtual machine, okay? So, that's control for you. But, some

other people will come, they will say that, "Okay, this database is not for me. We will build the database itself in-house, okay?" So, that's control for them, okay? The convenience for them would be that taking that binary from open source. So, the definition is entirely contextual. One thing which is control for one person or one organization or one company could be convenience for Now, let's discuss on

why will you choose each of these approaches. So, the first thing is it offers system customization as needed. I will take a sip of water. Okay. So, it offers you system customization as in you can define the aspect of the system, whatever configurations you need, how the system should be deployed, how the system would be created, what kind of model it will operate on, whether it would

be whether it be synchronous communication, whether it be asynchronous communication, uh how it is working in every aspect of the use case, you can define that, okay? other thing could be that there is you don't want to do it, but there is compliance requirement. If some of you have worked in the payment industry, you might know that there are some regulations which you have to strictly follow,

okay? Uh whether you like it or not. So, inherently you have to choose that particular approach which has more control over the managed solutions. Uh another thing which it offers is there is no vendor lock-in. So, you're not dependent on the vendor. Uh I mean, what uh it could be totally possible that the vendor is disappeared, okay? So, you are vendor for any of the dependency, okay?

Uh if the vendor is no more, then you you don't depend on it, basically, right? So, even if it disappears, it doesn't matter to you. The final thing which I want to talk about is cost implications. Now, this is one of the reason, okay, then most of the companies switch to control because uh using these services like managed services or or like there is lot of cost

associated to it, okay? Uh the cost could be anything, okay? The cost could be the bill you pay for the cloud provider, that is one thing. Other uh it brings in operational overhead, right? So, if you already have that expertise, if you already have that expertise that you know that how to how you can manage it, then there is no point uh paying that provider to manage

it for you, okay? So, that's one of the things. So, you have to think on the total cost of ownership uh when I say cost implications. Now, you might have seen in the news these days, okay? Uh SaaS is dying, you should build everything on your own, like lot of CEOs are also claiming uh that we build everything uh in-house and all, right? So, again, that could

be one of the reason that we have Claude for uh Claude with us or we have GPT with us, so we'll build everything in-house, right? Why pay to some vendor for it? But, there are lot more things to consider. We'll be talking about that as well, but that's one of the idea that why you would choose control over convenience. Now, if we talk about convenience, the best

thing about convenience is it offers faster time to market, okay? When I say faster time to market, uh you can since you don't have that dependency on since you don't have to create that uh first level of infrastructure, okay? You can directly use that solution, okay? You all just have to focus on writing that code which is specific to product, if we talk about in the coding

terms. So, it offers you to move faster in the market, okay? Next thing which is related to this is since you are moving faster to the market, the reason is there is lesser operational overhead, okay? Now, when I say lesser operational overhead, you are not managing that infrastructure, okay? Uh it could be anything like uh let's say I have to do the security patches, okay? So, I

have faced this personally in my experience as well. Like for one of our use case, we were uh using Amazon EC2, okay? Uh later on for other service, we started using ECS Fargate. So, Fargate, if you don't know, it's a managed serverless uh uh containerization service which is offered by AWS. So, if you compare these two solution, if some security patch comes in, in case of EC2,

you will have to do it on your own, okay? But in case of Fargate, the serverless offering, you don't have to do it. So, there is lesser operational overhead when I talk about convenience offerings. And definitely you will require lesser talent. If you are using the solutions which requires higher expertise, then you will need people who are you who can manage that infrastructure, okay? So, we'll need

people uh with that skill set. Like right now, my company works with uh power hypervisors, okay? Which are offered by IBM. So, we will need people who can work with those power hypervisors. And that's hard skill to find, okay? Uh I'm not sure if anyone of you have even heard about power, okay? So, that that's the thing about it. You will have lesser talent requirement if you

use managed offerings. So, that's best thing about convenience. And it offers a lot of non-functional uh but or like characteristics which we see in uh Venkat uh Venkat session's as well, that there are a lot of characteristics which we need. Uh and if you want to develop those characteristics, if you want to support those non-functional requirements, uh you will have to modify your architecture accordingly. But if

you are using those convenience offerings, if you are using those managed services, then it comes out of the box such as reliability, availability, scalability, and all those things, okay? So, till now we talked what's control, uh uh why control, why convenience, and all those things, right? But now we have to do the decision-making. Uh which one will you choose? Right? It's the hardest question in the room.

Uh which one will make sense to me, okay? And I I'm not sure if you heard this term, right? There are always trade-offs. Like there is no perfect answer even it comes to software engineer, software architecture. Whenever you are trying to build a solution, there are always trade-offs, okay? If you see this spectrum, uh there is full convenience at one end of spectrum, there is full control

at one end of spectrum. And there is The point is that we figure out a way or figure out a point specifically in the spectrum that this is what makes sense to my business context, okay? So, that's what we have to do in our like we should get better at trade-off analysis, okay? We will be discussing some of the things around how can you make that decision?

So, we will start with a simple thing. We will start with simple thing by asking ourselves some of the questions. The first question is why do you need custom optimization? Uh if I say that, okay, I need it, uh you might just say that I want to explore, I want to learn some new things. So, that could be a very simple reason for most of the folks,

okay? Uh other reason could be that uh I need it because my industry demands it or there is some compliance specific requirement, okay? Uh it could be anything. You should be able to justify that, okay, this is the reason I need custom optimization for whatever I'm trying to build. Now, once you decide that, okay, I need it, now you need a team who can build that thing

for you. So, does your team have that kind of expertise, okay? It's like really important that if you're trying to dis uh if you're trying to build something, you have some kind of expertise around it. Otherwise, you will be just introducing technical debt around it, okay? So, if there is some requirement that, okay, I have to build custom solution, there is a big requirement for it, so

I have to have that skill set or I should be able to hire those people who can build this infrastructure for And the final thing is what if a vendor disappears, okay? We said earlier that in control there is no vendor lock-in, but in case of convenience, there could be vendor lock-in, okay? Let's say and it it happens uh like for some of the tools. You might

have seen that okay, this tool was available with uh uh some provider, then it was deprecated because there was lesser business with that company. Okay, it happens with you might have seen with AWS services or any of the cloud provider or any of the companies as well. Companies shut down. So, if you're dependent on that solution, okay, you chose convenience and then you are dependent on that

solution, if that vendor disappears, how will you able to make that decision? Okay. So, finally, we have to make a decision, right? But, we said that there are always trade-offs and decisions can always go wrong. So, what if the decision which you made uh is not working for you? So, the idea would be that you make a decision and revisit later if it's required, okay? we were

discussing today in the keynote session, if you attended, that there are like characteristics or there are non-functional requirements, if you want to support them, the architecture has to change a little bit. So, what kind of uh flexibility we are offering the architecture? So, you make a decision particular and if needed, you revisit it later. And we'll be talking about some of the examples that you started out

with something and then later on, you move to something else. So, the first example is around uh you started with control and then you later on switch to convenience because control was not making sense uh to my business use case, okay? So, when I was part of Amazon, uh I used to work for Amazon a few years back. So, when I was part of Amazon, uh we

used to use Amazon Chime. Uh if you don't know Amazon Chime, uh it's a uh messaging platform. It helps you for meetings, it helps you for all the team communications and all, okay? So, this was our default uh communication channel uh during COVID times as well, right? You connect with peers using it. And by the time I was leaving Amazon, they introduced Slack as well for messaging,

okay? So, we had two tools at that time. Uh we were using Chime as well as Slack uh for some of the use cases, okay? Uh the recent news which I saw was uh that they deprecated the support uh for Amazon Chime, okay? Now, vendor disappeared the use case I was talking about, okay? So, they are deprecating Amazon Chime and they are not allowing any new integrations

or not onboarding any new customers. So, they deprecated Uh and they switched to Amazon uh the Zoom and a mix of Slack. Now, if you see this use case, Amazon do have the money to control their entire infrastructure, okay? But, they still choose convenience. They started out with something. They started out with control and later on moved to convenience because that's what making sense to them. That

was their business strategy that they are not making probably as much as money which they thought they would with Amazon Chime. So, it's better to use Amazon Chime Amazon Zoom and Slack for their internal use cases as well, okay? So, this is the one example around you. You started out with something uh like you chose you make it you made a decision and then you revisited later

because that's what made sense to me. Let's take another example uh which talks about you started with convenience and then later on you switched to control. So, we'll take example of Zomato. Zomato which I said in the beginning of the session that Zomato is your online food delivery application. Now, once you select a dish, okay? Uh what you do next is you have to pay the money,

okay? So, there are different payment options which are presented to you. Uh let's say debit card, let's say UPI, let's say credit card, all those things, okay? Now, generally how these companies operate is uh they integrate with some sort of payment partner. Probably Just Pay, Razorpay in case of India, right? Uh there are multiple in like Stripe and in other countries. Uh so, how like do you

see systems I know AWS here which is not available on Zomato by the way. It's available on Amazon. But, the idea is that you make the payment. And this is how it's supported, okay? So, if I ask you, what's the most popular payment method in India? PhonePe. As in the payment method, UPI, right? UPI. So, UPI Unified Payment Interface. Uh just a minute. Yeah, UPI is the

payment method which is being which is most popular, okay? And that's how Zomato started. They integrated with one of the payment partners and they supported all the payment options through that payment partner, okay? That's how they started. And this is the convenient solution for them because they are not doing that heavy lifting of payment integration. If you want to build that payment platform, you have to take

a lot of licenses. it's it's a big turn. I have worked in payment, so it's a big turn. Uh you have to rely on a lot of compliance and regulations. You have to take licenses. You have to build the system accordingly how the data should be segregated. There are a lot of things which you have to consider, okay? So, Zomato started with convenience which is a fair

choice, okay? But later on, later on they realized that if they want to control the success rate, okay? There are a lot of factors on which success rate is dependent. Let's say you are uh two banks. Now, at a particular time, it could be possible that one bank is not working, okay? The systems are down. So, how can you redirect that user to other bank, okay? That

is one of the thing. You might have seen on PhonePe or Google Pay as well that this bank is not working properly now. You probably should use other bank for other payment to move forward, okay? So, to gain the control over infrastructure, to gain the control over the success rate, and this was the primary reason for them. To gain the control, they launched their own UPI service

in partnership with this ICICI Bank. So, they started with they started out with convenience and later on they moved to control because that's what made sense to me. So, it's okay that you take a decision and then revisit later as needed. If I talk about an example, it could really happen that or you could take mix of approach. Let's say you have a big architecture software architecture

for your system. So, it could be really possible that some part of your architecture uh is control based as a new control every aspect of that system. Probably you install your database, you manage it. But for messaging use cases, you rely on some service offered by some cloud provider, okay? It could be totally possible. Uh if you take an example from my previous which we discussed earlier,

I used to cook my own food, but I also used to order biryani, right? If you haven't tried biryani, you should try it. It's my favorite dish. So, yeah. So, it's a combination of what controlled and convenience. You can take whichever approach and you will have to do the trade-off analysis that which makes sense to me. So, we will be talking about a balanced approach, okay? Uh

what kind of things you can consider, okay? It might not be as balanced as how Thanos want. Uh like 50/50, but we can still try that, okay? Uh it's There is uh some things uh which we can consider, okay? So, the first thing is adopt norms, but check always, okay? So, what do I mean from this is there could be some of the standards which are followed

in the industry per se, okay? In your particular company as well. Uh let's say for any of the new service which will launched in your company, you by default use Java plus Spring Boot, okay? So, that's your default norm. But let's say if you're launching a new service, at that time you should always evaluate if that same framework makes sense for your use case as well, okay?

Uh the database decision choice we make, it's not just for interviews, okay? You have to do that in your real life as well. That, okay, uh MySQL is the default choice my for my company. Do I have to switch to some other database? Do Does it make sense, okay? So, you can adopt norms and you can always check against uh your business context. So, this is the

first Now, once you did that, you define what works for you. Okay? You did that analysis, then you define what is working for me. And how do you do it? You do a continuous reassessment. Okay? You start We took some examples that okay, you started with one thing, then later on you pivoted to something else. So, you do that continuous reassessment that okay, you chose one approach,

then you validate you run some metrics probably, you gather user feedback. All those things you do, and then you reassess that is that this approach sense uh makes sense to me or not at this particular point as well. And one such thing which can be leveraged for this is OODA loop. Uh what it means is it means observe, orient, decide, and act. Okay? OODA. Uh in observe

phase, what you do is you gather data. Okay? For a system use case, you might say that okay, what are my system requirements? Uh what are some of the things which I have to take care of? Uh what are the expectations from my system? Okay? Uh what is my system not expected to do? So, you do that analysis that I'm gathering the data for the system I

want to build. Okay? This is the first phase. Once you did that, you move to the synthesis phase. Okay? These are my requirements. Now, I match these requirements to what I'm building. Okay? Let's say these are the requirements. Now, I am suggesting that this should be the architecture, but does this architecture uh will be able to like will I be able to afford the cost for this

architecture? Okay? If I say that okay, this is what I'm choosing. Can I bear that cost? Okay? That is one thing. Other thing could be uh does it match to my long-term vision? Okay? How I perceive my company or my team moving forward? That could be other thing. So, you do analysis and synthesize in this phase. And the next you once you did that, you decide. You

choose a course of action that this is what I'm doing. And finally, you act on it. Okay? Execution phase. So, the hardest part would be uh the orientation and then making a decision. Once you do that, uh act is much simple part, okay? So, you can say that okay, these these are the dilemma which you have to solve, okay? The act is the final part. Dilemma is

already solved. Now, you can go to act. Now, it can always happen that you come back to again, okay? We are doing that reassessment again and again. So, this is the original diagram of OODA loop which I took from Wikipedia uh and if you see this diagram, uh there are four phases of it, right? That was I was uh saying. So, there are a lot of uh

inputs which you see, but the final input is that you are again gathering feedback from the last days, okay? That's what you are doing. Okay? So, this is the OODA loop for you which you can leverage or which you can use for the decision making. about is uh focusing on customer problems. Uh whenever you are doing that choosing control versus convenience, if you're trying to take a

balanced approach, right? Uh what you should always do is you focus on the business context first. Uh you don't focus on that uh resume driven thing, okay? Uh so, let's say I'm trying to build application, okay? Now, if I say that okay, this is my application and I want to I have a use case that okay, this should be multi-cloud. What if one cloud goes down, right?

It can happen. I want to have it multi-reason. There are a lot of reason these days, right? Uh there can be a nuclear attack on uh one of the uh AWS region recently. So, there could be a lot of reasons and due to a lot of these reasons, you decide that okay, this is how my architecture should look like. And but like you can always make that

decision, but you also have to satisfy that against your business context, the customer problem you are solving, okay? Uh in the morning, we were talking about that your decision making or your thought process change uh for a startup founder versus an enterprise uh uh the engineers who are working in an enterprise because you in working in enterprise, there is less cost factor as compared to startup, right?

So, that's the thing about it. You always focus on the business context. You always focus on the customer problem you are solving, and then you try to make a decision around control versus convenience. We will end the discussion with this. The best architecture is not the most powerful, but one aligned with the business strategy. Uh the software architecture, like uh there is no perfect architecture. I I'm

sure you believe that, right? Uh even if you want to build something, it might be perfect for you for your understanding, but there would be lot of bottlenecks if you think from other perspective. You might have built something depending on the requirements you thought, right? So, there could be other things as well. For that requirements, your business or like software architecture that you came up with is

not working. So, the best architecture would be the one that aligns with the business strategy, okay? Uh it's not the most perfect one which you think. So, with this, I will end the session. So, thank you so much. And if you want to connect with me, uh these are some of the QR codes which you can scan. Uh this is the YouTube one. This is the LinkedIn

one, and this is the cover page of my book. So, yeah. Thanks so much. >> [music]