In part 1 of our package repositories series, important terms like packages, metadata, dependencies, and upstreams were explained. In this part 2, we will take it further, diving into trends within the software landscape that have changed what developers and organizations want from a package repository. In recent years we’ve seen a push to use managed services in the cloud, automation, supply chain security.
With companies expecting software products to handle constantly increasing volumes of requests and network bandwidth use, apps must be primed for scale. If you need resilient, resource-conserving systems with rapid delivery, it is time to design a distributed system. To successfully architect a heterogeneous, secure, fault-tolerant, and efficient distributed system, you need conscientiousness and some level of experience.
Today, we are excited to announce that Cloudsmith has secured $15 million of funding in our recent Series A round. This latest round will help us continue to build best-in-class technology for today’s software engineers and their organizations by evolving cloud-native package management and providing a secure, single source of truth for all software artifacts and assets.
Package repositories were never something I thought about as a developer unless something didn’t work. For example, if it was slow, wouldn’t connect, wouldn’t install, or was overly complicated to configure. Mostly I wanted something I barely noticed. Something simple and easy to use.
The first time I was tasked with maintaining a production server, I relied on a checklist my predecessor had left for me. The checklist contained all the maintenance steps along with their corresponding commands. In those early days, I religiously copied each command, double- and triple-checking each character before pressing the Enter key. Slowly but surely, the commands got committed to memory until one day I realized I did not need the checklist.