There is a paradox at the heart of modern software development processes.
On the one hand, those processes are more collective than ever before. The old days of the lone genius are long gone. In the modern world of DevOps, continuous integration and continuous delivery, extensive teams work together as seamlessly as possible. Every cog in the machine plays a vital role.
As individuals in that process, we are used to sharing our own work and building on the work of others. Software delivery is a broader, more cooperative process than ever before.
On the other hand, however, we have never been further apart. Modern software teams are rarely in the same building, and in some cases, there is no ‘building’ at all. Even large developer organizations such as GitLab, Automaticc and Basecamp either have no office at all or let employees work wherever they feel like.
Of course, most of us will be well aware that a range of technologies help square that circle and enable highly distributed teams to work closely together. From tools such as GitHub that help us collaborate on code in a constructive way, to messaging platforms such as Slack that keep everyone in the loop, there are a multitude of products that support co-working across physical barriers.
In fact, the very existence and adoption of those tools - by the open-source community, in particular, can be said to have driven the adoption of distributed development.
But it isn’t all plain sailing.
Where Do Software Assets Live In A Distributed World?
Let’s talk about software assets. In the collective processes we described above, packages are the essential building blocks of software. What we create is a collection of packages and dependencies, and is in turn packaged and made available for use by others within and outside the organization.
So centrally important are these packages that for reasons of security, availability and reliability most organizations are by now well-aware that these packages need to be stored within a private repository. In addition, of course, if we wish to protect our own intellectual property it will be absolutely essential to do this.
But where should that repository live?
The standard answer to that question today is (or certainly was) ‘on-premise in my development headquarters or datacenter’. As a simple answer to an apparently simple question, this has its merits.
First, locating packages and assets on-premises means that in theory, they are fast to integrate into build processes. Given that these processes can integrate thousands of packages and dependencies, and occur dozens of times a day, even marginal performance issues can quickly escalate into significant (and frustrating) increases in build times.
Second, as noted above it gives us control over the software assets within the organization. On-premises means under our watchful eye, or at least that is the theory.
Of course, you’ve probably guessed what the issue with this approach is. Which premises? At Cloudsmith we increasingly work with clients who have teams and individuals distributed all across the globe in dozens or even hundreds of individual sites.
And even beyond that reality, the growing rise of cloud-native continuous integration, for example, means that many of the processes that packages feed into (and emerge from) are not based on any premises anyway.
That adds up to making performance worse for the majority of the organization even whilst it looks great to the CTO and the rest of the team in HQ! To counter this issue, many organizations attempt to mirror repositories across multiple locations.
This brings its own challenges. For one, we no longer have a single source of truth for our software assets. Dependent on location, we can’t be sure that we’re all looking at the same thing at the same time, or that the same controls and permissions are being applied.
In addition, whilst it might be practical to mirror to a handful of offices, that doesn’t help teams that are spread across dozens or even hundreds of locations - including, of course, those cloud-native processes we mentioned above.
Lastly, it’s just complicated and costly. On-premises solutions are already expensive to maintain, support and scale. That is why cloud services have been universally adopted in almost every other area.
Attempting to add in mirroring of software assets across multiple locations only adds to that burden, meaning the development organization has to invest significant resources into performing this task - resources that could and should be spent actually delivering software.
Ultimately, all these approaches impose a great deal of cost for little tangible reward. In addition, they really only kick the can down the road. What happens as new locations are added?
Fortunately, there is another way...
Cloud-Native Package Management
What distributed development teams need is this:
A ‘single source of truth’ for software assets, one that is available to any team or individual, anywhere on the planet, whilst maintaining the highest levels of performance for all.
The only place that source of truth can exist is in the cloud. But there is a world of difference between being ‘in the cloud’ and being ‘cloud-native’. The former does mean that security, control, auditing and provenance can be handled in a single place, and consistently across the entire organization.
Only the latter, however, can deliver outstanding performance to developers and teams wherever they are.
At Cloudsmith, we invest a significant amount of effort into ensuring that every member of a development team, and every process you integrate packages and dependencies into, are supported in this way.
- We provide the ability to choose precisely where in the cloud your assets are stored (which you may want to control for legal and IP reasons, as well as performance)
- All packages are distributed around the world by a blazing fast global Content Delivery Network (CDN).
- We use edge-caching to optimize performance everywhere, and give our users fine-grained controls over exactly how long assets are cached for, all across the world.
- Upstream proxying caches upstream packages, reducing the amount of external repositories our clients depend on and protecting software and servers from downtime and slowness of official main repositories.
Through a combination of these features and more, we believe that cloud-native private repositories don’t have to mean ANY compromise when compared to on-premises solutions, in addition to being so obviously superior for supporting distributed teams.
If you’d like to try Cloudsmith for yourself and find out why - sign up today at cloudsmith.com!
