Simple Engineering

cloud

Access to servers via cloud infrastructure raised the bar of what can be achieved by leveraging third-party computing power. One area amongst multiple others is the possibility to centralize code repository and development environments in the cloud.

This blog is a collection of resources until additional content lands in it

In this article we will talk about:

  • Leveraging third-party services for front end development
  • Leveraging cloud-native IDE for backend development
  • Deep integration of github with cloud-native IDEs
  • The code to move the development to the cloud
  • Services available for cloud development
  • Remote debugging using tunneling

Even though this blog post was designed to offer complementary materials to those who bought my Testing nodejs Applications book, the content can help any software developer to tuneup working environment. You use this link to buy the book. Testing nodejs Applications Book Cover

Cloud IDE

Unlike the front-end dev environment, backend code IDEA is a little tricky. Requirements of backend code are a little different from the front end, and sometimes involve a lot of moving parts. Things such as databases, authentication, payment processing systems, etc require special attention when developing code.

The following are some serious contenders to look into when wanting to move a part of backend code completely to the cloud environment.

Front End

Cloud IDE, especially on the front-end side, is getting a little more serious. Not only they remove hustle to deal with environment setup, but they also make it possible to demo end results in real-time. There is an increased capability to ship the code as early as possible. There is a myriad of those, but these two stand out.

Databases

Tunneling for remote debugging

It is quite a challenge to debug certain things, the WebHook from a live server is one of them. The following tool makes it possible to test those. It would be even easier if the development environment was entirely cloud-powered.

Miscellaneous

Conclusion

In this article, we reviewed possibilities to move development to the cloud, the cost associate with the move, and cases when that move makes sense. There are no additional complementary materials in the “Testing nodejs applications” book, but can be a good start to centralize testing efforts.

References

#cloud #nodejs #github #cloud-idea

For practical reasons and ease of maintenance, deploying smaller portions(atomic deployments) to different platforms is one of the strategies to achieve zero-downtime deployments. This article discusses how some portions of a large-scale application, can be deployed to various cloud services, or servers, to keep the service running even some nodes stays down.

In this article we will talk about:

  • Cloud is somebody else's servers, therefore can fail
  • Plan B: Alternative services to provide when the main server is down
  • How to design the application for resiliency, avoid cloud vendor lock-in

Even though this blog post was designed to offer complementary materials to those who bought my Testing nodejs Applications book, the content can help any software developer to tuneup working environment. You use this link to buy the book. Testing nodejs Applications Book Cover

Modern days infrastructure

Cloud and serverless are somebody else's servers. As long as the server is in the equation, failures that lead to downtimes and whatnot are always going to be there, in one way or another. The price tag associated with running the application on somebody else's server, versus what it costs to roll out own infrastructure should also come into the picture when talking about nodejs infrastructure.

For more on cheap infrastructure, visit this github collection about free or cheap platforms good from prototype to beta version of your app.

Since Cloud-native and serverless platforms are servers at their core, meaning: can fail, having a Plan B or alternative services to back up to when the main service is down making a good investment.

To solve the nodejs infrastructure equation, we always have to solve the “how to design the application for resiliency, while at the same time avoiding cloud vendor lock-in” equation. The good ol' server, hosted on bare-bone metal server, takes time to set up, but solve a whole range of issues while, at the same time, keeping our independence intact.

To compensate, there are some CDN that we can tap into, to get assets faster to the user. The same applies to distributed caching solutions, that can save the main service dollars when paying for traffic.

In any case, it can be a good thing to split code into chunks that can be deployed to different servers. For example, in the case of pictures are hosted on one service(Netlify, etc), the database service(server) can be a completely different platform, and the REST API or messaging service, another.

For more on cheap bare-bone server providers, visit this link to make a choice

Conclusion

In this article, we revisited how to achieve cloud vendor lock-in independence, when, at the same time build resilient nodejs applications. There are additional complimentary materials in the “Testing nodejs applications” book.

References

#nodejs #cloud #serverless #discuss