TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Show HN: Effortless on-demand preview environments in your cloud

1 点作者 hemezh超过 2 年前
Hi HN, we&#x27;ve been working on Cohesive for the last few months. Our goal is to simplify DevOps tooling for early stage startups so that they can focus on what matters the most - building great products for their customers.<p>As engineering teams grow in size and complexity, getting access to a stable environment to test your code and collaborate with team members becomes more and more difficult. In many early stage organisations, the focus is on growth and the lack of tooling makes it hard to spin up new environments on-demand. This causes many frustrations:<p>1. Some teams end up creating a queuing mechanism where environments are locked by an engineer&#x2F;QA or team trying to get their feature out. This is error prone and requires high collaboration to work, if at all.<p>2. The DevOps team has to manually spin up these environments. This adds to their already quite full plates and slows down releases.<p>3. We&#x27;ve seen most teams create an in-house solutions for this. This requires high investment and needs continued maintenance. It&#x27;s also typically quite expensive and takes effort to be cost effective.<p>We believe, in 2022, this should be a solved problem and hence we decided to build it. Here&#x27;s are some features:<p>1. Test every PR in its own environment.<p>2. All the infra runs in your cloud. This means you get all the benefits without compromising on capabilities.<p>3. Once the config(how to run your application and the resources it needs) is set up, everyone else can just reuse it to launch environments. This simplifies onboarding for new hires massively.<p>4. There are cases when the service you&#x27;re working is dependent on a few other services. We provide a solution for this out of the box where you can launch a group of services with one click or on PR. We call it Stacks.<p>5. Environments can be made private which can only be accessed when connected to the private network for your org. This is easy to do with the CLI.<p>6. Save costs by hibernating environments when not in use.<p>7. Written in Go and runs on K8s(EKS for now). We currently support AWS with plans to support other platforms soon.<p>Join our Slack community here: <a href="https:&#x2F;&#x2F;join.slack.com&#x2F;t&#x2F;cohesive-community&#x2F;shared_invite&#x2F;zt-1d0smvq8w-PSlnLO67xupljEJv28kDbQ" rel="nofollow">https:&#x2F;&#x2F;join.slack.com&#x2F;t&#x2F;cohesive-community&#x2F;shared_invite&#x2F;zt...</a><p>Let me know what you think also would be happy to answer any questions.

1 comment

QuinnyPig超过 2 年前
On paper? Awesome!<p>In practice? The rubber-meets-the-road challenges are not insignificant. Everything that aspires to set up environments like this seems to find itself dashed upon the rocks of &quot;oh, that particular third party API is the same in prod as it is in pre-prod,&quot; &quot;stateful datasets that need to be independent of other environments but also purged of sensitive content,&quot; and a bunch of unknown unknowns that exist in a given production environment despite everyone&#x27;s best efforts.<p>I&#x27;ve got an AWS application that I&#x27;d love to to build preprod environments for (not in Kubernetes) and despite controlling all of the dependencies myself, I still have an eternal backlog item hanging over my head to go through and abstract all the environment-specific stuff out. In other words, &quot;the heavy lifting isn&#x27;t in the part that I understand your service to do.&quot; :-&#x2F;<p>Man, do I wish it were otherwise.