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
nodejsApplications book, the content can help any software developer to tuneup working environment. You use this link to buy the book.
Modern days infrastructure
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
For more on cheap infrastructure, visit this
githubcollection 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
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.
- Features | Netlify ~ Netifly
- Deploy your site through Netlify and add HTTPS, CDN distribution, caching, continuous deployment ~ Netifly
- How to set up CI/CD Pipeline for a node.js app with Jenkins ~ Moshe Ezderman – Medium