OpenChoreo is an open-source project for building internal developer platforms without hiding Kubernetes. With OpenChoreo, platform engineers work with native K8s resources, while developers get higher-level components, templates, and self-service workflows. The platform is modular and supports extensions, policies, observability, and agent-based automation.
IMO this analysis is best done with three groups, not two. People who do well in sports, do well in academics, and third group who does neither. Any analysis that put the middle group to the other will not give right output.
If you are going to blindly follow HN or other site's comments, then it will not help. But as far as giving different perspectives HN and reddit/programming etc are good
I think low code can really help while doing broader level coding, e.g. service, API, component definitions, and also mapping out communications/ service calls. When doing detailed data manipulations, data mapping can help, but when digging deep, the code is easier. If we can switch and use mixed approches between code and low code, it can improve the productivity in my opinion.
With Choreo, you can write integrations, write and manage APIs, facilitate reuse via a marketplace, and much more.
Three things that sets Choreo apart:
1. Simultaneous low-code and code: Choreo enables you to go from low-code to source code, easily switching back and forth with zero boundaries.
2. Integration and collaboration of effort: Developers simply write code; we’ll do the rest to give you a production-grade deployment including sophisticated build pipelines, autoscaling, high availability, deep observability, performance forecasts, API management, and marketplaces.
3. Lock-in free low-code: It's all available in GitHub because your low-code is actually just code. As a result, you can clone and edit the code anytime. Please note, some of this feature is not available in the first public beta launch.
We are a team known for many open source projects (Apache Axis2, Apache Synapse, WSO2 API Manager, WSO2 ESB, Ballerina) that powers thousands of real-world systems.
We all used to build software by composing libraries and running programs on top of middleware platforms. The world, however, has changed; now we build most software apps by composing APIs together and running them in a container.
Choreo is the result of over five years of work towards building a better software development experience for cloud-focused developers. With Choreo, you can write integrations, write and manage APIs, facilitate reuse via a marketplace, and much more.
We see three things that sets Choreo apart:
1. Simultaneous low-code and code:Choreo enables you to go from low-code to source code, easily switching back and forth with zero boundaries. This is powered by Ballerina - a programming language we have been working on for 5+ years (see https://ballerina.io).
2. Lock-in free low-code: Because your low-code is actually just code, it's all available in GitHub. As a result, you can clone and edit the code anytime. (Some aspects of this feature are not in the first public beta but will be available soon.)
3. Focus on creative development, not building platforms: Developers simply write code; we’ll do the rest to give you a production-grade deployment including sophisticated build pipelines, autoscaling, high availability, deep observability, performance forecasts, API management, and marketplaces.
1) It is mentioned that KNative "deliver a serverless experience to developers on any cloud". How does it work with any cloud? Are you referring to fact that all clouds has k8s? Is it already supported in any cloud or will be supported?
2) If any cloud is supported, does it virtualize services such as storage, queues, API management and Identity
3) Does Knative can seamlessly switch monitoring to what is provided by each cloud.
Above observations are true when the conditions you match are simple. I have observed the same several times that when queries are rather simple you are better off with a single node. What happening is that cost of IO dominates.
There is a clear value in making Stream processors work closer to hardware. That does not mean single node can handle does better under all use cases. When the complexity of queries increases and when queries can be portioned, there are use cases where still distributed setup can do better.
I work on WSO2 Stream Processor, https://wso2.com/analytics ( Opensource, Apache Licensed). We have chosen to support both worlds where SP has an HA mode that can two servers in a Hot-warm mode that do 100K event per the second and give you a two-node deployment. If you want more, SP runs on top of Kafka, scales, and support multi-data center deployments as well. If the user is in doubt, he can start small and later switch to Kafka without changing any code.
It is compiled and output is bytecode. Currently bytecode interpreter is in Java. In the future, it can run on other languages (go?) or using something like LLVM with we write an interpreter for the bytecode. However, to do that we need to port the connectors, which is some work.
I think the best way to search for a subject for papers is to build a mapping between subjects and people/ conferences and incorporate that to searching.
With collectors like CMS, you can control after what percentage of the GC is filled GC will kick in. I think you can use that get the same effect. This is only for old gen.
I think games are ripe for Big Data and IoT as they are less critical usecases compared to health etc. Following is two similar efforts with football, first done by us and second by SAP.
Big Data Realtime Analytics world mostly doing and discussing counting usecases and implementing them by hand (e.g. using Storm). However, realtime usecases like windows, temporal event patterns etc are too complicated to be rewritten by every programmer. We need higher level abstractions, and learning from Hive and CEP, SQL like languages might fit the bill.