121–130 of 176 posts
see https://www.nextplatform.com/2019/02/20/google-wants-cloud-s... for better explanation from Google's Urs Hölzle
Simpler and monolith (an endlessly re-suggested reply) has it's place, but I see it as impossible for any "simple" solution to ever gain enough mindshare to win. A lot of people suggesting monoliths & hosted services, but they are never going to have the community, the presence of something like Kubernetes, which unites people, which people collaborate over, in the same way we all got to learn & experience & co-devel…
In ops world, I think getting much better at Kubernetes is going to be ongoing for a while. Devs running k3s or microk8s will become more common for local-dev. We'll need better deployment tools, and #GitOps & project like Flux are going to help a lot.
Helm does ok, but it could definitely be disrupted. The various code-oriented approaches are ok but honestly uncompelling. Endless attempts to build/promote new templating languages seems to be ongoing, but Helm remains the baseline expectation.
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.
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.
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…
How does serverless make more sense for a simple web api than a traditional web framework?
- Zero to very minimal devops / syadmin knowledge required. - Monitoring and few other important tooling is usually out of the box
- Add on / Related services in serverless stacks like vercel/netlify etc also handles email/auth type components, a framework will only provider library for these, implementation is in developer hands.
- Simplified deployment : most services can sync with Git repos, provide one click deploy and have simple CLI binaries .
Also k8s adoption standardizing the visibility and forcing security to all (ssl everywhere, encryption, authentication for each request, etc).
That mass organizational evolution in enterprises opens up a lot more simplicity for just-containers or bespoke scaling strategies. Go ahead and run micro, nano, macro, or mega services. Don't be limited by docker "conventions" on size or complexity.
Of course serverless was the natural evolution to k8s, but the "DC OS" is still a very very very nascent thing that is far behind something like a POSIX standard or anything like that for portability. Serverless is all lock-in right now. k8s was nice in a way because at least it was SOMEWHAT non-lockin as an architecture/framework. If you squinted. Hard.
Standards and portability breed true flexibility and good tools, and we probably need a lot more of that in the cloudrealm.
However an alternate perspective is the microservices were not micro enough to make it worth the overhead + cost. My opinion is the reason this none of this feels great is because a container is not small enough of a base unit to enable you to completely forget about infrastructure.
That's why I'm betting the next paradigm that gains traction is fully serverless architectures. The overall direction things have been going for decades is to make hardware more invisible and I think we finally get pretty close with serverless.
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.
https://temporal.io if the lesson from k8s is that after containers we needed container orchestration - the business logic analog is that services will need service orchestration. (disclaimer: i work here so i'm both biased and have skin in the game)
https://temporal.io if the lesson from k8s is that after containers we needed container orchestration - the business logic analog is that services will need service orchestration. (disclaimer: i work here so i'm both biased and have skin in the game)
Temporal cannot replace a general purpose compute orchestrator.
Things that are interesting about it:
- any device and any workload from IoT to servers.
- totally new security model from the ground up which is how I expect it to be the main driver for business use cases
- new app delivery model which is kind of like a weird mix of the web as you know it currently, native apps and kubernetes.
- seems to be developing an interesting interop story where the goal is that you will also be able to run Android and linux apps on it despite the fact that it’s not Linux and not based on Linux. Everything is custom made from the ground up.
- the development story is also super interesting, all IPC happens over a gRPC like protocol and provides a nice language neutral way to develop for the platform and to integrate with everything else.
Some of the other projects I’ve seen coming out of Google make way more sense in this context too. Flutter for web is a good example which I know is not exactly a crowd favorite here on HN but I’m serious when I say that now might be a good time to go and look at Dart again. It’s actually a really nice modern language if you are coming from JavaScript, Typescript or Java you will be up and running very quickly.
I think this is about to become a hugely disruptive force. If Google manage to not screw this up that is.
For a slightly longer term bet I’d say by the time it hits say v5 it will be the biggest OS / platform in the world by a considerable margin.