132 A Shared Development vs Local Services and Containers

Is it better to only have one service locally at a time in development and have everything else in a shared development environment or should everything be local? Should we use containers locally for the entire environment? These are the questions we will answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_02 0:25

Should I use a shared development environment or should I try to replicate everything from production into every developer's local machine? This is a question that's asked on the suggestion site. And if you have a suggestion, go to suggestions.imtimcorey.com, and I'll try to answer in a future episode of DevQuestions. So should we use a shared environment for development, or should we try to replicate everything locally, or should you have a hybrid solution of some kind? That's the question we're going to answer today. So my opinion, and this is an opinion, and we'll talk about exceptions because there are some. But my opinion is that you should have a local environment, meaning local to every developer, that replicates as much of production as possible, if not everything, in production. That does take some work. But let's talk about some different scenarios and why I think it's important that you have everything local, not just some stuff. Okay? Let's start with a simple example. So let's think about if we have one C solution, maybe a couple of projects in there, but you know, one solution and then one database. That's your uh your entire environment. So your production application might be one web page or one website or one web application or one desktop application, something like that, whatever it is, with one database. Let's say a SQL database, doesn't really matter. So that's our simple solution. Well, why should we have everything fully on the developer's machine, all the way locally? And the answer is what's called the developer loop or development loop. And what that is, is the feedback loop. It's when you make a change and you quickly see what it does and quickly see how it affects everything else, and can quickly change that and iterate on that process. So why is this important to do locally as opposed to with a shared development database, for example? Well, let's just say that you are going to test specific data. Maybe you were given a bug to fix where every 1000th time that you enter something in the system, everything crashes. Well, that's a pretty specific bug you have to track down and fix. And maybe you find a solution for it, but how do you test that? Well, you put a thousand in, just to be sure. And when you do, it either crashes the system, which means you didn't fix it, or it doesn't. But imagine if you were on a shared development environment. If you add a thousand new people into the database, well, that might mess somebody else's testing up. Maybe they were testing, you know, how many records in the database and all of a sudden it keeps changing and so their tests are off. Or maybe they're trying to do something where they delete certain users, but but you're adding users and that causes problems. So you're gonna have a conflict of who's testing and who's trying things out is more important. And so one developer has to slow down in order to let the other developer do their work. It's kind of a work in series instead of a work in parallel. Now it's not all the time. A lot of times you can work in parallel, but there are times when you both need the same resource or you both want to affect a certain table in a certain way, or something like that, where you would cause a conflict. The other thing is a breaking change. Imagine if you are a newer developer. Let's say a junior level developer, you just started and you're working on this, and you say, hey, you know, I'm gonna write this new SQL query to do something on just a dev server because we're trying this out. And you're trying something out, and you you know, you want to delete one record. And like almost every SQL database developer ever, you forget once to put the where clause on your delete. And you delete every user out of your development database. It's not a problem, it's only development, right? Yes and no, because yeah, it didn't hurt anybody in production, it didn't delete any real data. You're safe, and that's why you should have a development environment and not work on production. But you still cause a problem because it's not just you that's down. Imagine you have a team of 10 developers. Well, all those developers are gonna be using that same shared development environment, that same shared development database. And all of a sudden, all 10 are down because they can't test against the user table because there are no more users, because you deleted them all. Well, that's a problem because now it's not just that you took your database down, you took the entire team's database down. And so you're not just costing the company your time, you're costing the company the time of the entire team, 10 people. So that gets much more expensive and it slows everything down. You see a theme here? Whenever you have a shared environment, things cause it to slow down. So if the other thing is if you're doing testing and maybe you're doing a performance test to see how things have changed, well, you have to tell everybody else, pause what you're doing on a development server, I want to see how this performance compares to the last time I ran this. Well, you can't have somebody else doing work too, because that would slow down the SQL Server and that would throw off your performance numbers. So you kind of need to tell everybody to get off. So just like deleting the database, you're gonna be waiting, having everybody wait on you to fix things or wait on you to get your test done. And so it again creates this backlog of people waiting. So that's a simple environment. And that's probably the simplest application you can have, especially with a team of more than one person. Um, that's probably the simplest thing you're gonna see. Let's talk about if you get into more complex examples. Because this is where the the um the really the advice of well, keep everything in one development environment seems more practical. And that's if you have a microservice environment or you have some other large, complex set of servers and interactivity that's happening that you think, well, I can't replicate that locally. I shouldn't have to, right? I'm just gonna do it on a shared development environment. And maybe we'll pull down just the thing we're working on and test that locally, but against the shared environment. And that's the more common uh example of when people think, well, I should have just that shared environment. And so let's talk about that. So a complex example. Let's let's keep it simple in our complex example. So we have two applications. We have a Redis cache, we have a MongoDB database, we have a SQL database, and we have some sort of message queuing system, whether it's RabbitMQ or Azure Service Bus or whatever it's gonna be, but we have this is our environment. Okay, so it's a little more complex. This is a really small microservice environment, but that's what a microservice environment might look like. Okay. So what issues do we have in this type of scenario when it comes to a shared uh development environment, even if we pull some things down locally? Well, first of all, the same issues all apply. If you're testing specific data, or if you break things, or if your changes take time to test or complete, you're still gonna have that backlog. Well, what if let's see some additional things that might be a problem? What if we decide we're going to um test adding something to the queue? Okay, so your application is, let's say, the web application, one of them, and it talks to MongoDB and and what it does is it processes queue messages. Okay, so you decide, well, I'm gonna add something to the queue. Well, remember that the whole purpose of a queue is it doesn't know who it's talking to. It just says, hey, I've got messages here. What if those messages affect other services? Well, now you're affecting other services in your development environment that aren't local that could cause a problem with somebody else who is testing. Maybe they're testing what happens when the queue is empty, but you're filling the queue up. Or they're testing what happens when a certain queue message comes through and now it's buried in the noise. Okay, so messing that queue could be a big problem. What if you decide to change the structure of the database? Well, if anything else is depending on that database structure, you've got a problem because now applications are breaking because they depended on that database structure that you've now changed and you haven't changed those two. And so you want to have everything locally. Now, quick aside right here, if you're talking about true microservice environments, they shouldn't be sharing a database. Therefore, a database structure change shouldn't affect anybody. However, that's not always the case. There are times when the people forget or people decide to cut a corner and then rely on that database. It does cause a bad problem. And it's one of the reasons why you should really think hard about if you need to do microservices and if you do, making sure that you enforce some really strict rules around it. That's a kind of an aside. But let's just say that more than one application depends on a particular database and you change the structure. That could be a problem. All right. Simulating failure. What if you decide, hey, I want to simulate what happens to my application if the queue goes away? Maybe you're gonna change the IP address or you're gonna turn the queue service off entirely. Well, all of a sudden, now nobody has access to that queue. And yes, other services dependent on having that queue available, and it's not anymore. And maybe you that's a good test to make sure you know what happens to those other services, but what if other people are depending on that queue to be available in order to do their testing? That's a problem. All right. So, and there's lots more to go into. What if you have the cash go down or you take the cash down intentionally, and the list goes on of things where maybe you're working on a specific web application, but you need to affect other services, or you need to test what happens when things happen to those other services. Other people depend on those same services. So my recommendation is to bring everything down to the local machine. The benefits there are pretty enormous because not only can you have that faster cycle of test, check, and verify, but you don't affect the rest of the team if you have a big problem. There is no chance of a central failure of the development server. What if the development server gets a bug or a virus or just crashes entirely? Well, no problem. You still have your local development environment, you can all still work. What happens if your laptop crashes? It's a bummer and it's gonna cause you problems, but it won't cause the rest of the team problems. So it's a big difference as far as the resiliency of your development team. And development speed is important, right? So I recommend pulling everything down. Um yes, I do recommend having a shared development environment, but it doesn't serve the same purpose as your local development environment. Your shared development environment should really be about integrating all the changes, making sure they all integrate properly when you're ready to commit them, making sure that you're ready to go on to the next stage of testing and QA and production. So it should really be the first step in your deployment, in my opinion, rather than just be your place where everyone does work. All right. So instead of having a failure of one person affect everybody, it's going to be a failure of one person that affects one person. So yes, there's a really big reason why you should work locally. Now, I said there's going to be exceptions. And yes, there will be exceptions. Not many, but there will be exceptions. I think that exceptions are really going to be pretty rare because you really should be able to replicate as much as possible locally. And if you can't replicate everything, you need to think through is that really true, or is it just that we haven't found the right solution for that? Now, there are tools to help you with this. Uh the biggest one probably is automation, whether you create scripts, whether you use like GitHub Actions or Azure DevOps and the pipelines there, whatever you use to automate even your local process. For instance, I've got a video on YouTube where I talk about using Docker to automate the uh the taking your backup from your SQL database and restoring it to a clean Docker instance that's been scrubbed and doesn't have any sense of a personal information in it, but that you can have running automated in the background that developers can just pull that image down and say, there's my database. So stuff like that you can do a lot. Docker, like I mentioned, is a big tool because you can have things like Redis and a cache or a message queuing system and your log server and a whole bunch of other things all running in containers so that when you don't need them, you turn them off. When you need them, you turn them on, and it's very efficient on your system. This does mean that developers' machines should probably be pretty of pretty performant. You probably shouldn't be looking at the cheapest possible laptop to be your development machine. Now, I get it. If you're just getting started, if you're self-funding, there's a reason why you might do that. And that's okay as you get started. But as you are working for a company, if you're working for in a larger environment with a team, you should have the resources to invest in the things that will make you back money. And this is one of those areas where it's going to make you back money because additional performance in your laptop, additional performance in your desktop, I prefer a desktop for working with development, the more performance you have, the more efficient you will be. Therefore, the more you'll get done and the cheaper per hour you will be, because you're getting more done. And therefore, you you the what you accomplish is greater for the number of hours you put in. And that's important. So Docker is a big deal, but another one that's kind of newer on the radar, it's still developing, it's still being developed and kind of brought up to. I'm not even sure it's version one yet, but uh Project Tie is another solution that can be really helpful for this kind of thing, because not only can you use it to automate, kind of like what you do with maybe a Docker Compose or something like that, but you can also use it to run your systems locally where they're all running outside of containers. That way you can debug multiple applications if you have a microservice type structure, multiple applications at the same time using Project TI. So that's another solution. There's a lot of solutions out there. You don't have to have a full Kubernetes installed on your machine in order to test out what or simulate what would be in a production environment, even if it is a Kubernetes environment. So there's a lot of different options out there that you can do, but I'd highly encourage you when you're developing to have a full environment on your machine. Get it there so you can make mistakes, you can break things, cause problems, and reset and only affect you, not your entire team. The cost difference for your company will be huge. Because again, taking the time of one developer is a lot cheaper than taking the time of a dozen developers. So those are my thoughts on why you should have a local dev environment. Now, if you're a team of one, put the environment wherever because it's just you. But eventually you're gonna want to have that locally. Another benefit there would be you can work on a plane. You can work without internet. There's reasons why having a local environment is still very, very helpful. It's just not every reason will apply because you only have one person. Okay, thanks for listening. And as always, I am Tim Corey.

SPEAKER_01 17:56

Thank you for joining us for this episode of Dev Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamtimCore.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to IamtimCore.com and enroll in a course.