I feel the same way about advertised prices like $99.95 or for gas, even $1.99 9/10.
But it persists because it works. I suspect call for pricing works as well. Especially for enterprise, and they are who you are usually targeting with that kind of prices.
I guess for people who aren't sure yet if they need/want what you offer, prizing (at least in a magnitude) is part of the decision whether they should invest more time researching.
So either:
- put a ballpark prize on it (even something vague like "from X$ to Y$ depending on application, talk to sales" would work
- if that isn't what you want, you need to make extra sure that people want your product so hard they are willing to jump through your hoops. For that to be true they have to be sure the thing you offer solves problems worth solving in a way they want it to be solved.
I recently gave a tech talk internally about Terraform. I wanted to show how quickly a web service can get complicated by showing the SVG generated from `terraform graph` output.
It failed miserably:
$ tf graph|dot -Tpng > graph.png
dot: graph is too large for cairo-renderer bitmaps. Scaling by 0.420618 to fit
Trying to upload the genrated image to Google Slides and the error message: The image is too large. Images must be smaller than 25 megapixels.
$ tf state list|cut -d. -f3|grep ^google_|sort|uniq|wc -l
42 <-- different types of Google Cloud resources we use in our Terraform configs.
I'm very skeptical this config can be managed using a WYSIWYG tool.
Wonder if it'd be more achievable if the product natively understood TF modules? So you tend not to describe or view direct AWS resources, but slightly higher level concepts your eng team uses - then you only see the actual resources if you "zoom in" to a lower level scope
The best way to verify that is to test it on Brainboard, I'm excited to know the results. We can do it together if you want, lemme know if you are interested.
All for trying to reduce env drift and divergence between things, but don’t think the documentation as the source of truth is the winning formula. Source of truth will inevitably be code (bc it has to capture the full weight of the complexity of your system), IaC is hard enough already with the dizzy height of the abstractions you are building on top of, having a system that adds another doesn’t seem like a winning formula to me.
All for better visualizations of terraform resources tho
We are challenging the fact that source of truth will inevitably be code, we wanna move it a bit higher. When you analyze history of computer science you see that it is all about abstractions: OS as an abstraction to the HW, VM as abstraction to the limitation of both OS & HW, dockers does the same, kubernetes...and the cloud providers themselves are an abstraction of the underlaying technologies by offering: compute as a service, storage as a service, network as a service...
This looks interesting. But as a developer I really would like my pull requests, linters and what not.
This feels like the G-Programming language from LabView which allows you to graphically program your physics experiments. But once you drink the programming language coolaid you don’t want to do graphics programming any more.
So I guess I am already biased towards reading text. But for me this is still the best way to consume information compared to pictures or videos
Interesting points. FYI: pull requests will be available during Q1/2021 and we have a kind of linter (predictable blocks, maps, lists). Another point is once you work on graphics I guess you care less about the code since you'll be fully managing graphics in the same analogy to assembly, you care about your language code and not about the assembly generated behind the scenes.
> I guess you care less about the code since you'll be fully managing graphics ...
Is this a thing you have experienced for yourself and others around you?
My experience does not hold this statement as it is much harder for me to parse a complex image.
Yes, I'm still experiencing that while using Brainboard. I realize that I care more about the graphics and the design and less about the code even if I spent more 12 years dealing with the code.
Indeed, managing complexity is one of the most difficult part of making a graphical tools useful, and some architectures cannot inherently be represented only by a simple 2d graphic.
On the flip side, IAC can sometime be complicated to reason about without deep-diving in the source code and having deep knowledge about Terraform and every cloud provider.
We believe that there is a middle ground, where Brainboard helps engineers design and communicate about their architecture efficiently, are able to manually edit the generated Terraform files, while avoiding the churn of constantly redrawing their documentation graphics.
The best answer is really to try it out. Let's do it and see if it works or not. By the way we are implementing complex architectures (that will be available in the marketplace) and it just works as expected.
The idea is fantastic but I am very skeptical how this would handle state drift and larger projects.
Anyways, being able to visualize infrastructure this way is pretty great. Currently, the way it usually works is to draw the infra and then manually write the tf resources. This seems like it would simplify the process greatly since one could genereate the IAC directly from the diagrams. Pretty neat (if it works well).
Very nice question about the state drift, we are working on it in a way to have a live sync with the existing infra and either suggest a remediation or generate an alarm.
We are working hard to make it work well and at the current stage (full support for GCP, Azure & AWS) we are having an amazing results.
The pull request is within our short term roadmap.
To handle change control Brainboard has its own versionning system based on git accessible from the design area. It versions graphically your architectures.
OK. Specific Sentinel integration might be optional (or not even possible), not too sure. But the only way we'd be compliant with the Sentinel policies is if I can use the pre-designed modules in TFE.
Terraform modules are within our roadmap, for now we have the market-place where you can design template architectures that contain your own rules and policies that you can distribute within your organization or team(s), you can make them public if you want as well.
Cloudcraft is only for AWS and doesn't have all Terraform resources available, and the generation of the Terraform code is not complete.
Brainboard supports all cloud resources for AWS, Azure and GCP (Digital Ocean and Alibaba planned next) and fully supports any field available in Terraform (even map of maps).
It supports Terraform variables and have a git based versioning + a market place to design and distribute your blueprints to your team, organization or public.
