Live data from Hacker News

Show HN: OpsFlow – Low-code DevOps – Webflow for infrastructure

opsflow.app

21–30 of 39 posts

Re: Show HN: OpsFlow – Low-code DevOps – Webflow for infrastructure

#21

I feel like if you need this, you're not using the right platform. I don't see how someone gets the benefits of IaC with this, seems like it just improves the console experience and auto generates crap IaC. Why even use IaC at this point, aside from your tool probably needing it on the backend to deploy things? If you really need this, seems like you'd be better served by the low code solutions on the cloud providers…

That's a very good point. And it is also the very reason we wanted to build smth like this. The question we asked ourselves: why are people leaving PaaS platforms like Heroku?

The answer seems to be that people are starting with simple tools (beanstalk, heroku, GAE etc) but then quickly approaching their limits in terms of both features and cost - and move to "native" AWS / GCP / Azure. At this point they need to rebuild the infra from scratch, write all the IaC, etc. This is painful, slow and expensive. So it's either simplicity or extensibility, pick one.

We thought that someone must find a better way, it could just as well be us. The idea is to generate IaC in the background on top of a "real" cloud provider like AWS, making it seem to the user just as if they were using a PaaS. Until they want more - and at this point instead of moving to a different platform they can just extend TF however they like. No big one-off DevOps effort needed. Chances are that it can be done by the same person who built the backend, even if they never worked with AWS or Terraform before. Much smoother learning curve.

Also, many tech scaleups end up building "in-house herokus", often backed by Terraform. This was one of the motivations of us as founders, they had to do this more than once.

Re: Show HN: OpsFlow – Low-code DevOps – Webflow for infrastructure

#22
I really like your demo.

A question that always comes up when I see these "Heroku-like" replacements on top of AWS/GCP/Azure is who is the target user?

A couple years ago, you would have platform teams helping developers launch their stuff. Since then, AWS has tried to make things easier through services like App Runner. Nowadays, if you don't want to manage the instances yourself, you just use a managed service. Platform teams are essentially dead.

It's not 2016 anymore and developers should know how their code runs. Trying to "protect" them from infrastructure only hinders their pace long term.

Re: Show HN: OpsFlow – Low-code DevOps – Webflow for infrastructure

#24

this is pretty interesting. Quick question - let's take a popular piece of software (Apache Airflow). Let's say i want to set it up on AWS EKS with all the best practices + spot instances cost reduction ... how would i do it with OpsFlow ? The problem with devops is that i dont know the "right way". I dont know whether i should use private VPC or a public VPC, etc etc. So a library of readymade "templates" would be q…

We attempted to do something similar with my last company (Atomized YC S20). We had a vision of creating an "app store" approach to infrastructure. The hardest problem we ran into wasn't build out the engine that did all the work but actually creating the templates and ensuring that everything was built with best practices in mind. Another issue we ran into was all the options that were available such as instance size. We ended up failing as a company because we couldn't find that balance between giving too much (and essentially re-creating the AWS Console UI) and giving too little with a "one-click" approach.

I still believe there is a market for this - but I'm not sure how big of a market it is to be honest. There is definitely a need for a product like this to exist though.

Re: Show HN: OpsFlow – Low-code DevOps – Webflow for infrastructure

#25

I was interested in it, but there's no full examples of what it actually produced on the site. No videos, no code. On the Product Hunt site, the video stops right as you're about to push the button. There's no way I'm going to connect this to my AWS account just to find out what it can do without knowing what it's going to do.

Thanks so much for sharing the feedback!! This is super helpful, and we will work to address this.

Re: Show HN: OpsFlow – Low-code DevOps – Webflow for infrastructure

#26
post #12
post #4

Under "Try it right here," my first instinct was to drag-and-drop the components from the left onto the right pane.

that was the intention actually but then we thought many people would use it on mobile and settled on clicks. would you prefer dnd interaction?

What about current click behavior, but also if you hold for a little bit it let's you drag? Would need accompanying animations to make it intuitive.

Easier would be default to DnD, do clicks only on mobile viewports

Re: Show HN: OpsFlow – Low-code DevOps – Webflow for infrastructure

#27

I really like your demo. A question that always comes up when I see these "Heroku-like" replacements on top of AWS/GCP/Azure is who is the target user? A couple years ago, you would have platform teams helping developers launch their stuff. Since then, AWS has tried to make things easier through services like App Runner. Nowadays, if you don't want to manage the instances yourself, you just use a managed service. Pla…

Thank you!! And fair point. To us it's in a sense a bet on a particular direction the industry is going to take. If we're right then infrastructure-as-code isn't going away, someone needs to write it, even for the managed services. Those still need to be connected with each other, there are VPCs, security groups, secrets - the "glue" connecting those services. We don't believe developers should care about that though. Specialisation tends to increase, not decrease with time. It's hard enough to make one's frontend or backend work in isolation. So our thinking is that the devops corner of the industry is very much a transitory state - post-problem but pre-product, somewhat like hardware was before the PC, or software development before operating systems. There are strong incentives to cleanly decouple devops from development by means of products - just like operating system engineering is decoupled from software engineering via layers upon layers of apis and tools that don't require any specialist intervention.

So we are trying to make progress in that direction - if managed cloud services were hardware, then we are building an operating system for developers to use that hardware with as little friction as possible.

Re: Show HN: OpsFlow – Low-code DevOps – Webflow for infrastructure

#28
post #24

this is pretty interesting. Quick question - let's take a popular piece of software (Apache Airflow). Let's say i want to set it up on AWS EKS with all the best practices + spot instances cost reduction ... how would i do it with OpsFlow ? The problem with devops is that i dont know the "right way". I dont know whether i should use private VPC or a public VPC, etc etc. So a library of readymade "templates" would be q…

We attempted to do something similar with my last company (Atomized YC S20). We had a vision of creating an "app store" approach to infrastructure. The hardest problem we ran into wasn't build out the engine that did all the work but actually creating the templates and ensuring that everything was built with best practices in mind. Another issue we ran into was all the options that were available such as instance siz…

thanks so much for sharing this Nick! It takes a great deal of courage to share this sort of thing publicly, and I do greatly appreciate it. It is also extremely helpful as we are facing very similar challenges.

Re: Show HN: OpsFlow – Low-code DevOps – Webflow for infrastructure

#30
post #13
post #9

Earlier quoted context omitted.

Same team behind it. But it's a completely new UI, much simplified and streamlined. From previous launches we learned that the UI was quite confusing, and rebuilt it from scratch. The old one can be found at app.digger.dev; this is dashboard.digger.dev

I don't understand why there's two apps, name and domains (doing the same thing?), one redirecting to the other. Is your startup named OpsFlow (previously digger.dev)? Or is OpsFlow a new product home digger?

We've started Digger 1.5 years ago, and launched it last summer. It was well received but didn't exactly take off as we hoped. Clearly needed more work. We have also realised that as a startup of 2 at the time we were trying to do way too many problems at once, it is simply impossible to build a full-featured platform with a tiny team.

We then launched a number of more focused products, all powered by the same Digger engine. 2 did better than the other 5 or so. Lemon was an alternative UI for AWS; Alicorn was a multi-cloud offering for containers. Those launches helped us realise that some of the core architectural assumptions we had were wrong. We also needed to rework the UX because people were getting confused by the split between Services and Environments, as well as separation of Infrastructure and Software deployments.

So we got back to the drawing board. We have radically simplified the UX, removed the confusing parts, introduced keyless AWS connection with narrowed down permission scope and many other things. The question remained - which is the use case people care about most? To answer it we started launching smaller products again, all powered by Digger engine with tweaked configurations.

Many people liked AWS Bootstrap. It allows you to quickly configure your AWS account to run frontend, backend and a database of your choice. Quite literally bootstrap.

Another thing that was well received was Terragen. We made it all about auto-generation of terraform. As soon as the user connects their AWS account they can export generated Terraform into their GitHub.

With OpsFlow we took the learnings from AWS Bootstrap and Terragen and made the UI even simpler. It no longer bothers the user with optional stuff, it is all moved to the new Settings page. And it's centered around 2 simple types of building blocks - Apps and Resources.

OpsFlow is the closest we got so far to making something people want. Still a long way to go though :)

Post reply on HN