[HN Gopher] Show HN: OpsFlow - Low-code DevOps - Webflow for inf...
___________________________________________________________________
Show HN: OpsFlow - Low-code DevOps - Webflow for infrastructure
Opsflow cofounder here! We launched a bunch of things recently,
some of them well received (Terragen, AWS Bootstrap). It's no
secret that AWS is hard, and our mission is to make it simple.
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
Author : igorzij
Score : 59 points
Date : 2022-06-24 09:51 UTC (13 hours ago)
(HTM) web link (opsflow.app)
(TXT) w3m dump (opsflow.app)
| talhof8 wrote:
| Waited a long time for something like this. Tired of wasting time
| on IAM roles.
|
| Congrats on your launch!
| igorzij wrote:
| 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
| ArtemZ wrote:
| 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!
| motatoes wrote:
| Cofounder, everytime I build on AWS I feel a disconnect between
| abstraction levels. Would love to hear about your feedback from
| OpsFlow
| chiefalchemist wrote:
| 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!!
| igorzij wrote:
| thanks!!
| sandGorgon wrote:
| 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.
| nkotov wrote:
| 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.
| igorzij wrote:
| 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.
| lagrange77 wrote:
| Are you planning to support other cloud platforms as well?
| igorzij wrote:
| 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.
| shepardrtc wrote:
| 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.
| igorzij wrote:
| Thanks so much for sharing the feedback!! This is super
| helpful, and we will work to address this.
| razzypitaz wrote:
| 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?
| CedarMills wrote:
| 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.
| igorzij wrote:
| 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.
| xyzzy123 wrote:
| 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.
| no_wizard wrote:
| 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.
| igorzij wrote:
| Hey HN crowd, founder here. The fact that we hit the frontpage
| somehow broke the new app signup flow. While we are fixing it, we
| are temporarily redirecting to app.digger.dev (the old UI). Will
| keep you posted here!
| igorzij wrote:
| Fixed ~2h ago. The homepage is pointing to OpsFlow UI again.
| pgt wrote:
| Under "Try it right here," my first instinct was to drag-and-drop
| the components from the left onto the right pane.
| igorzij wrote:
| 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?
| abatilo wrote:
| 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.
| EUROCARE wrote:
| 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.
| Jarwain wrote:
| 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
| pgt wrote:
| It redirected me to something called "Digger" at Digger.dev. Are
| you the same company?
| igorzij wrote:
| 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
| QuiiBz wrote:
| 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?
| igorzij wrote:
| 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 :)
| nkotov wrote:
| 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?
| candiddevmike wrote:
| 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).
| igorzij wrote:
| 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.
| debarshri wrote:
| 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.
| [deleted]
___________________________________________________________________
(page generated 2022-06-24 23:03 UTC)