5 Internal Software Development Platform Challenges

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.”

Internal Software Development Is Messy

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, enthusiasm 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.

5 Challenges to Internal Software Development

But, hey, if you're committed to building here are five simple ways to build your own internal development platform (IDP) and the problems with each approach:

1. Build a custom platform from scratch: This approach allows you to build an (IDP)tailored to your needs. But this costs significant time and resources and building a custom platform from scratch can lead to issues with scalability, security, and compatibility with third-party tools.
2. Use open-source software: Using open-source software can be a cost-effective way to build an IDP, as many open-source tools are freely available. However, open-source software can also introduce compatibility issues, security vulnerabilities, and the need for ongoing maintenance and updates.
3. Adopt a cloud-based platform: Cloud-based platforms, such as AWS or Google Cloud, can provide a scalable and cost-effective option for building an IDP. But relying on cloud-based platforms can also introduce issues with data privacy, vendor lock-in, and service reliability.
4. Utilize low-code development platforms: Low-code development platforms enable non-technical users to create software applications with minimal coding experience. However, this limits control over the development process, and can also introduce issues with scalability and compatibility with other tools.
5. Use a DevOps platform: DevOps platforms, such as Jenkins or GitLab, can automate the software development and deployment process, providing increased speed and efficiency. But this can be complex to set up and requires ongoing maintenance and updates to ensure reliability, security and security.

See? 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.

Internal Software Development and Platform Building Is Hard

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.

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

Buying is Better Than Building an Internal Development 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.

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 tough o manage and secure. As a result, more companies are asking cloud development vendors, "How much is that doggy in the window"?

John PapageorgeMarketing / Dance InstructorView all posts