×
THANKS FOR SIGNING UP!
We’ll make sure to share the best materials crafted for you!
4 minutes read
Developing in the Cloud vs. Developing in Local
Written by Ismail Egilmez
Business Development Manager @Thundra
The tech industry has been rapidly embracing trends such as cloud computing, containerization, microservices, and managed services in recent years, and as a result, these technologies have become a part of the everyday responsibilities of software engineers and IT professionals. In today’s new era, most modern applications are built with complex and distributed architectures using these technologies and are served in the cloud.
Many applications are made in or modernized to microservices from monolith structures and designed as distributed systems. Development environments, therefore, had to change as cloud technologies became the new standard.
Will the Future of Development Be Remote?
In the past, it was simple to run the same virtual machine on your local machine and interact with it as if it were running in the cloud. Today, however, this is almost impossible if you want a realistic environment.
With the wide adoption of these new technologies, development environments for modern applications can no longer be the same. Because applications are not stand-alone, they rely on infrastructure services such as data stores and queues provided by cloud vendors or external services managed and maintained by other teams or third parties.
Although there are Kubernetes distributions that can run a cluster in your local computer, it gets harder to make tests realistic if you are using managed services in your distributed applications.
When you add managed services and start integrating them into your microservices, it might be problematic to test the resulting behavior before going to production. Doing that locally just isn’t possible anymore because there are too many services, and several of them—as well as the networks between them—are managed by their providers.
What Is the Impact of the Shift?
Developers need to control what they are building; this is a must. For decades, there has been a belief that says the more you develop locally, the more control you will have. This is actually true, but the change in our industry is inevitable.
It’s hard to create development environments that closely mimic production environments while developing distributed microservices in the cloud. Developers are accustomed to working on projects on their personal computers/local environments, even when working on large enterprise projects. This process had almost transformed into a tradition until the rise of distributed applications.
In today’s development environment, however, geography doesn’t equate to control. Control can only be achieved when you understand the systems you’re using, independent of their location.
Mocking or replicating cloud services or managed services in your local environment simply no longer translates to the real environment upon which your application will run during production. This means you are missing the chance to find potential sources of failures and not testing your applications in a realistic manner.
Pros of Developing Locally
Local development is extremely fast, easy, and free. If everything is on your own computer, then you will easily know where to find what you are looking for. Developers don’t have to pay for any resources; even an Internet connection is not required.
You can use logs, and it’s easy to debug code. But it is becoming an increasingly poor option for developers building distributed applications.
Cons of Developing Locally
Although local development is generally a common habit, the downsides might outweigh the benefits in most cases when developing distributed applications.
The development environment is not realistic locally because dependencies cannot be emulated like they can in the real world. There can be small or large differences from production environments.
Additionally, all services have to be set up locally and kept in sync during production. This can potentially be a big burden for developers to handle as applications scale.
Why Not Develop in Remote Environments?
Remote development may be a better choice for developing distributed systems based on managed services. There are tradeoffs between local and remote development, but remote development can be the optimal choice in most cases when developing distributed applications.
A staging environment can be set in the cloud and all dependencies of the service can work there. That being said, remote development still has some downsides.
Pros of Developing Remotely
Remote development is more realistic depending on how much you use it. It becomes more real as the development environment begins to get closer and more similar to the production environment.
It might seem like a drain on your wallet to recreate your local production environment remotely, but it doesn’t have to be. There are several solutions out there that have on-demand pricing, so simply deploying them won’t cost you anything. Furthermore, the load a developer creates when debugging is often negligible.
There is less of a need for mocking external resources and services and a lower risk of differences between development and production environments. Additionally, some of the security, reliability, and scalability responsibilities can be partially outsourced to a cloud vendor in remote development.
Another advantage of remote development is that it’s crash-proof: It does not rely on developers’ hardware, and it’s not limited by the speed of developers’ hardware. It can be even faster and not expensive at all, provided it doesn’t run 24/7 in pre-production.
Lastly, developers can collaborate with each other from the ground up without thinking about security issues. Using a remote development environment can aid your ability to collaborate with your team members in a company, regardless of the company’s size.
Cons of Developing Remotely
It’s not pleasant when the developer’s speed is limited; this is the explicit drawback of remote development. Since code has to be pushed to the cloud every time a change is made, development speed therefore decelerates, making it almost impossible to debug distributed complex microservices and cloud applications. These applications are built using cloud services, services provided by other vendors, and even services provided by other teams in the same organization.
It’s difficult for developers to ensure they use these services in a resilient way so that if the application crashes, they can pinpoint the root cause of the problem. Another downside they might encounter is the cost of cloud resources compared to free local development environments.
Luckily, there are third-party services, like Thundra, that can help you address these obstacles.
Thundra makes Remote Debugging possible in Distributed Microservices
Thundra’s new flagship product Sidekick was created to solve the debugging issues developers have encountered in their remote development environments, especially in dev, staging, and testing environments. It combines seamless debugging and tracing capabilities, allowing developers to quickly and easily debug remote systems.
Sidekick helps developers improve their development cycle times, which as mentioned above, is a huge drawback of remote development. Slow development cycles are no longer a problem with Sidekick when developing in remote environments. Developers do not have to search for the proverbial needle in the haystack to find integration errors in a distributed system.
Thundra Sidekick enables developers to set non-breaking tracepoints and therefore see the failures in their code without having to change it using automated instrumentation. These non-breaking tracepoints take a snapshot of the code execution while the app is running. Then, Sidekick connects tracepoints in several services in the same distributed transaction thanks to Thundra’s distributed tracing engine.
We know why developers develop in local machines: because they can debug code and fix it very quickly. But the typical cycle to fix an issue in cloud applications consists of several steps: Create a new build, deploy it to the cloud, and verify the accuracy of the fix. This is a time-consuming and daunting process. Thundra lets developers reload small changes without re-deploying code. In this way, developers improve the development cycle, gaining time and productivity.
Thundra allows you to troubleshoot issues before they impact your customers. Get started with Thundra Sidekick and start debugging at lightning speed!
The tech industry has been rapidly embracing trends such as cloud computing, containerization, microservices, and managed services in recent years, and as a result, these technologies have become a part of the everyday responsibilities of software engineers and IT professionals. In today’s new era, most modern applications are built with complex and distributed architectures using these technologies and are served in the cloud.
Many applications are made in or modernized to microservices from monolith structures and designed as distributed systems. Development environments, therefore, had to change as cloud technologies became the new standard.
Will the Future of Development Be Remote?
In the past, it was simple to run the same virtual machine on your local machine and interact with it as if it were running in the cloud. Today, however, this is almost impossible if you want a realistic environment.
With the wide adoption of these new technologies, development environments for modern applications can no longer be the same. Because applications are not stand-alone, they rely on infrastructure services such as data stores and queues provided by cloud vendors or external services managed and maintained by other teams or third parties.
Although there are Kubernetes distributions that can run a cluster in your local computer, it gets harder to make tests realistic if you are using managed services in your distributed applications.
When you add managed services and start integrating them into your microservices, it might be problematic to test the resulting behavior before going to production. Doing that locally just isn’t possible anymore because there are too many services, and several of them—as well as the networks between them—are managed by their providers.
What Is the Impact of the Shift?
Developers need to control what they are building; this is a must. For decades, there has been a belief that says the more you develop locally, the more control you will have. This is actually true, but the change in our industry is inevitable.
It’s hard to create development environments that closely mimic production environments while developing distributed microservices in the cloud. Developers are accustomed to working on projects on their personal computers/local environments, even when working on large enterprise projects. This process had almost transformed into a tradition until the rise of distributed applications.
In today’s development environment, however, geography doesn’t equate to control. Control can only be achieved when you understand the systems you’re using, independent of their location.
Mocking or replicating cloud services or managed services in your local environment simply no longer translates to the real environment upon which your application will run during production. This means you are missing the chance to find potential sources of failures and not testing your applications in a realistic manner.
Pros of Developing Locally
Local development is extremely fast, easy, and free. If everything is on your own computer, then you will easily know where to find what you are looking for. Developers don’t have to pay for any resources; even an Internet connection is not required.
You can use logs, and it’s easy to debug code. But it is becoming an increasingly poor option for developers building distributed applications.
Cons of Developing Locally
Although local development is generally a common habit, the downsides might outweigh the benefits in most cases when developing distributed applications.
The development environment is not realistic locally because dependencies cannot be emulated like they can in the real world. There can be small or large differences from production environments.
Additionally, all services have to be set up locally and kept in sync during production. This can potentially be a big burden for developers to handle as applications scale.
Why Not Develop in Remote Environments?
Remote development may be a better choice for developing distributed systems based on managed services. There are tradeoffs between local and remote development, but remote development can be the optimal choice in most cases when developing distributed applications.
A staging environment can be set in the cloud and all dependencies of the service can work there. That being said, remote development still has some downsides.
Pros of Developing Remotely
Remote development is more realistic depending on how much you use it. It becomes more real as the development environment begins to get closer and more similar to the production environment.
It might seem like a drain on your wallet to recreate your local production environment remotely, but it doesn’t have to be. There are several solutions out there that have on-demand pricing, so simply deploying them won’t cost you anything. Furthermore, the load a developer creates when debugging is often negligible.
There is less of a need for mocking external resources and services and a lower risk of differences between development and production environments. Additionally, some of the security, reliability, and scalability responsibilities can be partially outsourced to a cloud vendor in remote development.
Another advantage of remote development is that it’s crash-proof: It does not rely on developers’ hardware, and it’s not limited by the speed of developers’ hardware. It can be even faster and not expensive at all, provided it doesn’t run 24/7 in pre-production.
Lastly, developers can collaborate with each other from the ground up without thinking about security issues. Using a remote development environment can aid your ability to collaborate with your team members in a company, regardless of the company’s size.
Cons of Developing Remotely
It’s not pleasant when the developer’s speed is limited; this is the explicit drawback of remote development. Since code has to be pushed to the cloud every time a change is made, development speed therefore decelerates, making it almost impossible to debug distributed complex microservices and cloud applications. These applications are built using cloud services, services provided by other vendors, and even services provided by other teams in the same organization.
It’s difficult for developers to ensure they use these services in a resilient way so that if the application crashes, they can pinpoint the root cause of the problem. Another downside they might encounter is the cost of cloud resources compared to free local development environments.
Luckily, there are third-party services, like Thundra, that can help you address these obstacles.
Thundra makes Remote Debugging possible in Distributed Microservices
Thundra’s new flagship product Sidekick was created to solve the debugging issues developers have encountered in their remote development environments, especially in dev, staging, and testing environments. It combines seamless debugging and tracing capabilities, allowing developers to quickly and easily debug remote systems.
Sidekick helps developers improve their development cycle times, which as mentioned above, is a huge drawback of remote development. Slow development cycles are no longer a problem with Sidekick when developing in remote environments. Developers do not have to search for the proverbial needle in the haystack to find integration errors in a distributed system.
Thundra Sidekick enables developers to set non-breaking tracepoints and therefore see the failures in their code without having to change it using automated instrumentation. These non-breaking tracepoints take a snapshot of the code execution while the app is running. Then, Sidekick connects tracepoints in several services in the same distributed transaction thanks to Thundra’s distributed tracing engine.
We know why developers develop in local machines: because they can debug code and fix it very quickly. But the typical cycle to fix an issue in cloud applications consists of several steps: Create a new build, deploy it to the cloud, and verify the accuracy of the fix. This is a time-consuming and daunting process. Thundra lets developers reload small changes without re-deploying code. In this way, developers improve the development cycle, gaining time and productivity.
Thundra allows you to troubleshoot issues before they impact your customers. Get started with Thundra Sidekick and start debugging at lightning speed!
The tech industry has been rapidly embracing trends such as cloud computing, containerization, microservices, and managed services in recent years, and as a result, these technologies have become a part of the everyday responsibilities of software engineers and IT professionals. In today’s new era, most modern applications are built with complex and distributed architectures using these technologies and are served in the cloud.
Many applications are made in or modernized to microservices from monolith structures and designed as distributed systems. Development environments, therefore, had to change as cloud technologies became the new standard.
Will the Future of Development Be Remote?
In the past, it was simple to run the same virtual machine on your local machine and interact with it as if it were running in the cloud. Today, however, this is almost impossible if you want a realistic environment.
With the wide adoption of these new technologies, development environments for modern applications can no longer be the same. Because applications are not stand-alone, they rely on infrastructure services such as data stores and queues provided by cloud vendors or external services managed and maintained by other teams or third parties.
Although there are Kubernetes distributions that can run a cluster in your local computer, it gets harder to make tests realistic if you are using managed services in your distributed applications.
When you add managed services and start integrating them into your microservices, it might be problematic to test the resulting behavior before going to production. Doing that locally just isn’t possible anymore because there are too many services, and several of them—as well as the networks between them—are managed by their providers.
What Is the Impact of the Shift?
Developers need to control what they are building; this is a must. For decades, there has been a belief that says the more you develop locally, the more control you will have. This is actually true, but the change in our industry is inevitable.
It’s hard to create development environments that closely mimic production environments while developing distributed microservices in the cloud. Developers are accustomed to working on projects on their personal computers/local environments, even when working on large enterprise projects. This process had almost transformed into a tradition until the rise of distributed applications.
In today’s development environment, however, geography doesn’t equate to control. Control can only be achieved when you understand the systems you’re using, independent of their location.
Mocking or replicating cloud services or managed services in your local environment simply no longer translates to the real environment upon which your application will run during production. This means you are missing the chance to find potential sources of failures and not testing your applications in a realistic manner.
Pros of Developing Locally
Local development is extremely fast, easy, and free. If everything is on your own computer, then you will easily know where to find what you are looking for. Developers don’t have to pay for any resources; even an Internet connection is not required.
You can use logs, and it’s easy to debug code. But it is becoming an increasingly poor option for developers building distributed applications.
Cons of Developing Locally
Although local development is generally a common habit, the downsides might outweigh the benefits in most cases when developing distributed applications.
The development environment is not realistic locally because dependencies cannot be emulated like they can in the real world. There can be small or large differences from production environments.
Additionally, all services have to be set up locally and kept in sync during production. This can potentially be a big burden for developers to handle as applications scale.
Why Not Develop in Remote Environments?
Remote development may be a better choice for developing distributed systems based on managed services. There are tradeoffs between local and remote development, but remote development can be the optimal choice in most cases when developing distributed applications.
A staging environment can be set in the cloud and all dependencies of the service can work there. That being said, remote development still has some downsides.
Pros of Developing Remotely
Remote development is more realistic depending on how much you use it. It becomes more real as the development environment begins to get closer and more similar to the production environment.
It might seem like a drain on your wallet to recreate your local production environment remotely, but it doesn’t have to be. There are several solutions out there that have on-demand pricing, so simply deploying them won’t cost you anything. Furthermore, the load a developer creates when debugging is often negligible.
There is less of a need for mocking external resources and services and a lower risk of differences between development and production environments. Additionally, some of the security, reliability, and scalability responsibilities can be partially outsourced to a cloud vendor in remote development.
Another advantage of remote development is that it’s crash-proof: It does not rely on developers’ hardware, and it’s not limited by the speed of developers’ hardware. It can be even faster and not expensive at all, provided it doesn’t run 24/7 in pre-production.
Lastly, developers can collaborate with each other from the ground up without thinking about security issues. Using a remote development environment can aid your ability to collaborate with your team members in a company, regardless of the company’s size.
Cons of Developing Remotely
It’s not pleasant when the developer’s speed is limited; this is the explicit drawback of remote development. Since code has to be pushed to the cloud every time a change is made, development speed therefore decelerates, making it almost impossible to debug distributed complex microservices and cloud applications. These applications are built using cloud services, services provided by other vendors, and even services provided by other teams in the same organization.
It’s difficult for developers to ensure they use these services in a resilient way so that if the application crashes, they can pinpoint the root cause of the problem. Another downside they might encounter is the cost of cloud resources compared to free local development environments.
Luckily, there are third-party services, like Thundra, that can help you address these obstacles.
Thundra makes Remote Debugging possible in Distributed Microservices
Thundra’s new flagship product Sidekick was created to solve the debugging issues developers have encountered in their remote development environments, especially in dev, staging, and testing environments. It combines seamless debugging and tracing capabilities, allowing developers to quickly and easily debug remote systems.
Sidekick helps developers improve their development cycle times, which as mentioned above, is a huge drawback of remote development. Slow development cycles are no longer a problem with Sidekick when developing in remote environments. Developers do not have to search for the proverbial needle in the haystack to find integration errors in a distributed system.
Thundra Sidekick enables developers to set non-breaking tracepoints and therefore see the failures in their code without having to change it using automated instrumentation. These non-breaking tracepoints take a snapshot of the code execution while the app is running. Then, Sidekick connects tracepoints in several services in the same distributed transaction thanks to Thundra’s distributed tracing engine.
We know why developers develop in local machines: because they can debug code and fix it very quickly. But the typical cycle to fix an issue in cloud applications consists of several steps: Create a new build, deploy it to the cloud, and verify the accuracy of the fix. This is a time-consuming and daunting process. Thundra lets developers reload small changes without re-deploying code. In this way, developers improve the development cycle, gaining time and productivity.
Thundra allows you to troubleshoot issues before they impact your customers. Get started with Thundra Sidekick and start debugging at lightning speed!
