Part of my responsibilities as a Network Programmer early in my career included supporting an enterprise implementation of Novell NetWare. It was the mid-1990s, and Novell had a dominant hold on the network operating system market. I decided it would be in my best interest to become a Certified Novell Engineer (CNE). A few months and several intense examinations later, I obtained my very own version of this certificate:
The most demanding examination in the series focused on networking concepts and the
That particular exam instilled a curiosity inside of me that has remained top-of-mind over 25 years later.
The CNE certification experience trained me to look “under the hood” when considering new technologies, solutions, and frameworks.
After having a very positive experience with my “Spend Zero Time on DevOps with Render PaaS“ publication, I felt that I needed to dive deeper to understand the design for a service that promises Zero DevOps.
Render offers a unified cloud designed for software engineers looking to deploy rapidly. The platform lives in an ecosystem that scales nicely.
Imagine being able to get the benefits of AWS, GCP, and Azure with the ease-of-use found with solutions like Heroku.
This foundational design is promoted in tandem with the Zero DevOps promise, making every deployment as simple as what is displayed below:
In this three-step model, the developer selects the service type first, then specifies some basic information for the initial deployment. Pressing the Deploy button starts the process for the service run on the Render platform.
That third step is what happens in the future. Basically, when you push changes to the specified branch (main in the example above), the code will automatically deploy onto Render without any further action.
Since this premise sounds amazing, the CNE-exam-passing side of me needs to know what Render looks like “under the hood.”
In talking with the engineering team at Render, I learned that they provide hosting services from multiple cloud providers. All the services use Cloudflare for DDoS protection and CDN.
Render has purposely focused on creating cloud, provider-agnostic solutions to avoid being tied to any set of providers or services. This means that a year from now, the technologies behind the scenes could change without having an impact on existing Render customers.
Inside the Render unified cloud, the engineering team leverages containers, PostgreSQL, Kubernetes, Go, JavaScript, Git, Redis, and Let’s Encrypt for their internal design. To support Git-based push/merge deployments, connectors exist between Render and GitHub/GitLab.
For the Render Dashboard user interface, the Render engineering team uses React and GraphQL to allow customers to configure and maintain their services running on the platform.
When I started looking at Render, I honestly wasn’t excited about what appeared to be yet another platform competing in this space. But as I started to dive deeper into the Render ecosystem, I saw a platform that is far more versatile and scalable.
To clarify, if I were to review the last five major projects I have worked on as a part of the CleanSlate Technology Group engineering team, all of them exceeded the most feasible implementation with the Heroku service.
This is because Heroku seems to be a great fit for smaller to midsize applications where scalability and flexibility over time are not concerns. This concept is often referred to as the “graduation problem,” meaning a service often has to be graduated to a more versatile option as it matures or gains momentum.
For large-size applications, Heroku can present the following challenges:
By contrast, Render provides a solution that eliminates the graduation problem—regardless of the size of the project—by providing flexible and affordable solutions at every tier of hardware and services.
Some additional benefits Render provides over their competitors:**
The software engineers at Render also realized that customers are often looking for more than just client and API services (such as JAM-stack style) for their applications. Consider these features which are already available in the Render unified cloud:
These four items are truly game changers when comparing Render to their competition.
I started looking “under the hood” at technology solutions over 25 years ago in order to gain confidence in a product, solution, or framework. I will always remember the first time I completed this exercise with Spring Boot, walking away with a high degree of satisfaction with the Java-based micro-framework by Pivotal.
Now, by completing this same exercise with Render, I feel that same level of confidence—not only for prototype-level applications but for enterprise-grade solutions as well. This differs greatly from my prior experience, where I have always maintained the understanding that I would eventually have to migrate once my “graduation problem” became a reality.
Since 2021, I have been trying to live by the following mission statement, which I feel can apply to any IT professional:
“Focus your time on delivering features/functionality which extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.”
**
**- J. Vester
I truly feel like Render adheres to my personal mission statement for two reasons. First, it lives up to the Zero DevOps promise by allowing feature and service teams to stay focused on producing solid solutions. Second, it removes the longer-term burdens associated with the “graduation problem” that you would face with every other competitor in this market.
If you are a software engineer curious about alternative options with your cloud service provider, I highly recommend giving Render a try … which can you do at zero cost just by visiting the following URL:
Have a really great day!
Also Published here