I am starting to build a new application on microservices/API-driven architecture. I do have some requirements for business process management (Human approval activity) and straight-through processing.
Can I use Redhat PAM alone for BPM as well as a microservices orchestration use case or is it recommended to use Fuse with it? I am confused with the usage of Fuse. What are the common use cases of Fuse and PAM?
Is Red Hat PAM can also do microservices orchestration. Do you think it is a viable solution choice for this use-case? Please guide.
Regards
Vinay
if I had to do this I would use something like the api-provider (https://github.com/syndesisio/syndesis-quickstarts/tree/trunk/api-provider) of FuseOnline/Syndesis and have RH PAM call into these endpoints. So in essence RH PAM becomes the orchestrator. Does that help you?
--Kurt
Related
I like what I see and hear from Jelastic. I was wondering if Jelastic will or does support AWS' ECS or Rackspace's Carina? I am just looking for bigger names in IaaS.
Scott
I was wondering if Jelastic will or does support AWS' ECS or Rackspace's Carina?
Yes. Jelastic can be installed on your own hardware, or on almost any public cloud infrastructure - but with the caveat that you get all of the limitations of that underlying infrastructure to go with it.
Naturally my opinion on this is somewhat biased, but having some insight into the workarounds and limitations necessary to apply Jelastic concepts onto AWS, Azure, Google Cloud means it's not something I would personally recommend anyone to do.
For example one of the clear gains from using Jelastic is the substantial cost saving because you do not pay for unused resources. If you layer Jelastic on top of 3rd party infrastructure, you have a fixed cost for that infrastructure => you are paying for unused resources again.
I am just looking for bigger names in IaaS.
Jelastic recently published a blog post showing the very substantial size advantage of the Jelastic Cloud Union over what you think of as the dominant names.
In addition to having portability to migrate your workloads between different providers inside the Cloud Union, as you can see there are several providers offering multi-region directly too.
Overall you have many advantages by purchasing Jelastic service directly from an experienced and qualified provider, to give you the full benefits and capabilities of the platform - including better support and problem resolution since they have ownership of the full stack (relying on AWS or others infrastructure means you have an extra layer for finger pointing, misinformation, and delays when dealing with any issue).
Both Marathon and Aurora are built on Mesos and supposedly are engineered for running long running services. My questions are:
What are their differences? I have struggled in finding any good explanations regarding their key differences
Do these frameworks run anything that runs on Linux? For Marathon they state that it can run anything that "is executable in a shell" but this is sort of vague :)
Thanks!
Disclaimer: I am the VP of Apache Aurora, and have been the tech lead of the Aurora team at Twitter for ~5 years. My likely-biased opinions are my own and do not necessarily represent those of Twitter or the ASF.
Do these frameworks run anything that runs on Linux? For Marathon they
state that it can run anything that "is executable in a shell" but
this is sort of vague :)
Essentially, yes. Ultimately these systems are sophisticated machinery to execute shell code somewhere in a cluster :-)
What are their differences? I have struggled in finding any good
explanations regarding their key differences
Aurora and Marathon do indeed offer similar feature sets, both being classified as "service schedulers". In other words, you hand us instructions for how to run your application servers, and we do our best to keep them up.
I'll offer some differences in broad strokes. When it comes to shortcomings mentioned in each, I think it's safe to say that the communities are aware and intend to fix them.
Ease of use
Aurora is not easy to install. It will likely feel like you are trailblazing while setting it up. It exposes a thrift API, which means you'll need a thrift client to interact with it programmatically (a REST-like API is coming, but is vaporware at the moment), or use our command line client. Aurora has a DSL for configuration which can be daunting, but allows you to easily share templates and common patterns as you use the system more.
Marathon, on the other hand, helps you to run 'Hello World' as quickly as possible. It has great docs to do this in many environments and there's little overhead to get going. It has a REST API, making it easier to adapt to custom tools. It uses JSON for configuration, which is easy to start with but more prone to cargo culting.
Targeted use cases
Aurora has always been designed to handle a large engineering organization. The clusters at Twitter have tens of thousands of machines and hundreds of engineers using them. It is critical to Twitter's business. As a result, we take our requirements of scale, stability, and security very seriously. We make sure to only condone features that we believe are trustworthy at scale in production (for example, we have our Docker support labeled as beta because of known issues with Docker itself and the Mesos-Docker integration). We also have features like preemption that make our clusters suitable for mixing business-critical services with prototypes and experiments.
I can't make any claim for or against Marathon's scalability. On the feature front, Marathon has build out features quickly, but this can feel bleeding edge in practice (Docker support is a good example). This is not always due to Marathon itself, but also layers down the stack. Marathon does not provide preemption.
Ownership
To some, ownership and governance of a project is important. It feel that in practice it does not define the openness of a project, but for some people/companies the legal fine print can be a deal-breaker.
Marathon is owned by a company (Mesosphere)
To some, this is beneficial, to others is is not. It means that you can pay for support and features. It also means that there is something to be sold, and the project direction is ultimately decided by Mesosphere's interests.
Aurora is owned by the Apache Software Foundation
This means it is subject to the governance model of the ASF, driven by the community. Aurora does not have paying customers, and there is not currently a software shop that you can pay for development.
tl;dr If you are just getting your feet wet with running services on Mesos, I would suggest Marathon as your first port of call. It will be easier for you to get running and poke around the ecosystem. If you are forming the 'private cloud strategy' for a company, I suggest seriously considering Aurora, as it is proven and specifically designed for that.
So I've been evaluating both and this is my summary.
Aurora
[+] also handles recurring jobs
[+] finer grained, extensive file-based configuration
[+] has namespaces so multiple environments can co-exist
[-] read-only UI, no official API
[~] file based configuration and cli based execution brings overhead (which can be justified with more extensive feature set)
Marathon
[+] very easy to setup and use
[+] UI that provides control and extensive API (even with features missing from UI at the moment)
[+] event bus to listen in on api calls
[-] handles only long-running jobs
[-] does not have separate deployment-run-cleanup steps, these if necessary need to be combined in a script of one-liner
Even though Aurora has better capabilities, I prefer Marathon due to Auroras complexity/overhead and lack of UI (for control) & API
I have more experience with Marathon.
Ideological:
Marathon is a relatively tested product that is used in production at AirBnB. Aurora is an early Apache project (so YMMV).
Both are open source and active. Feel free to contribute pull requests or file issues!
Technical:
Marathon doesn't schedule batch tasks or cron jobs
Marathon has a friendly UI and better health indicators (in 0.8.x)
In regards to your second question, you can run any command or docker container, and Mesos will do the resource isolation for you. If you have 50% CentOS nodes and 50% Ubuntu nodes and you run a task that executes apt-get, the task will have a 50% chance of failure. Mesos and Marathon have no awareness of the actual machines.
Disclaimer: I don't have hands-on experience with Aurora, only with Marathon.
ad Q1: In a nutshell Apache Aurora is capable of doing what Marathon + Chronos can provide, that is, schedule both long-running services and recurring (batch) jobs; see also Aurora user guide.
ad Q2: Yes, anything. Currently based on cgroups and Docker but hey, you can roll your own.
I want to create a production management system to be used by a small manufacturing firm. The system will allow to document different stages in manufacturing of equipment. The requirements are as follows:
1.Non browser based interface.Need something like Swing or AWT based.While i understand the convenience of implementing a browser based solution,the business owner insists on a non browser interface
2.Accessed from multiple systems.These systems will allow CRUD operations on the central system (Thin Client?)
3.The application will not have more than 3 concurrent users.
I need some advice regarding what would be a good path for this kind of application.Currently, i'm thinking of using Griffon with RMI. However, i don't have much development experience.Read a bit about Apache River (Jini) too.Would it be a good idea to use Griffon with RMI?
Please provide some advice. Thanks.
EDIT:after some reading, i've decided to use more mainstream frameworks.So, Griffon is not an option. How about Jini(Apache River) or OSGI (Apache Felix)?
Hmm how is that a project which recently moved out of the incubation phase be considered mainstream vs a project that's been used in production for more than 3 years now? Anyway, Apache River gives you access to Jini technology and nothing more; meaning you can't achieve item #1 of your list with River alone. River may use RMI for accessing remote resources, however you can use RMI directly, or try out DRMI, Kryonet, Hessian/Burlap, Spring's HTTP Invoker, Protocol Buffers, Avro/Thrift, REST, SOAP, ZMQ and many more.
Even if you choose one of these options and/or River you still have to define the following things
application structure (file structure and runtime behavior)
build setup
dependency management
testing profiles
packaging
deployment strategies
These things and more are what Griffon brings to the table. As you may have noticed the framework allows you to build up applications by adding plugins, reducing thew amount of time you must allot for hunting down dependencies, setting up bootstrap mechanism and getting things done. On the subject of remoting technologies have a look at the different options Griffon has to offer http://artifacts.griffon-framework.org/tags/plugin/remoting
Even more, you can also combine OpenDolphin (http://open-dolphin.org/dolphin_website/Home.html) with Griffon. There's even an example application found at the opendolhpin repository showing a full client-server application (build with Griffon, Grails and OpenDolphin) https://github.com/canoo/open-dolphin/tree/master/dolphin-griffon-crud
With what seems to be your current understanding of the problem, I would not recommend OSGI, especially for a small manufacturing firm (Possible maintenance issues, depending on the "personel").
The main reason why I wouldn't advocate JINI or OSGI in your case is because of what you said
However, i don't have much development experience.
JINI (Apache River) is a viable option as long as you fully understand the concepts of LookupService and service registrations, etc. There's tons of RMI going on here with possible firewall implications...
OSGI is not difficult but you may have issues deciding how to structure your applications as well as interacting with services, etc.
Try to stick to the simplest approach that you can handle for the implementation (Flexible design in mind): Make it work and then improve it.
There are simple Web Services options such as Spring Remoting (over http/https for example), unless Spring introduces too many concepts and headaches for your app.
Is there an alternative to zookeeper or doozer that are best of breed? I do not want to use java and doozer install is rather tough.
I would like a HA service in the spirit of zookeeper and doozer where machines can register there IP address and the type of server e.g. worker or web app. This will needed for zeromq where workers will need to know the servers to connect.
Thanks
You could consider zpax, it's similar to zookeeper/doozer in basic concept but it's intended for direct embedding into the target application. However, it's still pretty early in the development process. If you have the time and motivation to invest some effort in this arena, it might be worth a look.
I'm developing an app for filtering network connections from clients to my server (deny or allow to connect to my server).
I'm researching and found some resources like Windows Firewall API.
But I don't know if it's necessary for me or not.
What's the best API or solution to resolve it?
Thank so much.
regards,
Why don't you use an already-developed and proven app in the first place? If you really want to develop a filtering layer then what you need is a Filter driver and more specifically NDIS filter . A sample solution can be found here. But unless you are absolutely sure what you are doing and what you want to achieve I'd strongly suggest that you stick to an off-the-shelf solution - any firewall will be decent, or even a linux machine in front of your server with appropriate iptables rules.
Since you are working in a windows operating system. You would have to make use of Windows Filtering Platform as seen in the documentation on https://msdn.microsoft.com/en-us/library/aa366510.aspx
Drivers like TDS,LSP, and NDIS are all deprecated.
The programming language is C++. In my experience, it was a desktop application with the GUI in WxWidget and writing the filtering network connections hooks into the user mode.
There are two Filtering Layer Identifiers (Run-time Filtering Layer Identifiers and Management Filtering Layer Identifiers ), i made used of the earlier being that its more effective.
Should you need more assistance let me know.