DEV Community

Cover image for Build from Scratch vs. Developer Platforms
Niklas for Rig.dev

Posted on • Updated on

Build from Scratch vs. Developer Platforms

Developers face multiple challenges when building and deploying robust applications to the cloud. Choosing between building everything from scratch or using a managed platform for developers can significantly impact scalability, complexity, and timeline.

What to choose?

In this article, we will look at the factors to consider when selecting the right frameworks and platforms to build and deploy backend applications to the cloud.

Factors to consider when selecting what platform to build on

  1. Deployment Simplicity: How easy is it to deploy applications? Platforms that simplify deployment, especially those tailored for Kubernetes, can be invaluable.
  2. Kubernetes Integration: Given the dominance and capabilities of Kubernetes in the cloud ecosystem, it's crucial to consider how seamlessly a platform integrates with it.
  3. Flexibility vs. Structure: Does the platform offer the flexibility to design your application architecture, or does it impose a specific structure?
  4. Scalability and Performance: The platform should scale with your application's growth, ensuring consistent performance irrespective of user demand.
  5. Open-Source Foundations: Platforms built on open-source technologies, like Kubernetes, offer more control and reduce vendor lock-in risks.

Ways to build backends

Generally, there are two prominent approaches to building backend applications and deploying them to the cloud:

  1. Building from scratch: Building the backend application and infrastructure environment from scratch. Developers are responsible for everything, from design, code, test, etc.
  2. Choosing between BaaS or PaaS providers: Building applications on top of a Backend-as-a-Service or Platform-as-a-Service provider. Developers don't need to code every feature or set up complex infrastructure while building the backend.

These platforms provide pre-built backend services and infrastructure, allowing developers to focus more on application-specific logic and frontend development. However, they come with certain limitations, such as constraints in customization, integration challenges, and potential vendor lock-in risks.

Building from scratch

When developers opt to build from scratch, they're diving deep into the realm of granular control and customization. This approach demands:

  • Application Frameworks: Selecting the right programming language, frameworks, and protocols tailored to the backend application's needs.
  • Infrastructure Choices: Making decisions about deployment strategies and scaling mechanisms. With the rise of container orchestration, many developers are now considering Kubernetes as their go-to for deployment, given its flexibility and scalability.

While this method offers unparalleled customization, it's a challenging path. The complexities of design, coding, testing, and maintenance often offset the allure of complete control. Moreover, while powerful, the intricacies of Kubernetes require a steep learning curve and expertise.

Let's look at the Pros and Cons of Building from Scratch

Pros

  1. Complete Customization: Developers have full control over every aspect of the backend architecture. This level of customization is ideal for projects with complex requirements.
  2. Ownership and Independence: Developers have complete ownership of the codebase and infrastructure. Organizations are not reliant on third-party services, reducing the risk of vendor lock-in.

Cons

  1. Time-Consuming: Building from scratch requires significant development time as developers must design, develop, and test every component of the backend application.
  2. Expertise in multiple skills required: Creating a robust and scalable backend demands skilled developers with expertise in various technologies and databases.
  3. Code Maintenance: Developers are responsible for all the ongoing maintenance and updates, adding to long-term development costs.
  4. High Development Cost: As everything is developed and maintained by the development team, organizations have to spend potentially higher for specialized skills and third-party tools.

Choosing between already existing platforms

Already existing platforms for building the backend alleviate the pressure of building and managing everything independently. Developers don't need to code every single feature or infrastructure. Hence, they can focus more on streamlining the development and deploying fast.

BaaS platforms offer pre-built backend services and infrastructure, allowing developers to sidestep some of the complexities of backend development. However, they can sometimes limit customization and flexibility, especially for projects with unique requirements.

PaaS platforms provide a more comprehensive environment for development and deployment in the cloud. They offer greater control over the infrastructure but might require developers to grapple with the complexities of platforms like Kubernetes.

Pros and cons of using a BaaS provider

Pros:

  1. Rapid Development: BaaS platforms come with pre-built backend services, enabling developers to develop and deploy applications quickly.
  2. Documentation: Popular BaaS solutions like Firebase and Supabase often have extensive documentation, simplifying integration with front-end applications.

Cons:

  1. Limited Customization: While BaaS platforms offer convenience, they might not cater to projects with unique requirements, especially those that benefit from Kubernetes' scalability and flexibility.
  2. Vendor Lock-In: Relying heavily on a specific BaaS platform can lead to dependency, making migrations challenging.
  3. Scalability Concerns: While BaaS platforms are convenient, they might not be optimal for projects with high scalability demands, especially compared to Kubernetes-based solutions.

Pros and Cons of Using a PaaS Provider

Pros:

  1. Reduced Infrastructure Overheads: PaaS solutions minimize the need for managing on-premises infrastructure, leading to cost savings.
  2. Kubernetes Integration: Many modern PaaS platforms now offer Kubernetes integrations, allowing developers to leverage its scalability and flexibility without diving deep into its complexities.

Cons:

  1. Initial Complexity: PaaS platforms, especially those centered around Kubernetes, can have a steep learning curve. Developers must familiarize themselves with the platform's ecosystem, APIs, and constraints.
  2. Backend Feature Development: Unlike BaaS, PaaS solutions might not offer essential backend features out-of-the-box. Developers need to build these or integrate third-party solutions.
  3. Provider Dependency: Committing to a specific PaaS can lead to dependency on its services and features, potentially complicating future migrations.
  4. Vendor Lock-In Risks: Utilizing unique features of a PaaS can lead to vendor lock-in, making transitions to other platforms or solutions challenging.

Which platform to choose?

The rise of Kubernetes has reshaped the application development landscape. Its scalability, flexibility, and robustness promise has made it a cornerstone for many modern applications. However, with its power comes complexity, leading developers to seek platforms that simplify its intricacies without compromising its capabilities.

Platforms like Vercel and Netlify have revolutionized development in the frontend domain by offering streamlined workflows, automated deployments, and seamless framework integrations. They've set a benchmark for what developers expect from platforms regarding ease of use and efficiency.

The backend world, however, presents its own set of challenges. Traditional BaaS solutions, while convenient, might offer more scalability and flexibility than Kubernetes-centric projects demand. On the other hand, PaaS solutions, even the few that integrate with Kubernetes, can sometimes introduce unnecessary complexities that hinder rapid development.

So, what's the ideal solution?

Enter Rig.dev

We are currently building in the process of building Rig.dev - an open-source application platform for Kubernetes, designed to eliminate its inherent complexities. We seek to empower developers with a developer-friendly deployment engine that simplifies the process of rolling out, managing, debugging, and scaling applications on Kubernetes. With features like Capsules and rollouts, a slick Dashboard, and a CLI for terminal operations, Rig.dev aims to provide developers with powerful and intuitive tools.

Rig.dev is not just another platform; it's our vision for the future of application development. It promises an application platform that evolves with your needs, all while ensuring the freedom to choose and transition between any cloud provider that supports Kubernetes.

We are not done building yet, but we would love your support on Github along the way 🙏

Pleeease star us on Github

Also, please join our Slack to share feedback, report bugs, and suggest features.

Top comments (3)

Collapse
 
efpage profile image
Eckehard

The never-ending dilemma for backend engineers

Do you think, things are different for frontend engineers? It's the same here, just tools are different.

Collapse
 
niklasrefnov profile image
Niklas

@efpage You are absolutely right. Both frontend and backend engineers face similar dilemmas when it comes to choosing between building from scratch or leveraging existing platforms and tools. The primary difference, as you pointed out, lies in the specific tools and technologies available to each. It's a testament to the universality of these challenges in the software development world, regardless of the specific domain. Thanks for highlighting this!

Collapse
 
efpage profile image
Eckehard

There are many tools today, that adress only a very specific task. They solve one single problem, but give you two new limitations at the same time.

We should focus on solutions, that might do a good job also 5 years later.