I've started my journey with cloud related technologies very recently. I'm trying to understand the basics as to be able to prepare the foundation for a basic cloud setup in my Internet of Things oriented company.
While browsing the Internet I've stumbled upon the following two groups of open source projects:
WSO2 / Mule / ...
OpenStack / CouldStack / Eucalyptus / ...
I'm trying to understand:
what kind of service do they offer? (IaaS, PaaS, SaaS, other?)
what are the differences between them?
what do they have in common?
how do the play with other cloud related technologies like Amazon AWS?
which one would you recommend to get some basic experience and for some early proof-of-concept? (I'm looking for the easiest option first)
Cloud stack and Open stack are open source softwares designed to manage, deploy virtual machines and networks which can deliver cloud services. Mainly these provide Infrastructure as a Service (IaaS). There are alot of comparisons on the internet on these two. So these softwares needs to be intalled on your hardware and maintain it and you provide a cloud service from it. When it comes Amazon AWS it is a readily available service where you don't do installations or maintain hardware, you just take service from them.
WSO2 and MuleSoft are different from above two and they are software platforms where several products(such as ESB). Both provide cloud platform facilities to deploye their products.
We cannot say which one to use but base on your requirements you may choose one or two (WSO2 products deployed on Amazon AWS or WSO2 products deployed on CloudStack VM's). Since you are willing to set up Internet of things, i think you may need to refer about products provided by above providers. Following source [1] will give you an idea about Iot platform setup by several free open source WSO2 products.
[1] http://wso2.com/landing/internet-of-things/
Related
When you have so many services, let's say more than 50 services and you want to know the relation between services, for instance you want to know which services have hard dependency on each other and which have soft dependency on each other, meaning when a service goes down and doesn't function anymore which other services will not work.
Basically for providing a level of High availability and uptime (SLA) we also need this.
and also when a new person joins the team there should be some kind of documentation to see what services we have and how is the dependency tree.
what kind of relation they have ? just messaging through a message broker or direct requests ?
Are those services working in just test environment or prod environment ? or both ?
What tools and softwares are there to help us cover this.
I am just now also looking into this question. Especially modelling dependencies between services.
In my opinion you can go into two directions
Service Registry
Configuration Management DB
There are a lot of full blown Service Registries out there, which do are not only static documentation, but services als register themselves with the service registry and others can discover the service to user there automatically.
Eureka related to Netflix Open Source Stack (Netflix OSS)
Consul
Zookeeper
Etcd
For me the Service Registry option might be to complex and I am going into the the direction of a simple CMBD
Can we deploy QlikSense/QlikView on serverless architecture?
Currently using Monolithic architecture, any other way to move on to serverless?
While I am not familiar with Qlik's products, it is unlikely they would be suitable for serverless architecture.
Companies generally offer the products either as:
Downloadable products that you run on your own server (which could be a virtual server in the cloud), or
Software-as-a-Service, where you access their website directly and no server is required (eg Salesforce)
"Serverless architecture" is a design decision that can be made when designing a software product. It means the the application is broken-down into small components ('microservices') that can be run on services like AWS Lambda, with no actual server.
However, such architecture would normally only be used for your own applications that you create. If another company has designed their system to be 'serverless', then they would normally run it on a cloud system (eg AWS) and offer it to users as Software-as-a-Service. It would be highly unusual to have a 'download' product that runs on a serverless architecture.
I notice that Qlik has product offerings that run on AWS (AWS Marketplace: Qlik), which runs on an Amazon EC2 instance, rather than serverless.
If you look into the Qlik Core product then yes Qlik can be deployed on an elastic containerised enviroment. But then as I understand it you don't get the standard objects and visualisations, user management etc. So you have to code your own stuff that ties into the Qlik Data Analytics Engine via apis.
From https://core.qlik.com/why-qlik-core/
So, how do you get it? Licensing info here but let’s talk components
Linux-based Associative Engine – provided as a Docker image with built-in support for Amazon Web Services, Microsoft Azure and Google Cloud Platform
Supporting APIs – these ingest your data into the Qlik Associative Engine through connectors
Supporting Open Source Libraries – these various libraries by Qlik expose the engine to help you build solutions faster
It’s all language agnostic but JavaScript lovers will find it easier to work with given the number of our open source tools available in JavaScript. Other top languages and tools used include R, Go, Shell, C#, Python, Java and D3. Qlik Core can also be managed with the orchestration tool of your choice for implementing, scaling and managing containerized applications.
It really depends on what exactly are you building. As The Budac mentioned you can use Qlik Core
If you just want invoke Qlik API (for example some automation jobs) then serverless functions are making sense.
Qlik Sense (both Enterprise and Kubernetes versions) expose a lot more different API which can be called from technically everywhere.
QlikView on the other hand is more ... conservative. QV is an older software and the API/integrations are more limited. For example: to call the Management API you have to be on the same domain as QV. Personally I've only connected to QV Management API only with C# and pretty sure you cant use JS/Node
I'm looking at building a new service discovery platform to allow our customers to provide plugins to our platform. I know that UDDI was the technology "du jour" a while ago, however, in doing some research it appears that UUDI is falling out of favour with people. What are you using for service discovery these days? What would you like to use given the chance?
These days API Gateways are becoming popular choice for Sharing API & related documents along with. As far service discovery is concerned specific vendors have their own implementation as well such as Oracle API Catalog.
Why would anyone use WSO2 Application Server instead of other application servers?
I rather encountered only problems with it, mainly due to class loading issues, so I would appreciate if someone could point out what are the advantages or the use cases when using WSO2-AS really makes a difference.
I can see the benefits of other standalone WSO2 products, but as far as the AS is concerned, I would rather rely on more lightweight servers and just package the libraries I need.
There are number of advantages on WSO2 Application Server.
1.) It provides in-built support for multi-tenancy, in case if you have isolated departments like organization there is no real need to have number of server instances you could simply create a new tenant.
2.) Automatic lazy loading support for tenants, web applications and web services. In a production system a particular tenant/web application/web service can be ideal for sometime it's a waste to allocate hardware resources continuously to such ideal applications specially if you use IaaS. WSO2 application server can detect such ideal tenant/web application/web service and release their resources and tenant/web application/web service will load again when a new request dispatch to the particular tenant/web application/web service.
3.) Wide range of deployment options, support to deploy on-premise, public or private IaaS , public or private PassS such as Apache Stratos. An an example one can deploy his application into WSO2 App Cloud (http://wso2.com/cloud/app-cloud/) instantly without downloading anything, later he can get same experience one of above platforms.
4.) Deployment synchronization feature, a clustered environment you may have very large number of nodes and upgrading application version and configuration changes across the cluster can be headache. Using Deployment synchronization feature you can modify only one node labeled as manger node and Deployment synchronization will take care about synchronize changes across the cluster automatically and consistently.
5.) When developing applications on WSO2 Application Server you can leverage carbon platform level features such as identity, registry, logging, distributed caching, multi-tenancy etc. As an example one can use identity features provided by the platform to mange users, roles permissions also for authentication and authorization without write something own.
6.) Inbuilt support for security standards such SSO among other WSO2 products.
7.) In-build monitoring capability for web services and web application through WSO2 BAM.
8.) Enhanced and rich dashboard for applications and services which facilitate to basic statistics, application management, security wizards, code generations, Try -It tools, run time logging configurations etc.
9.) Enhanced classloading mechanism (starting from AS 5.1.0), within one Application server instance you can have number of virtual server environments per application level. As an example one can specify an application run on minimal Tomcat mode or can assign to run Carbon mode which is ( Tomcat + Carbon platform).
When it come to your specific issue if you can specify your Application Server version and elaborate more on your classloading issue I can provide you more specific answer.
Having said above I want to mention that I'm from WSO2.
I'm trying to install and configure a highly availability setup for the WSO2 API Manager. I've been reading through this document: http://docs.wso2.org/wiki/display/Cluster/Clustering+API+Manager and in there it explains to break up the 4 components of the application into separate folders and that these 4 components can run on a single server. I'm not sure why this is needed. All I really want to do is take 2 servers, install the full application on both of them (without breaking the application up into 4 different pieces) and cluster them together between two servers with an Elastic Load Balancer in front of them.
What is the purpose of splitting up the multiple components on the same server if they all run out of a single installation? I'm looking for the simplest way to provide fail over capability to this application if one server goes down. Any insight into their methodology would be greatly appreciated.
Thanks.
The article you've linked describes on distributing different components of API Manager. If you look at the very end of that article there's a link to clustering configuration doc. In a production deployment usually it is encouraged that the 4 components are run on different nodes rather than having everything in a node and having multiple such nodes. That's why it goes on explaining breaking it down to separate components. The official AM doc below has a page on different deployment patterns.
You can go through the following articles to get a better understanding on clustering API Manager.
http://docs.wso2.org/wiki/display/AM140/Clustered+Deployment
http://sanjeewamalalgoda.blogspot.com/2012/09/how-do-clustering-and-enable-replicate.html
My 2cts:
The documentation mentioned in the remarks, explains how WSO2 sees the world of clustering. Spread the different functionality over different JVM's. This sounds logical from architectural point of view. A dis-advantages is that the diffent applications need to me administrated as well by operations. This makes the technical architecture rather complex.
In our situation, we defined 2 different servers with extra CPU and memory, on these servers we have installed the full WSO2 API Manager and defined the cluster configuration. Everything provisioned via Puppet.
Just a straightforward install, all data-source pointing to one schema in an Oracle database.
And...it is working; Our Developers happy, Operations happy, Architect department happy