141–150 of 176 posts
Earlier quoted context omitted.
What have you seen in that space so far?
Space Cloud https://news.ycombinator.com/item?id=26997595 and Porter https://news.ycombinator.com/item?id=26993421 were the ones I've seen recently, although admittedly on re-look I may have misunderstood Space Cloud and I could have sworn there was a third
Then, hosting those apps in some form will likely need to adopt AI-centric workflows in some way. We might even see AI-driven request routing and AI-driven WAF features at some point, too.
Earlier quoted context omitted.
What I'd really like to hear is the story for after you're gone and the business has several hundred services spread out over 5-10 years of development, with varying historical stratums, and plenty of them being left on life support, where the business just doesn't want to pay barely anything to keep them running. And then how does the teams dealing with cross cutting concerns like security, logging and monitoring de…
I’m not sure what you are getting at. Several hundred services probably means going too far to the microservices side. Cross cutting concerns like logging and monitoring are handled by 12factor. Services log to stdout and have the container orchestration pipe it to a logging backend. Monitoring can be standardised as well with healthcheck and metric endpoints. Security always has a maintenance cost attached unless yo…
You can easily hit that in a small fortune 500 company with ~10,000 employees, without microservices.
Earlier quoted context omitted.
Temporal cannot replace a general purpose compute orchestrator.
Hey, I'm the head of product at Temporal. I would love to understand what you mean by this.
My bet: rich fat clients. Super powerful phones that can run your entire e-commerce monolith to process my checkout. I’m talking about hosting your backend (most of it) and DB on my phone. Cheap syncs from my phone to your “main” server is fine because I’m always online and I have 10G connection. This will also force a shift in the way we develop programs.
So you no longer need to deploy and maintain hundreds of services. You’ll only need to deploy and maintain one that gets synced to millions of devices (no app stores) rather fast (because, yes, a new compression algorithm will emerge and your whole monolith is now only a couple of megabytes).
No, really. It's a cycle.
As businesses start to realize microservices aren't really worth it due to the complexity and cost it entails, they will start reverting back to hosting monoliths on VMs or services like Heroku/Netlify/Laravel Forge/Beanstalk, and they'll find out they can save a lot of money on compute and man hours by doing this. For more simple workflows, e.g. a single API endpoint, there's serverless and other SaaS services out t…
Serverless? There are always servers. APIs don't exist in a vacuum or scale magically. If you don't understand how to build what's underneath, then you don't understand what's involved and are at the mercy of vendors or someone else.
Earlier quoted context omitted.
Serverless? There are always servers. APIs don't exist in a vacuum or scale magically. If you don't understand how to build what's underneath, then you don't understand what's involved and are at the mercy of vendors or someone else.
By that logic I as AP dev should know systems programming and OS. A systems programmer should know kernel development ? A kernel developer should know assembly and microprocessor architecture? Everybody has at best little or shaky knowledge of underlying abstraction. Yes it helps to know more, but is not really practical to expect that knowledge as the minimum required.
Earlier quoted context omitted.
Serverless? There are always servers. APIs don't exist in a vacuum or scale magically. If you don't understand how to build what's underneath, then you don't understand what's involved and are at the mercy of vendors or someone else.
I have built what was underneath — and then threw it away, because the managed-services vendor built it better, and the OpEx of paying them to manage it was less than the OpEx of paying myself to maintain it.
Virtual private servers, but suspended/resumed/scaled for you without you needing to worry about the underlying method of deployment. AWS lambda + aurora but running actual operating systems. You want more threads or memory - they're there for you. Every user process is metered and monitored. Charged by cpuops + memoryops + iops + hdstorage bytes by the second. You never need to worry about how much disk you need, it's there, unlimited except by your pocket book. You never need to worry about how much compute you need - it's there, unlimited by your pocketbook. You never need to worry about how much memory you need. Backups of your drives are automatic.
All data is encrypted to allow it to live amongst all the other tenants' data. All wire traffic is encrypted.
It works exactly like ec2, except it's on-demand usage and overprovisioned and multi-tenant. Alarms and user-set limits for price and scale are respected. The only thing that will leak about the abstraction is that you'll have to mark processes as suspendable and dependent. You don't need to run your metrics collector if your app isn't running. Cron jobs should wake up the server, etc. Ssh/scp just works. You get service discovery out of the box, and your point of entry is the app lb dashboard. A real, on-demand, virtual private cloud.