Show HN: OpsFlow – Low-code DevOps – Webflow for infrastructure(opsflow.app)
opsflow.app
Show HN: OpsFlow – Low-code DevOps – Webflow for infrastructure
https://opsflow.app/
38 comments
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.
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 (AWS Elastic Beanstalk, Google App Engine, Azure App Service).
If you really need this, seems like you'd be better served by the low code solutions on the cloud providers (AWS Elastic Beanstalk, Google App Engine, Azure App Service).
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.
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.
In my opinion, analysis is wrong. I used think this way, but after spending a year in self hosted PaaS product, it was very clear that people didnt want a product like this. When you pitch to a customer they love the idea but when real implementation start shaping up, you start building leaky abstraction on top of the cloud providers. The customers have to build infrastructure your way or it is high way. Terraform is already an abstraction, terraform modules starts breaking the onus is on your. Cloud providers api breaks onus is on you. Building abstraction on abstraction starts becoming leaky. So, self hosted paas like this has a smaller TAM than what you think it is.
Where is model really works is what companies like Railway and render has done. You also own the compute and storage and retail that to end users. Your potential end users would rather prefer easily to use cloud provider than going to AWS and setting up PaaS on top of that. Your potential customer has got the time and effort for that.
Where is model really works is what companies like Railway and render has done. You also own the compute and storage and retail that to end users. Your potential end users would rather prefer easily to use cloud provider than going to AWS and setting up PaaS on top of that. Your potential customer has got the time and effort for that.
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.
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.
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.
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.
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.
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.
Why it seems like just about everybody tries to remove actual programming from my interaction with AWS?
Cloudformation with it's horrible piles of YAML (that you end up templating anyway), serverless framework with slighty less horrible YAML again with hundreds of tricks in it just to make it flexible enough for larger projects and multiple environments.
Absolutely horrible HCL in terraform which again tries to reinvent the wheel with it's broken implementation of conditionals and iterations.
And now this. As if creating a simple pipelines and basic AWS setups was what everybody is struggling with. Today even some founders and CEOs can handle that!
Thanks, people! I will be better off writing everything in actual programming language, with proper apis, network communication tooling, proper abstractions, libraries, iterations, conditions and all the good stuff. No need to take it away from me and replace with YAML or, even worse, web interfaces!
Cloudformation with it's horrible piles of YAML (that you end up templating anyway), serverless framework with slighty less horrible YAML again with hundreds of tricks in it just to make it flexible enough for larger projects and multiple environments.
Absolutely horrible HCL in terraform which again tries to reinvent the wheel with it's broken implementation of conditionals and iterations.
And now this. As if creating a simple pipelines and basic AWS setups was what everybody is struggling with. Today even some founders and CEOs can handle that!
Thanks, people! I will be better off writing everything in actual programming language, with proper apis, network communication tooling, proper abstractions, libraries, iterations, conditions and all the good stuff. No need to take it away from me and replace with YAML or, even worse, web interfaces!
Hey, what you do is very cool! At dstack.ai, we are building an MLOps platform that in some way similar to your approach except we still love and leverage the concept of infrastructure as code!
I’d love to chat to discuss the technology under the hood and other things if you are open. You can reach me at andrey at dstack.ai.
Cool that you revamped a bit, I've tested digger.dev once with you!
Looks good. I'd like to see some more full examples
E.g. seeing the visual editor and the outcome of the terraform code then.
I also would be interested how easy it is to customize the terraform code then without it getting overriden by your system then.
Looks good. I'd like to see some more full examples
E.g. seeing the visual editor and the outcome of the terraform code then.
I also would be interested how easy it is to customize the terraform code then without it getting overriden by your system then.
Congrats on your launch.
I'll have to check it out this weekend.
But as UI / UX goes - and in a similar-ish space- Buddy.works is so smooth I think sometimes smile to myself while I'm using it. BW is a great example for all of us.
Not knocking your product; just trying to help.
Good luck!!
I'll have to check it out this weekend.
But as UI / UX goes - and in a similar-ish space- Buddy.works is so smooth I think sometimes smile to myself while I'm using it. BW is a great example for all of us.
Not knocking your product; just trying to help.
Good luck!!
thanks!!
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 quite useful.
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 quite useful.
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.
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.
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.
thanks so much for this.
I'm curious about this - are u saying early stage devops teams want to build everything themselves ? I mean what im asking is a very "Gruntworks" kind of approach.
Did u not find that to be the case with Atomized ?
I'm curious about this - are u saying early stage devops teams want to build everything themselves ? I mean what im asking is a very "Gruntworks" kind of approach.
Did u not find that to be the case with Atomized ?
DevOps is already low-code. You can't program people... at least in this sense. Maybe you mean something else like Low-code IaC? Low-Code cloud?
Looks pretty cool and I like the UI. Congrats on another launch! How does this differ from Digger? What's the long term vision for this?
Cofounder, everytime I build on AWS I feel a disconnect between abstraction levels. Would love to hear about your feedback from OpsFlow
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?
Just my opinion, but I would be shocked to find out that people were trying to provision anything in their AWS accounts from their phone.
It'd be shocking because of how bad the console UX is, but I bet there are many people who would like to do that. It's not always enterprise-grade services I'm working on, sometimes I just want to hack on something with my BT keyboard during a train ride.
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
Easier would be default to DnD, do clicks only on mobile viewports
Just being that guy: isn’t “low-code devops” just “good old ops”?
It redirected me to something called "Digger" at Digger.dev. Are you the same company?
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?
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 :)
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 :)
Are you planning to support other cloud platforms as well?
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.
[deleted]
What HN crowd helped us realise is that the UI was still not simple enough. Rather confusing in fact.
So in the last couple weeks we have radically simplified it based on your feedback. We have removed the unnecessarily complex concepts like Services and Environments - it's just Apps now. All options are now on the new Settings screen. Instead of Infrastructure and Software deployments there is now a sequence of steps.
Check it out - and tell us what you think!
Here's our launch on ProductHunt: https://www.producthunt.com/posts/opsflow