Development Environment & Dependencies
The ‘development environment’ refers to the place the system is hosted. A lot of developers at the time of writing are using Digital Ocean and Amazon Web Services for their SaaS deployments, however there are plenty of other systems out there, and at the time of writing, Serverless is gaining traction. Whether you go with serverless or traditional framework systems such as Digital Ocean and AWS are used because it is cost effective and fairly easy to scale up their system resources as your systems scales up.
When you’re building or deploying a SaaS business, scaling is very important. Think about scaling like a water supply system for a village vs a metropolis. The village gets its water from a well system that has a limited depth and a limited amount of water than can be pulled from the ground at any given time. Whereas a large city has multiple reservoirs, backup reservoirs, water reclamation systems, etc.
If a city were to need to run on the water systems that work for a village, it would fail immediately. The same is true of a SaaS deployment. What works for five users or fifty users, is not the same as what works for five thousand users or five hundred thousand users.
Imagine if your village was growing to a town, and rather than replace and supplement your water sources, you could just press a button and your well just produced more water and your filtration systems just filtered more water. That is the power of using a scalable system like AWS or Digital Ocean versus using your own hardware.
Dependencies are software systems that depend on other software systems to operate. Software development is the process of standing on the shoulders of giants, standing on the shoulders of other giants, standing on… well it’s giants all the way down. These days, in software development, developers are ALWAYS using other people’s work. So it is a requirement that developers use other pre-built systems in their development. In fact, there is no modern SaaS system that exists that is not built on top of another piece of software.
A good analogy for a software dependency is the use of concrete in the building of a house. The home builders don’t create the chemical formulas for concrete, mine the minerals, or mix the chemicals. They buy their foundation concrete from a concrete company, who often just comes out and pours it for them. Most of the time, the workers laying the concrete know a bit about it, but they are very rarely chemical engineers who formulated and tested it. They know how to use it, not create it.
The exact same thing applies in software development. When your developer ‘pulls a dependency’ they basically know how it works, what it is supposed to do, what should and shouldn’t happen when it is used, and how to work with it. But if you needed them to rebuild a dependency, that could be the equivalent request of reformulating a concrete mixture for a bricklayer or house framer. With enough time they could figure it out, but it’s probably a better idea to just buy a different concrete mixture that meets your needs. On the flip side, don’t use the wrong concrete for your house or you’re going to have to tear it all down and start over.
