The value of Groq comes from its excellent price-to-performance ratio. Its inferencing speeds are faster than those of H200s, and it has the lowest costs in the industry. When running similar batch jobs across different providers compared to Groq, the processing speed can sometimes be more than 10 times faster. These figures are important for developing practical applications for production use. It's common for me to run workloads in Groq that cost less than $100, while the same workload can approach $1,000 on Bedrock or Gemini. They have tuned a set of OS models that can now deliver a full application. The speeds have allowed me to offload a lot of the functionality from heuristics to straight-up LLMs.
I think there is a different way to look at it. My personal experience is that enterprises that are at the forefront of adopting new ways of working, are now much more comfortable taking risks with building applications and insourcing SaaS functionality. The amount of custom software build is actually increasing and the codebase are getting more complex. Is there a price to pay down the road? Maybe.
So, relying on a large context can be tricky. Instead I’ve tried to get to a ER model quickly. And from there build modules that don’t have tight dependencies.
Agent mode without rails is like a boat without a rudder.
What worked for me was coming up with an extremely opinionated way to develop an application and then generating instructions (mini milestones) by combining it with the requirements.
These instructions end up being very explicit in the sequence of things it should do (write the tests first), how the code should be written and where to place it etc. So the output ended up being very similar regardless of the coding agent being used.
Not the founder? maybe read Walter Isaacson's book.
Stock graph shows Tesla stock had no material impact from the Solar City purchase, 90% of it's value coming after 2020. Today, Tesla energy and solar dominates the industry to the point where every installer offers Tesla Solar including the largest US installer Sunrun.
The key distinction lies in how YieldStar approaches setting rental prices compared to other systems. YieldStar not only recommends rental prices by analyzing the entire inventory it oversees but also incorporates a strategy that effectively eliminates the possibility of rent negotiation with potential tenants. This approach mirrors the dynamics of the prisoner’s dilemma, a situation in game theory where individuals may not cooperate, even if it’s in their best interest to do so. However, YieldStar transcends the Nash equilibrium—the point at which no participant can benefit by changing strategies if the others remain unchanged—by stripping tenants of any bargaining power. This ensures that the rent pricing strategy is firmly controlled, without the usual back-and-forth negotiation process.
App Runner is an abstraction on top of FarGate designed to compete with Cloud Run, which is why it doesn’t scale down to zero. I too haven’t found anything that beats the simplicity of a GCP deployment sigh..
Not so crazy. I can name at least 2 of the top 5 North American airlines running this in production for Mobile and Web supporting hundreds of millions of user requests, daily.
I too have a small team that built a greenfield application that generates about $100M annually for a large hotel chain. Serverless allowed us to get to market fast and everyone in the team is a feature developer — 0 infra folks. I think that’s the biggest value we have been able to derive from this compared all the other internal App teams who struggle with release cadences, experimentation and TTV.
But I fully acknowledge this is not the ideal and optimal setup and we are paying more to AWS on the OpEx. However, we have gone 3 years without any downtime at full speed, and the fact that we were able to unlock net new revenue very quickly has made all project costs and OpEx very minuscule.
But I think once the application boundaries stabilize and we are able to take a breather from full on feature development, hope to migrate some of this to simpler containerized infrastructure.
To make this transition easier, we use Serverless-framework and decouple the app component architecture from deployment architecture, so developers don’t worry whether this is getting deployed to a lambda or container.
Typically each channel takes its own course and evolves at different speeds with different needs. Trying to engineer a common set of APIs that serve all channels eventually leads to ever increasing FE logic with a backend API with leaky abstraction (by virtue of trying to accommodate different UI concerns).
By decoupling the BFF APIs which are geared towards a UI specifically, in a way you are moving a big part of the logic and orchestration to the backend and keeping the UI layer super lite. From practical experience, this has been a very helpful pattern both in my startups and enterprise career.