Live now: Hear the reasons why Replicated switched from building to buying a cloud development environment.
Join!

What Does Building Internal Software and Owning a Puppy Have in Common?

Build versus Buy (3 Part Series)

  1. The Cost and Complications of Homegrown Dev Environments
  2. What Does Building Internal Software and Owning a Puppy Have in Common?
  3. What Do In-House Dev Environments and Quicksand Have in Common? More You Struggle, More You Sink

Some of the smartest engineering and DevOps managers sometimes make the mistake of treating a new software initiative as a single, well-defined one-off project. For example, let’s say that the internal initiative in question is the engineering of a simple, clearly defined cloud development environment.

Take it from these executives who tried building:

  • Marc Campbell, founder of Replicated, says it best: “Easy to develop - impossible to maintain because every day something was broken."
  • John Craft, CTO & Co-Founder, Privacy Dynamics: “We spent 12 months building our preview environment system ourselves, but it was never as good as we wanted. We didn't have the bandwidth to manage or maintain it, and it was distracting us from our primary engineering needs.”
  • Engineering manager at a leading digital healthcare platform: “We tried to build it in-house, but that failed. Companies don't understand the complexity of what's under the hood when building their cloud dev environments, such as the custom resource definitions and technical design needed to work with Kubernetes.”

Should You Buy or Build a Development Platform?

Mommy, I want a development platform!

Building software internally, to service your company’s developers, is often an endless, ongoing project to maintain and scale while also accounting for many evolving complex connecting technologies in the world. The blind desire for companies to have their own homegrown development platform is often like the youthful enthusiasm to get a cute puppy.

In both cases, puppy love quickly gives way to the realization that there are long-term, serious responsibilities associated with its care. In the case of both, you have to make sure they are safe, secure and bug-free. If there’s a problem, you have to stop what you’re doing and take care of them morning, noon and night. They both require a lot of attention.

Turns out that owning a puppy - fleas et all - is a lot of work and costs a lot of money. So is building and managing a homegrown development environment. But it's easy to understand how engineering teams fall in love with the idea of building development environments. After all, who knows what engineers need better than the engineers themselves?

When software projects outside a company's core business are built, it usually starts when a developer or lead identifies a specific pain-point in isolation and engages internal engineering resources to come up with an in-house solution. At first glance, this approach makes sense, as internal engineering teams are good at building projects with a limited, well-defined scope. However, as your development team grows and your projects scale, so do the requirements of the platform; and complex business processes often span multiple departments, including collaboration with - but not limited to - DevOps, security, product, QA testing, and more.

Raising a Development Platform is a Big Responsibility

More projects, people, and product features means more potential problems. Sounds like rap lyrics, but this is the truth when it comes to building, especially a cloud development environment. You build it, you own it.

As puppies grow into big ferocious dogs, daily responsibilities continue and challenges can mount. It's the same problem development teams have with their homegrown solution. This predicament begs the question: why spend countless hours having your most valuable resource capital (your engineers) architect a solution that already exists and is proven in the market?

For instance, generally, a vendor has already solved the same problem hundreds of times, bringing clients the benefits of best practices based on others' experiences. In addition, in most cases, the vendor gains efficiencies because of its large customer base, so it can often charge less for implementing and maintaining an established product than it would cost to support a one-off, homegrown solution.

When you flip the script, the solution provider owns the burden of product development, quality assurance, maintenance, platform migration, security,  and patch fixes. In contrast, in-house development requires years of continued development beyond the initial project scope. There’s an opportunity cost and total cost of ownership associated with that that is often overlooked.

Okteto customers who first tried building internally found it required an enormous allocation of resources and budget to create, implement and maintain something as comprehensive and proven. Whether to build or buy a cloud development environment revolves around these four key considerations:

*Ensuring features and functionality were best-in-class

*Supporting performance and maintenance at scale

*Managing the allocation of resources against core business needs

*Realizing the total cost of ownership is more than what it seems

What issues drove Replicated to switch from building to buying a dev platform?

Working with a proven partner to deploy a proven solution allows you to solve the problem more quickly and ensures complex questions, such as Kubernetes updates and security breaches, are answered with comprehensive support and development. Additionally, working with a reputable provider to deploy a proven development platform will allow companies to get up and running more quickly and generally ensures that teams can focus on what developers do best: innovation.

Ask yourself how much time and money it will take to either buy software that will fit most of your needs or build a solution from the ground up. And how much will either solution cost you long-term? For instance, creating a cloud development platform with the sophistication to work with Kubernetes could take three to five years. When you buy software, you get a well-trained best friend that the vendor constantly cares for, grows, and babysits.

While developing a solution in-house may initially seem like the best way to address your business challenge, more and more technology leaders are seeing the benefits of buying over building. Commercial solutions provide speed, scale, and efficiency that can’t be matched by in-house solutions.  Building a cloud development platform can be ruff to manage and secure. As a result, more companies are asking cloud development vendors, "How much is that doggy in the window"?

Can't Decide Whether to Build or Buy?

Build versus Buy (3 Part Series)

  1. The Cost and Complications of Homegrown Dev Environments
  2. What Does Building Internal Software and Owning a Puppy Have in Common?
  3. What Do In-House Dev Environments and Quicksand Have in Common? More You Struggle, More You Sink
John PapageorgeMarketing / Dance InstructorView all posts