4 ms·

I have seen this problem very closely across multiple firms and environments. Just a few points that I would request you to dig further. 1. Quick immutable en

I have seen this problem very closely across multiple firms and environments. Just a few points that I would request you to dig further. 1. Quick immutable envs aren't so much of a problem for B2C apps. Particularly for B2B apps, it's not just the "run-build--pull-image--deploy--start-svc--share-url" that's the real hard part. The real hard part for B2B apps is the test data - the sane dataset which needs to be replicated as well, per environment. Nobody wants to use a test/staging DB where changes are uncontrolled. Bottomline - Immutability isn't just at the app layer, has to cover the test data and stateful parts (datastores) too. 2. What's the real value of it? One possible way to figure out hassle-to-value ratio, is the ratio of number-of-commits to number-of-builds, and the ratio of number-of-builds to any number-signifying-quality. If more builds (=> more number of envs cropping up, and brought down, that is a high rate of env churn) do not mean increased quality, then anyone choosing such a solution is really just doing it for the sake of feeling self-important or sounding smart. One really has to be keenly tuned for the real business value, while validating fitment of such tools for the org/business. Happy to discuss more. I have been designing/building tools like this, as a day job for quite some time.

gervwyk 6y ago
I can resonate with point one. Having built a few internal apps, its always tricky to have representative data for you staging env. It even becomes exponentially more difficult when dealing with multiple data sources and APIs.. some mock sandbox mode for this would be a superpower.
podoman 6y ago
Hi! Very interesting points: addressed them below. 1. For the most part, with Reploy, users either a) Use a staging db b) Seed their environments with fixtures or test data. c) Do a db dump of a common db Each of them have their own tradeoffs, which, from your knowledge of the space, are probably not worth describing in depth. The most ideal situation given your description is probably (c) because you can control what data is being seeded into each environment and introduce test data that everyone's staging env can then use. 2. I agree, but the problem here is that "any number signifying quality" isn't very easy to metricize. From our current users, Reploy is generally a no brainer. i.e. they go through the flow of having to spin up so many staging envs (or are annoyed by the lack thereof) that they use our product. In the near future, however, from a marketing/sales perspective we do want to do work to figure out who exactly is feeling the pain the most, as this is who we want to target. What's your background building these types of tools, if you don't mind me asking? Definitely down to discuss more!
- raghava 6y ago
  > 1. (c) Yup, that's the most sensible option but the fitment really depends on the context. > 2. IMHO, more thought is definitely needed, in case you want to avoid expert beginners subscribing and cancelling it after a couple of months/quarters > What's your background building these types of tools, if you don't mind me asking? Definitely down to discuss more! Have been designing and building dev/rel/ops/maint/mon/ALM tools for the last 13 years, in large firms, SMEs and startups

gervwyk 6y ago

I can resonate with point one. Having built a few internal apps, its always tricky to have representative data for you staging env. It even becomes exponentially more difficult when dealing with multiple data sources and APIs.. some mock sandbox mode for this would be a superpower.

podoman 6y ago

Hi! Very interesting points: addressed them below. 1. For the most part, with Reploy, users either a) Use a staging db b) Seed their environments with fixtures or test data. c) Do a db dump of a common db Each of them have their own tradeoffs, which, from your knowledge of the space, are probably not worth describing in depth. The most ideal situation given your description is probably (c) because you can control what data is being seeded into each environment and introduce test data that everyone's staging env can then use. 2. I agree, but the problem here is that "any number signifying quality" isn't very easy to metricize. From our current users, Reploy is generally a no brainer. i.e. they go through the flow of having to spin up so many staging envs (or are annoyed by the lack thereof) that they use our product. In the near future, however, from a marketing/sales perspective we do want to do work to figure out who exactly is feeling the pain the most, as this is who we want to target. What's your background building these types of tools, if you don't mind me asking? Definitely down to discuss more!

raghava 6y ago
> 1. (c) Yup, that's the most sensible option but the fitment really depends on the context. > 2. IMHO, more thought is definitely needed, in case you want to avoid expert beginners subscribing and cancelling it after a couple of months/quarters > What's your background building these types of tools, if you don't mind me asking? Definitely down to discuss more! Have been designing and building dev/rel/ops/maint/mon/ALM tools for the last 13 years, in large firms, SMEs and startups