The best Hacker News stories from Show from the past day
Latest posts:
Launch HN: Wasp (YC W21) – DSL for building full-stack web apps
Hi HN!<p>We are Martin and Matija, twin brothers and creators of Wasp (<a href="https://wasp-lang.dev" rel="nofollow">https://wasp-lang.dev</a>). Wasp is a declarative language that makes it really easy to build full-stack web apps while still using the latest technologies such as React, Node.js and Prisma.<p>Martin and I both studied computer science where we mostly focused on algorithms for bioinformatics. Afterwards we led engineering teams in several SaaS companies, on the way gaining plenty of experience in building web apps.<p>Moving from one project to another, we used various technologies:
JQuery -> Backbone -> Angular -> React, own scripts / makefile -> Grunt -> Gulp -> Webpack, PHP -> Java -> Node.js, … , and we always felt that things are harder than they should be. We were spending a lot of time adopting the latest tech stack and figuring out the best practices: how to make the web app performant, scalable, economical and secure and also how to connect all the pieces of the stack together.<p>While the tech stack kept advancing rapidly, the core requirements of the apps we were building changed very little (auth, routing, data model CRUD, ACL, …). That is why about 1.5 years ago we started thinking about separating web app specification (what it should do) from its implementation (how it should do it).<p>This led us to the idea of extracting common web app features and concepts into a special specification language from which we could generate code in the currently popular technologies. We don’t think it is feasible to replace everything with a single language so that is why we went with a DSL which integrates with the modern stack (right now React, NodeJS, Prisma).<p>Wasp lets you define high-level aspects of your web app (auth, routing, ACL, data models, CRUD) via a simple specification language and then write your specific logic in React and Node.js. The majority of the code is still being written in React and Node.js, with Wasp serving as the backbone of your whole application. To see some examples of what the language looks like in practice, take a look here: <a href="https://github.com/wasp-lang/wasp/blob/master/examples/tutorials/TodoApp/main.wasp" rel="nofollow">https://github.com/wasp-lang/wasp/blob/master/examples/tutor...</a><p>The main difference between Wasp and frameworks (e.g. Meteor, Blitz, Redwood) is that Wasp is a language, not a library. One benefit of that is a simpler and cleaner, declarative syntax, focused on the requirements and detached from the implementation details.<p>Another benefit of a DSL is that it allows Wasp to understand the web app’s requirements during the build time and reason about it before generating the final code. For example, when generating code to be deployed to production, it could pick the most appropriate architecture based on its understanding of the web app and deploy it to serverless or another type of architecture (or even a combination). Another example would be reusing your data model logic through all the parts of the stack while defining it just once in Wasp. DSL opens the potential for optimisations, static analysis and extensibility.<p>Wasp’s compiler is built in Haskell and it compiles the source code in Wasp + React/Node.js into the target code in just React and Node.js (currently in Javascript, but we plan to move to Typescript soon). The generated code is human readable and can easily be inspected and even ejected if Wasp becomes too limiting.<p>We are currently in Alpha and many features are still rough or missing, but you can try it out and build and deploy web apps! There are things we haven’t solved yet and others that will probably change as we progress.<p>You can check out our repo at <a href="https://github.com/wasp-lang/wasp" rel="nofollow">https://github.com/wasp-lang/wasp</a> and give it a try at <a href="https://wasp-lang.dev/docs/" rel="nofollow">https://wasp-lang.dev/docs/</a>.<p>Thank you for reading! We would love to get your feedback and also hear about your experiences building web apps - what has worked for you and where do you see the opportunities for improvement?
Launch HN: Wasp (YC W21) – DSL for building full-stack web apps
Hi HN!<p>We are Martin and Matija, twin brothers and creators of Wasp (<a href="https://wasp-lang.dev" rel="nofollow">https://wasp-lang.dev</a>). Wasp is a declarative language that makes it really easy to build full-stack web apps while still using the latest technologies such as React, Node.js and Prisma.<p>Martin and I both studied computer science where we mostly focused on algorithms for bioinformatics. Afterwards we led engineering teams in several SaaS companies, on the way gaining plenty of experience in building web apps.<p>Moving from one project to another, we used various technologies:
JQuery -> Backbone -> Angular -> React, own scripts / makefile -> Grunt -> Gulp -> Webpack, PHP -> Java -> Node.js, … , and we always felt that things are harder than they should be. We were spending a lot of time adopting the latest tech stack and figuring out the best practices: how to make the web app performant, scalable, economical and secure and also how to connect all the pieces of the stack together.<p>While the tech stack kept advancing rapidly, the core requirements of the apps we were building changed very little (auth, routing, data model CRUD, ACL, …). That is why about 1.5 years ago we started thinking about separating web app specification (what it should do) from its implementation (how it should do it).<p>This led us to the idea of extracting common web app features and concepts into a special specification language from which we could generate code in the currently popular technologies. We don’t think it is feasible to replace everything with a single language so that is why we went with a DSL which integrates with the modern stack (right now React, NodeJS, Prisma).<p>Wasp lets you define high-level aspects of your web app (auth, routing, ACL, data models, CRUD) via a simple specification language and then write your specific logic in React and Node.js. The majority of the code is still being written in React and Node.js, with Wasp serving as the backbone of your whole application. To see some examples of what the language looks like in practice, take a look here: <a href="https://github.com/wasp-lang/wasp/blob/master/examples/tutorials/TodoApp/main.wasp" rel="nofollow">https://github.com/wasp-lang/wasp/blob/master/examples/tutor...</a><p>The main difference between Wasp and frameworks (e.g. Meteor, Blitz, Redwood) is that Wasp is a language, not a library. One benefit of that is a simpler and cleaner, declarative syntax, focused on the requirements and detached from the implementation details.<p>Another benefit of a DSL is that it allows Wasp to understand the web app’s requirements during the build time and reason about it before generating the final code. For example, when generating code to be deployed to production, it could pick the most appropriate architecture based on its understanding of the web app and deploy it to serverless or another type of architecture (or even a combination). Another example would be reusing your data model logic through all the parts of the stack while defining it just once in Wasp. DSL opens the potential for optimisations, static analysis and extensibility.<p>Wasp’s compiler is built in Haskell and it compiles the source code in Wasp + React/Node.js into the target code in just React and Node.js (currently in Javascript, but we plan to move to Typescript soon). The generated code is human readable and can easily be inspected and even ejected if Wasp becomes too limiting.<p>We are currently in Alpha and many features are still rough or missing, but you can try it out and build and deploy web apps! There are things we haven’t solved yet and others that will probably change as we progress.<p>You can check out our repo at <a href="https://github.com/wasp-lang/wasp" rel="nofollow">https://github.com/wasp-lang/wasp</a> and give it a try at <a href="https://wasp-lang.dev/docs/" rel="nofollow">https://wasp-lang.dev/docs/</a>.<p>Thank you for reading! We would love to get your feedback and also hear about your experiences building web apps - what has worked for you and where do you see the opportunities for improvement?
Launch HN: Wasp (YC W21) – DSL for building full-stack web apps
Hi HN!<p>We are Martin and Matija, twin brothers and creators of Wasp (<a href="https://wasp-lang.dev" rel="nofollow">https://wasp-lang.dev</a>). Wasp is a declarative language that makes it really easy to build full-stack web apps while still using the latest technologies such as React, Node.js and Prisma.<p>Martin and I both studied computer science where we mostly focused on algorithms for bioinformatics. Afterwards we led engineering teams in several SaaS companies, on the way gaining plenty of experience in building web apps.<p>Moving from one project to another, we used various technologies:
JQuery -> Backbone -> Angular -> React, own scripts / makefile -> Grunt -> Gulp -> Webpack, PHP -> Java -> Node.js, … , and we always felt that things are harder than they should be. We were spending a lot of time adopting the latest tech stack and figuring out the best practices: how to make the web app performant, scalable, economical and secure and also how to connect all the pieces of the stack together.<p>While the tech stack kept advancing rapidly, the core requirements of the apps we were building changed very little (auth, routing, data model CRUD, ACL, …). That is why about 1.5 years ago we started thinking about separating web app specification (what it should do) from its implementation (how it should do it).<p>This led us to the idea of extracting common web app features and concepts into a special specification language from which we could generate code in the currently popular technologies. We don’t think it is feasible to replace everything with a single language so that is why we went with a DSL which integrates with the modern stack (right now React, NodeJS, Prisma).<p>Wasp lets you define high-level aspects of your web app (auth, routing, ACL, data models, CRUD) via a simple specification language and then write your specific logic in React and Node.js. The majority of the code is still being written in React and Node.js, with Wasp serving as the backbone of your whole application. To see some examples of what the language looks like in practice, take a look here: <a href="https://github.com/wasp-lang/wasp/blob/master/examples/tutorials/TodoApp/main.wasp" rel="nofollow">https://github.com/wasp-lang/wasp/blob/master/examples/tutor...</a><p>The main difference between Wasp and frameworks (e.g. Meteor, Blitz, Redwood) is that Wasp is a language, not a library. One benefit of that is a simpler and cleaner, declarative syntax, focused on the requirements and detached from the implementation details.<p>Another benefit of a DSL is that it allows Wasp to understand the web app’s requirements during the build time and reason about it before generating the final code. For example, when generating code to be deployed to production, it could pick the most appropriate architecture based on its understanding of the web app and deploy it to serverless or another type of architecture (or even a combination). Another example would be reusing your data model logic through all the parts of the stack while defining it just once in Wasp. DSL opens the potential for optimisations, static analysis and extensibility.<p>Wasp’s compiler is built in Haskell and it compiles the source code in Wasp + React/Node.js into the target code in just React and Node.js (currently in Javascript, but we plan to move to Typescript soon). The generated code is human readable and can easily be inspected and even ejected if Wasp becomes too limiting.<p>We are currently in Alpha and many features are still rough or missing, but you can try it out and build and deploy web apps! There are things we haven’t solved yet and others that will probably change as we progress.<p>You can check out our repo at <a href="https://github.com/wasp-lang/wasp" rel="nofollow">https://github.com/wasp-lang/wasp</a> and give it a try at <a href="https://wasp-lang.dev/docs/" rel="nofollow">https://wasp-lang.dev/docs/</a>.<p>Thank you for reading! We would love to get your feedback and also hear about your experiences building web apps - what has worked for you and where do you see the opportunities for improvement?
Show HN: I wrote an entire book to build a mouseless dev environment
Show HN: I wrote an entire book to build a mouseless dev environment
Show HN: I wrote an entire book to build a mouseless dev environment
Show HN: A fast JSON library for Go
Show HN: A fast JSON library for Go
Launch HN: Jiga (YC W21) – Faster custom parts for hardware products
Hi HN! It's Assaf and I'm the co-founder of Jiga
(<a href="https://app.jiga3d.com" rel="nofollow">https://app.jiga3d.com</a>). We make it fast and easy to produce parts for hardware products.<p>You can upload a 3D model (such as STL or SLDPRT) file and get a production quote within seconds. We have a vetted network of manufacturers around the world who can produce your part with 3D printing (plastic and metal), CNC machining (plastic and metal), or sheet metal. It's literally 3 clicks: 1. upload your file on <a href="https://app.jiga3d.com" rel="nofollow">https://app.jiga3d.com</a>. 2. select manufacturing process 3. select quote and order.<p>We built this because we are hardware makers ourselves. I was running a 3D printing manufacturing service before starting Jiga, and we were shocked by how bad an experience it was to get quotes and order parts online, or from machine shops. I spent a significant amount of my time and money on inefficient communication, paperwork, sourcing and quoting.<p>Ok, so now you're probably asking how we're different from other online manufacturing companies? Well, besides being not as fast, they act as an unnecessary middleman. They cut a huge fee, block hardware builders from talking directly to manufacturers and getting professional feedback (such as making sure they can produce that 0.15mm tolerance exactly on that little hole).<p>For examples, take some of our customers: an enterprise that builds jets for the US army, a company that builds a device that enables tractors to be autonomous, a hospital that builds 3D printed ventilation machines to tackle Covid-19 (first parts ordered with Jiga!) or a company that builds robotic arms.<p>These companies start by looking for the right supplier to make their part. They email quote requests with the designs, some suppliers reply after a week, some don’t. They log this data into spreadsheets and folders while making comparisons. Finally after two weeks the supplier is ready to take your order but oh no! They mixed up the email threads and made a mistake - and the wrong part was produced.<p>Worse, when getting into producing more than just prototypes, they have to manage the supply of many different components and timelines, making sure that that they won’t find themselves delaying over some little component and avoiding any miscommunication about parts or revisions. All this inefficiency is not only frustrating but also costly - makers and companies lose millions every year because of miscommunication and delays. We built Jiga to make this process efficient and painless.<p>We handle all logistics (always first class/priority shipping) and make sure that customers are 100% happy with every order that they get. Additionally, we let you read supplier reviews, check their certifications and communicate directly with them. Want to make sure that the supplier is aware of that 0.15mm hole? No problem, reach to them over our platform and they will answer promptly.<p>We make money from commissions on orders based on agreements with suppliers.<p>I’m looking forward to talking to anyone who builds hardware, and to hearing your feedback and ideas and experiences in this space. If you've ever needed parts for things you were making, I hope you'll give us a spin. Have at it, HN!
Launch HN: SigNoz (YC W21) – Open-source alternative to DataDog
Hi HN,<p>Pranay and Ankit here. We’re founders of SigNoz ( <a href="https://signoz.io" rel="nofollow">https://signoz.io</a> ), an open source observability platform. We are building an open-core alternative to DataDog for companies that are security and privacy conscious, and are concerned about huge bills they need to pay to SaaS observability vendors.<p>Observability means being able to monitor your application components - from mobile and web front-ends to infrastructure, and being able to ask questions about their states. Things like latency, error rates, RPS, etc. Better observability helps developers find the cause of issues in their deployed software and solve them quickly.<p>Ankit was leading an engineering team, where we became aware of the importance of observability in a microservices system where each service depended on the health of multiple other services. And we saw that this problem was getting more and more important, esp. in today’s world of distributed systems.<p>The journey of SigNoz started with our own pain point. I was working in a startup in India. We didn’t use application monitoring (APM) tools like DataDog/NewRelic as it was very costly, though we badly needed it. We had many customers complaining about broken APIs or a payment not processing - and we had to get into war room mode to solve it. Having a good observability system would have allowed us to solve these issues much more quickly.<p>Not having any solution which met our needs, we set out to do something about this.<p>In our initial exploration, we tried setting up RED (Rate, Error and Duration) and infra metrics using Prometheus. But we soon realized that metrics can only give you an aggregate overview of systems. You need to debug why these metrics went haywire. This led us to explore Jaeger, an open source distributed tracing system.<p>Key issues with Jaeger were that there was no concept of metrics in Jaegers, and datastores supported by Jaeger lacked aggregation capabilities. For example, if you had tags of “customer_type: premium” for your premium customers, you couldn’t find p99 latency experienced by them through Jaeger.<p>We found that though there are many backend products - an open source product with UI custom-built for observability, which integrates metrics & traces, was missing.<p>Also, some folks we talked to expressed concern about sending data outside of boundaries - and we felt that with increasing privacy regulations, this would become more critical. We thought there was scope for an open source solution that addresses these points.<p>We think that currently there is a huge gap between the state of SaaS APM products and OSS products. There is a scope for open core products which is open source but also supports enterprise scale and comes with support and advanced features.<p>Some of our key features - (1) Seamless UI to track metrics and traces (2) Ability to get metrics for business-relevant queries, e.g. latency faced by premium customers (3) Aggregates on filtered traces, etc.<p>We plan to focus next on building native alert managers, support for custom metrics and then logs ( waiting for open telemetry logs to mature more in this). More details about our roadmap here ( <a href="https://signoz.io/docs/roadmap" rel="nofollow">https://signoz.io/docs/roadmap</a> )<p>We are based on Golang & React. The design of SigNoz is inspired by streaming data architecture. Data is ingested to Kafka and relevant info & meta-data is extracted by stream processing. Any number of processors can be built as per business needs. Processed data is ingested to real-time analytics datastore, Apache Druid, which powers aggregates on slicing and dicing of high dimensional data. In the initial benchmarks we did for self-hosting SigNoz, we found that it would be 10x more cost-effective than SaaS vendors ( <a href="https://signoz.io/blog/signoz-benchmarks/" rel="nofollow">https://signoz.io/blog/signoz-benchmarks/</a> )<p>We’ve launched this repo under MIT license so any developer can use the tool. The goal is to not charge individual developers & small teams. We eventually plan on making a licensed version where we charge for features that large companies care about like advanced security, single sign-on, advanced integrations and support.<p>You can check out our repo at <a href="https://github.com/SigNoz/signoz" rel="nofollow">https://github.com/SigNoz/signoz</a> We have a ton of features in mind and would love you to try it and let us know your feedback!
Launch HN: SigNoz (YC W21) – Open-source alternative to DataDog
Hi HN,<p>Pranay and Ankit here. We’re founders of SigNoz ( <a href="https://signoz.io" rel="nofollow">https://signoz.io</a> ), an open source observability platform. We are building an open-core alternative to DataDog for companies that are security and privacy conscious, and are concerned about huge bills they need to pay to SaaS observability vendors.<p>Observability means being able to monitor your application components - from mobile and web front-ends to infrastructure, and being able to ask questions about their states. Things like latency, error rates, RPS, etc. Better observability helps developers find the cause of issues in their deployed software and solve them quickly.<p>Ankit was leading an engineering team, where we became aware of the importance of observability in a microservices system where each service depended on the health of multiple other services. And we saw that this problem was getting more and more important, esp. in today’s world of distributed systems.<p>The journey of SigNoz started with our own pain point. I was working in a startup in India. We didn’t use application monitoring (APM) tools like DataDog/NewRelic as it was very costly, though we badly needed it. We had many customers complaining about broken APIs or a payment not processing - and we had to get into war room mode to solve it. Having a good observability system would have allowed us to solve these issues much more quickly.<p>Not having any solution which met our needs, we set out to do something about this.<p>In our initial exploration, we tried setting up RED (Rate, Error and Duration) and infra metrics using Prometheus. But we soon realized that metrics can only give you an aggregate overview of systems. You need to debug why these metrics went haywire. This led us to explore Jaeger, an open source distributed tracing system.<p>Key issues with Jaeger were that there was no concept of metrics in Jaegers, and datastores supported by Jaeger lacked aggregation capabilities. For example, if you had tags of “customer_type: premium” for your premium customers, you couldn’t find p99 latency experienced by them through Jaeger.<p>We found that though there are many backend products - an open source product with UI custom-built for observability, which integrates metrics & traces, was missing.<p>Also, some folks we talked to expressed concern about sending data outside of boundaries - and we felt that with increasing privacy regulations, this would become more critical. We thought there was scope for an open source solution that addresses these points.<p>We think that currently there is a huge gap between the state of SaaS APM products and OSS products. There is a scope for open core products which is open source but also supports enterprise scale and comes with support and advanced features.<p>Some of our key features - (1) Seamless UI to track metrics and traces (2) Ability to get metrics for business-relevant queries, e.g. latency faced by premium customers (3) Aggregates on filtered traces, etc.<p>We plan to focus next on building native alert managers, support for custom metrics and then logs ( waiting for open telemetry logs to mature more in this). More details about our roadmap here ( <a href="https://signoz.io/docs/roadmap" rel="nofollow">https://signoz.io/docs/roadmap</a> )<p>We are based on Golang & React. The design of SigNoz is inspired by streaming data architecture. Data is ingested to Kafka and relevant info & meta-data is extracted by stream processing. Any number of processors can be built as per business needs. Processed data is ingested to real-time analytics datastore, Apache Druid, which powers aggregates on slicing and dicing of high dimensional data. In the initial benchmarks we did for self-hosting SigNoz, we found that it would be 10x more cost-effective than SaaS vendors ( <a href="https://signoz.io/blog/signoz-benchmarks/" rel="nofollow">https://signoz.io/blog/signoz-benchmarks/</a> )<p>We’ve launched this repo under MIT license so any developer can use the tool. The goal is to not charge individual developers & small teams. We eventually plan on making a licensed version where we charge for features that large companies care about like advanced security, single sign-on, advanced integrations and support.<p>You can check out our repo at <a href="https://github.com/SigNoz/signoz" rel="nofollow">https://github.com/SigNoz/signoz</a> We have a ton of features in mind and would love you to try it and let us know your feedback!
Launch HN: SigNoz (YC W21) – Open-source alternative to DataDog
Hi HN,<p>Pranay and Ankit here. We’re founders of SigNoz ( <a href="https://signoz.io" rel="nofollow">https://signoz.io</a> ), an open source observability platform. We are building an open-core alternative to DataDog for companies that are security and privacy conscious, and are concerned about huge bills they need to pay to SaaS observability vendors.<p>Observability means being able to monitor your application components - from mobile and web front-ends to infrastructure, and being able to ask questions about their states. Things like latency, error rates, RPS, etc. Better observability helps developers find the cause of issues in their deployed software and solve them quickly.<p>Ankit was leading an engineering team, where we became aware of the importance of observability in a microservices system where each service depended on the health of multiple other services. And we saw that this problem was getting more and more important, esp. in today’s world of distributed systems.<p>The journey of SigNoz started with our own pain point. I was working in a startup in India. We didn’t use application monitoring (APM) tools like DataDog/NewRelic as it was very costly, though we badly needed it. We had many customers complaining about broken APIs or a payment not processing - and we had to get into war room mode to solve it. Having a good observability system would have allowed us to solve these issues much more quickly.<p>Not having any solution which met our needs, we set out to do something about this.<p>In our initial exploration, we tried setting up RED (Rate, Error and Duration) and infra metrics using Prometheus. But we soon realized that metrics can only give you an aggregate overview of systems. You need to debug why these metrics went haywire. This led us to explore Jaeger, an open source distributed tracing system.<p>Key issues with Jaeger were that there was no concept of metrics in Jaegers, and datastores supported by Jaeger lacked aggregation capabilities. For example, if you had tags of “customer_type: premium” for your premium customers, you couldn’t find p99 latency experienced by them through Jaeger.<p>We found that though there are many backend products - an open source product with UI custom-built for observability, which integrates metrics & traces, was missing.<p>Also, some folks we talked to expressed concern about sending data outside of boundaries - and we felt that with increasing privacy regulations, this would become more critical. We thought there was scope for an open source solution that addresses these points.<p>We think that currently there is a huge gap between the state of SaaS APM products and OSS products. There is a scope for open core products which is open source but also supports enterprise scale and comes with support and advanced features.<p>Some of our key features - (1) Seamless UI to track metrics and traces (2) Ability to get metrics for business-relevant queries, e.g. latency faced by premium customers (3) Aggregates on filtered traces, etc.<p>We plan to focus next on building native alert managers, support for custom metrics and then logs ( waiting for open telemetry logs to mature more in this). More details about our roadmap here ( <a href="https://signoz.io/docs/roadmap" rel="nofollow">https://signoz.io/docs/roadmap</a> )<p>We are based on Golang & React. The design of SigNoz is inspired by streaming data architecture. Data is ingested to Kafka and relevant info & meta-data is extracted by stream processing. Any number of processors can be built as per business needs. Processed data is ingested to real-time analytics datastore, Apache Druid, which powers aggregates on slicing and dicing of high dimensional data. In the initial benchmarks we did for self-hosting SigNoz, we found that it would be 10x more cost-effective than SaaS vendors ( <a href="https://signoz.io/blog/signoz-benchmarks/" rel="nofollow">https://signoz.io/blog/signoz-benchmarks/</a> )<p>We’ve launched this repo under MIT license so any developer can use the tool. The goal is to not charge individual developers & small teams. We eventually plan on making a licensed version where we charge for features that large companies care about like advanced security, single sign-on, advanced integrations and support.<p>You can check out our repo at <a href="https://github.com/SigNoz/signoz" rel="nofollow">https://github.com/SigNoz/signoz</a> We have a ton of features in mind and would love you to try it and let us know your feedback!
Show HN: Weekend project, shows when the next season of your TV show premieres
I treated myself to a solo hackathon this weekend and built
<a href="https://next-season-of.com" rel="nofollow">https://next-season-of.com</a>. The data is scrapped from IMDB and the website is generated using the hugo template engine. There's still a lot of optimization to be done but I'm planning to use this as a learning ground to try and get my pages to rank in Google. It would be really cool to search "next season of Ozark" and see a link to next-season-of.com.
Show HN: Weekend project, shows when the next season of your TV show premieres
I treated myself to a solo hackathon this weekend and built
<a href="https://next-season-of.com" rel="nofollow">https://next-season-of.com</a>. The data is scrapped from IMDB and the website is generated using the hugo template engine. There's still a lot of optimization to be done but I'm planning to use this as a learning ground to try and get my pages to rank in Google. It would be really cool to search "next season of Ozark" and see a link to next-season-of.com.
Launch HN: Infracost (YC W21) – open-source cloud cost estimator
Hi, we’re Ali, Hassan and Alistair and we co-founded Infracost (<a href="https://www.infracost.io" rel="nofollow">https://www.infracost.io</a>). Infracost is an open-source cloud cost estimator for your pull requests. When you change your infrastructure code (Terraform), Infracost posts a comment in the pull request, which tells you the impact of this change to your cloud bill, e.g. “this will increase your bill by 25% next month”.<p>Existing cloud cost management products focus on post-bill analysis and target finance and management teams via charting dashboards. We built one of these back in 2013. They are all missing an important piece - the people who are responsible for purchasing cloud resources are not shown costs upfront, so they don’t know how much the resources will cost before launching them. We want to make cloud costs simpler to understand for developers and DevOps so they can make better decisions, which we believe will lead to more cost-efficient systems.<p>In 2011 Ali and Hassan started a cloud cost forecasting company based on Ali’s PhD research. They applied to YC and got through to the interview round. RightScale acquired them in 2012. I read about their YC interview experience on HN, reached out and ended up joining them. We went on to form the team that built RightScale’s cloud cost management product (now called Flexera Optima).<p>In our most recent startup (which failed) we were launching cloud stacks for users on-demand and we wanted a way to work out the cost of each. We hacked together something by building a GraphQL-based cloud pricing API and a CLI that parsed our Terraform code and output a cost breakdown.<p>We released the code on GitHub as Infracost and discovered that others had similar problems. We got requests to support more cloud services and integrate it into pull requests. At the moment, Infracost supports Terraform for AWS and Google Cloud (we’re adding new resources every week). It can be integrated into GitHub, GitLab, CircleCI, Bitbucket and Atlantis, or can be used anywhere through the CLI. In the future we plan to add support for more cloud vendors and infrastructure-as-code tools (Azure, CloudFormation, Pulumi, etc).<p>We now spend a lot of our days trawling through the cloud pricing pages working out how pricing works for different cloud services. We’re grateful for the contributors who have helped us with this. AWS currently has over 2 million price points and this is constantly increasing. Users are requesting better support for usage-based services like data transfer, S3 and Lambda. Currently we allow for usage estimates to be passed into the tool, and are looking at other methods, i.e. based on last month’s actual usage. We’ve also learned, the hard way, the importance of UX in CLI and workflow tools.<p>So far we are seeing a few use-cases for Infracost. Some enterprise users have integrated it into their “self-service” cloud catalog to set cost expectations before provisioning. Other users have integrated it into their CI pipeline as a safety net to catch unexpected costs. And some users are running it at design time to compare options and model usage.<p>We’ve talked to Sid Sijbrandij (CEO of GitLab), and Ian Tien (CEO of Mattermost) about when and how to monetize. Currently we are thinking about a buyer-based open core approach, in which the individual contributor edition will always be free, and enterprise paid features will include multi-team support, management reports and private cloud support.<p>We’d really appreciate it if you try it out and give us feedback. You can check out the repo at <a href="https://github.com/infracost/infracost" rel="nofollow">https://github.com/infracost/infracost</a>. We’d love your thoughts on our approach, and anything that has worked, or hasn’t worked for you when it comes to managing cloud costs.
Launch HN: Infracost (YC W21) – open-source cloud cost estimator
Hi, we’re Ali, Hassan and Alistair and we co-founded Infracost (<a href="https://www.infracost.io" rel="nofollow">https://www.infracost.io</a>). Infracost is an open-source cloud cost estimator for your pull requests. When you change your infrastructure code (Terraform), Infracost posts a comment in the pull request, which tells you the impact of this change to your cloud bill, e.g. “this will increase your bill by 25% next month”.<p>Existing cloud cost management products focus on post-bill analysis and target finance and management teams via charting dashboards. We built one of these back in 2013. They are all missing an important piece - the people who are responsible for purchasing cloud resources are not shown costs upfront, so they don’t know how much the resources will cost before launching them. We want to make cloud costs simpler to understand for developers and DevOps so they can make better decisions, which we believe will lead to more cost-efficient systems.<p>In 2011 Ali and Hassan started a cloud cost forecasting company based on Ali’s PhD research. They applied to YC and got through to the interview round. RightScale acquired them in 2012. I read about their YC interview experience on HN, reached out and ended up joining them. We went on to form the team that built RightScale’s cloud cost management product (now called Flexera Optima).<p>In our most recent startup (which failed) we were launching cloud stacks for users on-demand and we wanted a way to work out the cost of each. We hacked together something by building a GraphQL-based cloud pricing API and a CLI that parsed our Terraform code and output a cost breakdown.<p>We released the code on GitHub as Infracost and discovered that others had similar problems. We got requests to support more cloud services and integrate it into pull requests. At the moment, Infracost supports Terraform for AWS and Google Cloud (we’re adding new resources every week). It can be integrated into GitHub, GitLab, CircleCI, Bitbucket and Atlantis, or can be used anywhere through the CLI. In the future we plan to add support for more cloud vendors and infrastructure-as-code tools (Azure, CloudFormation, Pulumi, etc).<p>We now spend a lot of our days trawling through the cloud pricing pages working out how pricing works for different cloud services. We’re grateful for the contributors who have helped us with this. AWS currently has over 2 million price points and this is constantly increasing. Users are requesting better support for usage-based services like data transfer, S3 and Lambda. Currently we allow for usage estimates to be passed into the tool, and are looking at other methods, i.e. based on last month’s actual usage. We’ve also learned, the hard way, the importance of UX in CLI and workflow tools.<p>So far we are seeing a few use-cases for Infracost. Some enterprise users have integrated it into their “self-service” cloud catalog to set cost expectations before provisioning. Other users have integrated it into their CI pipeline as a safety net to catch unexpected costs. And some users are running it at design time to compare options and model usage.<p>We’ve talked to Sid Sijbrandij (CEO of GitLab), and Ian Tien (CEO of Mattermost) about when and how to monetize. Currently we are thinking about a buyer-based open core approach, in which the individual contributor edition will always be free, and enterprise paid features will include multi-team support, management reports and private cloud support.<p>We’d really appreciate it if you try it out and give us feedback. You can check out the repo at <a href="https://github.com/infracost/infracost" rel="nofollow">https://github.com/infracost/infracost</a>. We’d love your thoughts on our approach, and anything that has worked, or hasn’t worked for you when it comes to managing cloud costs.
Show HN: "Programming Algorithms in Lisp” Book
Show HN: "Programming Algorithms in Lisp” Book
Show HN: Clerk – all of user management as-a-service, not just authentication
Show HN: Clerk – all of user management as-a-service, not just authentication