Developing in the Cloud vs. Developing in Local – Security Boulevard

Get our new blogs delivered straight to your inbox.

Subscribe

Well make sure to share the best materials crafted for you!

4 minutes read

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 todays 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.

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 isnt possible anymore because there are too many services, and several of themas well as the networks between themare managed by their providers.

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.

Its 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 todays development environment, however, geography doesnt equate to control. Control can only be achieved when you understand the systems youre 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.

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 dont have to pay for any resources; even an Internet connection is not required.

You can use logs, and its easy to debug code. But it is becoming an increasingly poor option for developers building distributed applications.

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.

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.

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 doesnt have to be. There are several solutions out there that have on-demand pricing, so simply deploying them wont 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 its crash-proof: It does not rely on developers hardware, and its not limited by the speed of developers hardware. It can be even faster and not expensive at all, provided it doesnt 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 companys size.

Its not pleasant when the developers 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.

Its 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.

Thundras 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 Thundras 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 Sidekickand 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 todays 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.

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 isnt possible anymore because there are too many services, and several of themas well as the networks between themare managed by their providers.

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.

Its 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 todays development environment, however, geography doesnt equate to control. Control can only be achieved when you understand the systems youre 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.

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 dont have to pay for any resources; even an Internet connection is not required.

You can use logs, and its easy to debug code. But it is becoming an increasingly poor option for developers building distributed applications.

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.

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.

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 doesnt have to be. There are several solutions out there that have on-demand pricing, so simply deploying them wont 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 its crash-proof: It does not rely on developers hardware, and its not limited by the speed of developers hardware. It can be even faster and not expensive at all, provided it doesnt 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 companys size.

Its not pleasant when the developers 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.

Its 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.

Thundras 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 Thundras 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 Sidekickand 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 todays 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.

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 isnt possible anymore because there are too many services, and several of themas well as the networks between themare managed by their providers.

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.

Its 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 todays development environment, however, geography doesnt equate to control. Control can only be achieved when you understand the systems youre 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.

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 dont have to pay for any resources; even an Internet connection is not required.

You can use logs, and its easy to debug code. But it is becoming an increasingly poor option for developers building distributed applications.

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.

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.

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 doesnt have to be. There are several solutions out there that have on-demand pricing, so simply deploying them wont 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 its crash-proof: It does not rely on developers hardware, and its not limited by the speed of developers hardware. It can be even faster and not expensive at all, provided it doesnt 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 companys size.

Its not pleasant when the developers 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.

Its 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.

Thundras 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 Thundras 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 Sidekickand start debugging at lightning speed!

See the original post:

Developing in the Cloud vs. Developing in Local - Security Boulevard