DDEV v Build-it-yourself

Despite its appeal, if building your own local development and live deployment solution isn’t your core business, you should consider a fully-supported, open source solution like DDEV. It offers you a much better long-term balance in terms of focus and cost, meeting your needs efficiently while remaining transparent, flexible, and extensible.

Whether you’re leading a team of developers at a digital agency or an in-house digital department, your problems with choosing the right tools for the job are the same. You have to produce websites, compelling digital experiences, or deliver real digital transformation at a breakneck pace with consistent quality and under changing conditions. To do that, you’ve probably standardized your playbook. How do you kick off new projects? How should your team respond when things go wrong? A standardized solution for local dev and deployment is undoubtedly part of that playbook.

Now the question is: how should you build and maintain it? The idea of creating a bespoke solution with new tools is enticing for developers. But maintaining it? Not so much fun a few months down the line. If building—and maintaining—this tooling isn’t part of your core business. The excitement of today’s new shiny toy can turn into resource and priority conflicts, lost time, and excessive costs in the long term. And yet, many organizations choose this path. It’s what DRUD’s founders did a few years ago when they built what has become DDEV. At the time, they couldn’t find anything that fit their needs. A couple of years on, the landscape is different—there are some excellent tools available for you.

DDEV-Local is ideal for integrating with the other tools in your dev-to-deploy toolchain and into larger modern workflows—think DevOps et al. While tools are only part of the equation, alongside culture and practice, they can either save you time and money or cost you. It may seem smart to build your custom-tailored, containerized local environment or even a hosting solution, but the long-term drain on resources can be prohibitive. DRUD’s business is building, supporting, and maintaining this tooling; if it’s not at the core of what you do, it might not be the best investment for you.

Building and maintaining these solutions is DRUD’s core business. They’re here to make your dev-to-deploy workflow simpler, faster, and better. They like to say, “We’ve got your back, go make something awesome.”

The allure of build-it-yourself and the new shiny

It’s a credit to software developers that they jump at the chance to learn new tools and techniques. If it weren’t for their relentless interest in shiny new toys, the web itself wouldn’t perform as well, nor look as good as it does today for a range of users and devices. New languages and methods are absorbed quickly. Novelty itself is motivating, but by definition, the novelty wears off, and the reality of long-term maintenance can be a drag—on your mood and your resources.

The sheer expanse of the web developer roadmap—From scripting languages to package managers, and front-end frameworks to task runners—means that no one person can ever master it all. Changes happen so fast that developers can be overwhelmed with the amount they feel they have to learn. One solution is to specialize and focus on your niche area of expertise, and to have best practices in place like standardized tools and documented workflows, for example, to bring everyone up to speed quickly.

DDEV-Local user and senior team lead, Brandon Williams, said one of the reasons he loves DDEV is, “you can focus on building the products rather than supporting building the products.” Instead of spending time creating and maintaining tools, he can focus on his company’s core business where they are delivering value for their customers.

Prioritize your core business

It can be hard to resist the idea that what you make yourself is going to be the best fit for your situation. However, are you putting the needs of your core business and customers first?

Imagine a fine-furniture maker launching their business. Should they start by building the building for their workshop? Then forging hammers, making saws, and lathes? They might have the know-how. “How hard could it be?” Famous last words! Wouldn’t it make more sense to move into a building, buy and install the right tools, and make furniture right from the start? It would be the most efficient path to delivering the highest value creative work they can do. Why do we see software any differently?

The slippery slope starts like this: “We’ll just build it ourselves. We’ll get exactly what we want! We’ll never have to compromise!” The “Not Invented Here Syndrome” is a classic anti-pattern in software development. Some companies would prefer to reinvent the wheel, which is good if you plan to learn more about making wheels. But if you’re not in the business of making wheels, why would you waste time and effort to reinvent them?

It’s not just start-ups that are looking for lean approaches to growing their businesses. All business leaders are concerned with the bottom line. You need to stay focused on the value you’re providing customers. Every company should be parsimonious and question costs where it makes sense. Monthly per-seat subscriptions for key services can eat away at your budget. You can always strategically reinvest the money you save. But it seems ludicrous to me to think any company today would waste time distracting themselves from their core business to create and manage all the myriad applications they rely on every day: customer relations management, billing, chat, hosting, document creation and management. In every case, you need to choose a vendor or choose to build in-house.

What problem are you trying to solve? What value are you delivering? If your company isn’t in the business of offering CRM services, or chat tools, or hosting, or word processing, why would you want that burden on your bottom line? You would be burning potential revenue by eating up time your developers could be using on your core business.

Just how much money are we talking about? The Baremetrics Build v Buy Calculator crunches the numbers for you. Plug in the yearly cost of the ‘buy’ option, and then add in the cost factors for building it in-house. How long does it take to build? How much is a developer’s salary? How many days of maintenance per month. The results are often clear: “Don’t build! It’s not worth it!”

Nonetheless, we venture on building our own custom infrastructure, even when there are freely available open source solutions.

Building your own dev-to-deploy solution

It’s a lot of work to maintain your own systems to manage local development, deployment, and hosting with containerized solutions. This work is often taken on by senior developers and team leads to ensure that the tool is secure and won’t cause more trouble than it solves.

If you’re planning to develop your own Docker environment, for example, you have a lot to take into account. For starters, you might have wanted to get away from VMs, shifting to Docker for a lightweight container image that can be shared quickly to build the containers locally. You’ll need a Dockerfile, Docker-compose file, environment variables, and services to connect to the database and project as well as a tool like Jenkins to manage dependencies and build-tasks.

If you’re adding on deployments and hosting, you might also want to look into Kubernetes to create container clusters to push to your live environment. You’ll need to define deployment.yml, services.yml, among other things to set up a cluster locally. Kubernetes is deployment-environment-agnostic and has a large open source community around it, plenty of add-ons, and the ability to have all of your cluster/deployment configuration in code—which is why it’s in DDEV, too.

Custom, in-house tooling can be an awesome learning experience, and provide the exact thing you want, but it’s also a cascading decision that accrues more debt, weight, time invested, bugs, and issues over time. Eventually, the costs of maintaining it are greater than the benefit you gained from creating a completely custom-tailored solution in the first place. If existing tools get the job done well, and they’re supported by a focused, fully-committed, third-party development team, that team will be working for you continuing development and integrating new services … all while you are still laying the groundwork, falling farther behind, and accruing technical debt.

DRUD’s core business

The DRUD team built DDEV while working through their own challenges at a digital agency. When they were looking for tools, there were few options available. Today, just for Drupal, there are 37 local-dev solutions and counting! However, most of the solutions are from vendors who can’t commit to supporting them because they’re side-projects taking away from their core business. Building and maintaining these solutions is DRUD’s core business.

DDEV maintenance and improvement soon became such a big workload at the agency that it became a product of its own. A dedicated company—DRUD Technology LLC—was spun out. With deep roots in open source, the founders knew it needed a community around it to make it sustainable in the long term. Rick Manelius, one of DDEV’s original developers, pointed out, “I think this is such a critical discussion because many do not recognize the cost of building it yourself as part of the total cost of ownership (TCO). BIY may give it the exact way you need it, but you then have to feed it.”

The old open source adage, “Free as in puppy,” comes to mind. You get a beautiful, perfect puppy, but you also get the responsibility for it, feeding, walking, caring for it for years to come.

“In the long haul building your own utility is cost intensive,” says Steve Grandchamp, CEO DRUD Tech. If you’re looking for a solution, you probably already see the benefits of getting everyone using—and contributing to—the same tools and best practices for development and deployment. Up until now, there hasn’t been a clear leader.

Another part of the beauty of DDEV is that it’s entirely open source, so you can join the community, make feature requests and participate in the creation of the tooling without losing hours to learning and maintaining the entire project on your own. Take a look at the DDEV roadmap to get a glimpse of the future and how it fits with your team’s goals.

Try out DDEV before you build your own

DRUD developed DDEV to fill this need for a flexible yet managed development and hosting environment for a complete local-to-live solution, featuring seamless integration from dev-to-test-to-deploy. DDEV-Local is a tool that anyone on your team can use; you can choose to use it as a CLI or GUI application to match your working style. DDEV UI levels the playing field for everyone to get in the game.

DDEV gives you room to customize and adapt it to your specific needs while taking off your hands the burden of learning and configuring Docker containers or maintaining a complex set of services. Plus, DDEV-Local integrates with DRUD’s hosting solution, DDEV-Live, so your project can easily be pushed to production with no hiccups or integration issues. You get all the perks of Docker containers, with none of the time spent maintaining the tool itself.

If you’re ready to move away from maintaining custom tooling to working with a fully supported dev-to-deploy solution try DDEV today to save time. The DDEV developer and user communities are ready to welcome you and get your entire team started with configuration and services so you can improve your workflows and projects starting right now.


Photo by Clark Young on Unsplash

Please follow and like us: