I have a few questions about bluemix xpages runtime.
As of now (Aug 2016) Xpages NoSQL Database is still experimental. Is there an ETA for this NoSQL service to become GA ?
As of now, to have better control over performance, a separate domino server has to be provisioned to host the NSF datastore as described in https://developer.ibm.com/bluemix/2015/11/10/hybrid-xpages-applications-on-bluemix/
What are the best practices to minimize latency for the traffic between the XPages frontend and the backend server hosting the NSF datastore ? Should the domino server be hosted on IBM SoftLayer ?
Does the XPages runtime provide visibility into the network performance between the Xpages runtime and the NSF backend ?
I presume that the number of xpages runtime instances can be increased to handle increased traffic (horizontal scaling). However, the domino backend where the NSF is stored would eventually become a bottleneck, and can only be scaled by increasing the power (CPU/RAM) of the machine. (vertical scaling). Are there plans to offer Xpages NoSQL backend that can also scale horizontally?
In a hybrid bluemix xpages setup, the xpages runtime can be stood up using a custom server.id.
When the xpages runtime is scaled up by increasing the number of instances, would all the instances use the same server.id ? AFAIK, in a domino domain, each server would use a unique server.id. Should this be a cause for concern ?
Is xpages buildpack available (under some license) to be run on any other cloudfoundry instance ?
Thank you in advance for responding.
The question on NSF availability on Bluemix is better asked at the Blumix forum on ibm.com/developerworks. Or ask your IBM representative.
So far I have not seen any plan regarding such a service.
You need to look at your use case carefully:
you want to "just go to cloud": move your Domino servers to softlayer and you are done
you want to spice up your Domino applications with some Bluemix services (Watson seems popular these days): define that services in Bluemix, unbound to any runtime. They all expose https APIs. Call those from your main Domino server
You want to use Domino data in other Bluemix applications: either call DAS on your main Domino directly or, when it remains behind a (corporate) firewall use API Management and/or the secure tunnel service in Bluemix
want the performance monitoring service: if it's mainly about the traffic: use an nginx build pack (64M will do nicely) and add the service there. Will give you modern protocols and deep control what to accept/send in http. Use that as proxy in front of your Domino
need auto scale for your application: use XPages on Bluemix (note: doesn't scale database servers)
Hope that helps
As far as I know there are no plans to make the Domino database layer available on Bluemix. As a result, there are also no plans, as far as I know, to have a horizontally scaling backend. I think your concern over scalability is valid, I've not heard a reasonable answer.
For these very valid reasons I've not investigated XPages on Bluemix very deeply, as well as the fact that the Domino (data) server you use elsewhere will also have an XPages runtime, included in the cost rather than charged in addition.
In terms of communication, this is not via HTTP but via NRPC. At IBM Connect earlier this year the server guys outlined steps they were taking or had taken to further secure the NRPC communication (I believe it's pretty secure already, this was extra encryption I believe, but as a non-admin I didn't fully understand the reasons). If you look at the URL for attachments or images stored in rich text fields, for example, you'll see it uses XPiNC syntx rather than the syntax you normally get for XPages on the web.
I believe additional instances would have the same server ID. You only upload the NSF once to Bluemix, it handles the deployment to the multiple instances.
I don't think the XPages buildpack is available for other cloudfoundry instances, but I can't say for certain. I think what you currently see on Bluemix is all there is.
Related
I want to create and host 4-5 websites using the same database. The only difference between the sites will be:
branding (colours and header)
data will be filtered per website (through sql query) and
Each site will be on a separate domain (but can be hosted on same server)
My 1st thought was to use API / Rest model and provision five front-ends in their own sub-domain. But as sites can be hosted on same server (I'm assuming one hosting account which enables multiple sub-domains), I think I can simply connect all sites with connection string to same database, avoiding complexities of using REST.
Is this possible and would i run into database conflicts doing this?
If later, I wanted to add a mobile app client, then will I need to build out a rest interface anyway?
Thanks
The right thing to do here depends a lot on your specific use case, expected load, preferred backend/edge technology, future plans, etc.
Site domains and servers -
The main point here is that you can host your domains/subdomains on the same or different servers. You simply need to update the DNS to point to the correct IP (update the subdomain's A record).
Note: If these sites are all public-facing, then I highly recommend using an edge/proxy server and even consider a load balancer, depending on expected number of visitors (Nginx, or Apache Web Server)
Decoupled architecture is almost always preferred -
I would definitely have an API/REST layer to abstract the database from the sites. This ensures that you establish a contract through which any clients can interact with the backend, including your mobile application. You also don't have to duplicate DB-specific code across the various clients. What if you decided to change your schema? Or even your database solution? Then all clients will be broken and your customers would be unhappy. As a guiding principle, think: if I change any one thing in my architecture, how many other things will need to change as a result? In terms of scalability, this architecture will also allow you to easily spin up more instances of whatever it is you need (databases, REST service, etc) should the need arise.
How do I build and deploy a REST API?Re: #2, to set up a simple custom REST service running on Node.js (and express), this is a good tutorial. The example also walks through setting up and integrating with an in-memory MongoDB database.
Database collisions?If you follow the above steps, this should be a moot point. Node.js/express and the databases expose ways to configure connection pools if the defaults do not suffice. Again, this will depend on your needs - how many concurrent users you expect.
I was making a thinking exercise about how could I deploy a chat service like WhatsApp or Slack (just wondering), so people could really use it. You need two main parts, the client software (e.g. the app running on the smartphones), and the server software. So how would you develop the server-side code and make it work?
The first idea that came to me was the classic hosting service, but it cannot be the simple "web hosting service", probably because something like this should be programmed at a lower level and not working with HTTP requests and responses. Maybe using specific server-side technology like Node.js (any other suggestion?) to manage different type of requests at lower level, let's say at the layer where TCP lives, would be a better solution.
So I heard about the Amazon Web Services (AWS), which is not classic hosting, it's a cloud computing service. The problem is that I don't know exactly how this works. Could I deploy a server-side application that works at that low level of networking and also makes requests to databases? Would it be difficult to offer this kinf of service using AWS?.
I would like to hear all your opinions about any aspect of this. Would you use other kinf of technology on the server? What do you think about AWS, and if you would think it's a good option, where can I get some info to learn how to use it?
Server Side Code
You can create a chat service backend using NodeJS + express(or Hapi) to cater input Http Requests.
For Hosting: Cloud servers are pretty available these days and allow you to scale if your app grows with time.
Database:
if you already have your DB available (cool) just use ORMs ( like (Sequelize) which provides easy interaction of Nodejs service with your DB. (I have used MySQL + Sql Server + Oracle)
If not, you can create a new DB (MySql- free on your hosting server (cloud?)
I used Microsoft Azure to host a Nodejs(+ Hapi.js) Backend Service ,to be consumed by my mobile application, over the internet.
Azure gives you $200 free credit which is sufficient for you to try and make your hands dirty with them. There are numerous tutorials available for MS-Azure Api App hosting which will guide you to a successful deployment.
I have not yet explored AWS as of now, but i trust that they will be similar in their learning curves.
I'm just starting to learn more about the Node.js paradigm and finding it hard to grasp basic concepts. I'm familiar with front-end tools (HTML, CSS, JS) and have been using PHP with Apache server and mySQL db to deploy websites until now.
It seems to be that node is it's own server, and I would then need a SaaS platform like Heroku, or AWS (I'm not even sure if i'm understanding the purpose of these) if someone could explain the difference?
Is the database managed inside this service?
Is the website being hosted there?
In steps how would you get the node app to be served onto your domain name?
For Scalability purposes I understand how having dedicated big infrastructure can help, but if building a low traffic website with small number of members is there even a point in using node?
normal hosting services cost between $4-20 usd. per month and AWS or Heroku seem to start at a MUCH higher price. Is Node only to be used for large scale scaling business model?
Thank you for any answers or good recent external resources (websites or books) you could point me to.
You could easily host a low traffic website built with node.js absolutely for free on Heroku.
To see how easy that is, just go through the Getting Started With Node.js Heroku tutorial, in which you will do just that.
When you build your website with node.js, your own code that your write is the web server. You have no separate web server to configure and interact with (such as Apache). So what you see (or code...) is exactly what you get.
You will probably want to use a framework such as Express to build your web server functionality in your node.js app.
As for NoSQL databases, the way to do this on Heroku is to use an appropriate "add-on" from the Heroku Elements Marketplace. For example, you could easily add Heroku Redis or MongoLab. These are just some of the NoSQL "Database as a Service" options. That means that the Database is itself hosted somewhere in the cloud, and your app simply interacts with it. You don't need to worry about database maintenance, security upgrades etc. You just need to concentrate on your app's interaction with the DB.
Almost all add-ons in the Heroku Elements Marketplace feature a free-tier, that may suffice for your needs, at least initially. So you might be able to get your low-traffic website (including the DB) up and running completely for free, at least initially.
One thing you will need to understand is how Heroku free dyno hours work.
If you need your website to be continuously available 24/7, you may need to verify your Heroku account with a credit card (even though no charges would be incurred as long as you deploy only 1 free web dyno and are on a free-tier plan of your NoSQL DB as a Service). For further details, see this answer.
You also need to consider whether you can tolerate dyno sleeping in your low-traffic app. If not, you would need to prevent your web app from sleeping, which can also be done completely for free. For tips on how to do that see here.
As for serving your Heroku node.js app website from your own domain name, see here. Note that for this too you will need to verify your Heroku account with a credit card, although this too does not incur any charges.
Node.js is supported by many web hosting already, especially for those who use Plesk or cPanel as their web hosting control panel. Here is guide about how to setup a Node.js website via Plesk control, https://www.bisend.com/blog/how-to-set-up-a-node-js-site-in-plesk. As you said, it's very easy to host your website with a cheap shared web hosting.
Am I correct in the assumption that without access to the MongoDB server, there is not much point developing with Meteor?
Meteor is a great framework for building, packaging and deploy apps and sites. From a development POV, the templating and responsive DB work make prototyping so much easier than most MVC's.
I understand that underneath the hood, websockets and DDP provide the realtime sync'ing magic which means that you need access to the MongoDB server, something you don't have with PaaS solutions like GoogleAppEngine, Parse or Kinvey.
So, for the backend developer, they don't derive much benefit from Meteor since they need to maintain the server stack and scalability issues.
Is there a path to create and deploy products with Meteor without having to build and maintain the backend infrastructure? Heroku is still pretty close to the bone when it comes to managing infrastructure.
Wondering if there's a way to have CRUD operations through a REST driver that maps out to whatever PaaS you want and have the PaaS post log changes to a server that strictly handles websocket connections. Basically, pass the CRUD operation to a PaaS and maintain your own websocket server/s.
MeteorPedia has a page on deploying to PaaS: http://www.meteorpedia.com/read/Category:PaaS_providers
Recently, Google AppEngine has added support for custom VMs.
You can also use MongoHQ or similar for the database.
I am currently devising 3 database desktop applications for different users in a manufacturing company (one for the accounting department, sales department, production department). All applications have different functions but they should be able to access the data of the other department to reflect business transactions. What is the best programming language and database to use for this kind project? The three computers are not physically connected so I was thinking of having them to access a remote database. The language I am most familiar with is Java but I am very open to learning others if it would be more beneficial to the company. I was also thinking of having to use Adobe Air as I am adept with web programming but could still run as a desktop app but I can't seem to find sufficient resources of distributed systems using Adobe air. Any ideas would be very much appreciated. Thanks!
Lots of languages will do this just fine, including Java. You're familiar with that so my advice is stick to it with one caveat: depending on your requirements I would seriously suggest examining the possibility of making it a Web app instead. Desktop database apps are somewhat... old-fashioned. More to the point they'll create a bunch of headaches for you such as installation, Swing is annoying and tedious, etc.
As for what database, barring requirements you haven't specified, anything will do so pick something free like MySQL.
So for a desktop Java app I would:
Put the database on a remote server;
Put an application server or Web container on that same server;
Create a Webapp on the app server for handling RPC;
Pick a method of RPC, be it Web services or whatever, and use Spring to implement it;
Create a desktop Java app in Swing and distribute it to clients from the app server via Webstart (JNLP).
If it's a Web app:
Put the database and appserver or Web container on one server;
Pick a Java Web framework and create a bunch of Web pages that do what you want.
In all cases, have it be the same app but just act differently on the user type. This is much better than maintaining three different apps.
Also if you do a Web app, you might want to consider using PHP as it's a fast and proven way of knocking up Web pages and probably sufficient for the kind of internal application that you're doing.