Show HN: OpsFlow – Low-code DevOps – Webflow for infrastructure (opsflow.app)

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?

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

thanks!!! that's what we thought as well :) OpsFlow automatically generates IAM roles, security groups and stuff like that. And Terraform - which you can fully customize

thanks!!

Fixed ~2h ago. The homepage is pointing to OpsFlow UI again.

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.

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.

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

Yes - "on the roadmap". Unlikely in the short term though. We are a small team of 6 at the moment, trying to stay focused. AWS alone has enough quirks to keep us busy. We plan to expand into other cloud providers (GCP and Azure) when we get the AWS use cases right and start working with somewhat larger teams as customers. Currently we are focused on simplifying AWS for early-stage startups.

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.

when you say platform teams are dead, do you just mean the part of the team that mangages platform infrastructure?

My understanding with Platform teams is that its more than DevOps, its that a core set of engineers building a platform that the rest of engineering can safely (using that word in a relative sense here) build upon, e.g., I may as part of a platform team create core API services that are then exposed to product side teams to develop against, and we work with each other. This is essentially a productivity feature, because it allows for specialists to collaborate over their expertise, as opposed to having lots of full stack generalists managing their own slices of codebases, which results in shipping faster and higher quality product.

This only works if everyone does "you build it you run it".

It also impacts team sizing and the minimum number of people required to continuously support every project so it can be kept alive.

If you have a centralised ops / support function then they need things to be standardised so that they can support them.