Feature Request : Web Console

[Cragdoo]

I'm sure this isn't the 1st, and definitely wont be the last, post requesting a web (html) console but thought it deserves another discussion. At the moment tone option for web based access is via Enterprise Manager. While this is a useful tool, it is geared more around the self-serve restore functions with limited job management. There is also the upcoming Veeam Availability Console (VAC) , which appears to be gear more towards pure management (at this stage anyway, that may change). Sure we have remote console introduce in V9, but that still requires the installation of an application. What I guess people are asking for is the best of all those products in a nice shiny HTML5 console that us nice backup admins can access from any browser/device. Having used the VAC console, this is very much a step in the right direction.

Are there any plans to develop this further to add extra functionality?

Now being needy IT people, once this 'need' has been addressed ..can we add VeeamOne console into the mix, for a truly 'one pane of glass' (should that be one glass of pain??) solution.

I await the inevitable smack down

p.s. btw ...k00laidit made me write this

[mcrape]

I would also love to see a html5 / mobile friendly interface. Being in a smaller environment with limited resources,I tend to be "always on". It isn't uncommon for me to need to do basic Veeam-related tasks while away from a computer. An example would be a backup copy job to rotated media. If the job fails (drive missing or full), I tend to get lots of alerts. In the past I have had to use RDP from my phone to disable the job until I get back into the office - a simple task that can take a few minutes (waiting for RDP connections, logging in, resizing, etc.). A mobile-friendly / HTMl5 option would be great.

[k00laid]

I regret nothing.

I will absolutely second this. As a Veeam Availability Suite Admin to do normal functions I already have to work with the VBR console, Veeam ONE Monitor at a bare minimum, with various auxiliary web interfaces that are not cross linked to do further reporting and management. Throw Agent management into the mix and the sheer number of GUIs you need to familiarize yourself with in order to work just with Veeam is pretty daunting.

A web console for the entirety of VAS is IMHO the answer going forward. VAC is nice, but onboarding as an end customer of any size is pretty un-natural with the need to setup Cloud Gateways and such just to get started. Possibly if you could split the onboarding process, one for SP and one for enterprise based on licensing this would be a good solution, but you still need to bring ONE into the fold somehow.

[mwpreston]

Not to ask for the world buuuut..... maybe a possibility of having an API endpoint built around it as well? Currently our automation around deploying VMs assigns a vSphere tag to the given VM in order to have it included in a backup job which is great but I'm still forced to invoke PowerShell to perform other Veeam related activities to the VM (IE disk exclusions, VSS credentials, etc). This works however passing back return values and error messages to the initial workflow (which isn't in PoweShell) gets messy at times.

Perhaps an HTML 5 console like this could be delivered on a separate release cycle than VBR as well - somewhat similar to how VMware is handling the vSpher Client. Building basic functionality to get it off the ground and releasing updates as they are built. An unsupported Veeam Fling if you will?

That said I get that this would be a lot of work and don't claim to know how to best manage developers time . Just my thoughts.

Keep up the great work!

[Vitaliy S.]

Are there any plans to develop this further to add extra functionality?

That's the direction we definitely want to move to, so bringing more scenarios and use cases would be helpful. No solid plans or ETA at the moment though.

]Having used the VAC console, this is very much a step in the right direction.

Good to hear!

maybe a possibility of having an API endpoint built around it as well? Currently our automation around deploying VMs assigns a vSphere tag to the given VM in order to have it included in a backup job which is great but I'm still forced to invoke PowerShell to perform other Veeam related activities to the VM (IE disk exclusions, VSS credentials, etc). This works however passing back return values and error messages to the initial workflow (which isn't in PoweShell) gets messy at times.

This potentially can be addressed by Veeam Availability Orchestrator, which now orchestrates VM failover operations, but as far as I know there is a lot to come later.

[CloudMSP]

Please do NOT do this, every attempt to switch from a solid application to a damn web interface has always resulted in a far worse experience.

[Delo123]

Please please please do not NOT NOT NOT do this. Look at the Vmware client disaster (and every other vendor), NO. Anyone not able to remotly access their server has bigger issues. PLEASE NO!

[mkretzer]

DO NOT DO THIS PLEASE! Web Clients as a add-on are great, as a primary interface they are often unusable!

[Cragdoo]

Please do NOT do this, every attempt to switch from a solid application to a damn web interface has always resulted in a far worse experience.

I'd disagree and I'll refer you to the VMware web client as a great example of how to handle the migration. The fact that VMware allowed you the choice of the C# client while the were developing the web client should really help people wean themselves onto a new client.

[nielsengelen]

Web clients is a quite new thing to be honest. Years ago there were a few companies who tried to create web client as the new thing but failed in doing so. This is mostly due the fact that back then the frameworks as we know them now didn't exist. This resulted in every action being a new page and a new call. Companies then left the idea and went for hard clients (such as vSphere Client as an example here). Keep in mind that this means another service (or multiple) needs to be monitored and up and running all the time.

Over time things have changed and the 'web' improved a lot. Things got more fluent and 'snappy' with the perfect example being Facebook, LinkedIn and Twitter (social media). While these aren't apps they are a perfect example how smooth things can be.

VMware felt the need to try it again but made the initial wrong choice of going for flash compared to HTML5, javascript & CSS (such as AngularJS, bootstrap, ReactJS,... plenty of choice there is). They failed by doing so and the first few web clients were unusable and sadly due to this many people still refuse to use the web client. However VMware made the wise choice to switch to HTML5 thanks to the success of their fling. If you look at how good the web client has become in 6.5 it's a perfect example on how to do it correctly. The bigger problem I see with the way VMware handled things is the full redesign of their client. I've spoken quite some people about it (in regards to getting feedback how we should do it ) and many feel they are 'lost' and the learning curve is 'high'. Of course this is also due to the fact that the fat client has been along for quite a while so this is just a matter of time.

While I can't say where Veeam is going I can give my personal opinion on how things are changing.

The first example (as Craig mentioned) is the Veeam Availability Console. This is a full HTML5 management web interface which comes with a RESTful API meaning you can make your own interface if you don't like ours but it also allows you to integrate certain aspects within your own portals.
The second example is the upcoming Veeam Backup for Office 365 1.5 release (currently in BETA) which has exactly the same options. It comes with a RESTful API making sure you can do pretty much all the calls you can do via the fat client via REST. This allows us to integrate with portals or create an own design (which I am working on as an example - keep an eye at https://github.com/nielsengelen/vbo365).

For those who are saying 'no don't do it' in this thread; my question is simple. Why wouldn't we open up with a REST api allowing people to create a HTML5 interface? Is this due to the VMware example?

For those who says 'yes go for it': which are things you would like to see in it? Keep in mind that doing a full switch with 1 release isn't feasible so this would be step by step.

Also I am not a developer nor in product management but I am all up for the idea of 'Veeam flings' to help demands.

[mkretzer]

I'd disagree and I'll refer you to the VMware web client as a great example of how to handle the migration. The fact that VMware allowed you the choice of the C# client while the were developing the web client should really help people wean themselves onto a new client.

Are you serious? The fact that they still require the terrible, slow flash client if you want all features to work is frankly a desaster. Furthermore, in medium sized environments as ours is (~2000 VMs) C# client is still much faster than HTML5...

[Gostev]

I have to agree with mkretzer on performance and usability of vSphere Web Client in large infrastructures such as our QC labs...

I am likewise skeptical about web interfaces for now... mostly because I am yet to see an example of successful migration of an enterprise management UI into a web application. However, we're certainly not opposed to the whole idea. This is something that is on the table, although definitely not as a replacement for the existing UI - but rather as an alternative.

[Cragdoo]

yes an alternative would be preferable, compared to an alternative. As I've said having used the VAC HTML interface, definitely a step in the right direction. Maybe I should have been a little clearer in my use of the VMware HTML fling (and not the Web client, my mistake ..apologies) as an example. I was meaning more along the lines of the way they have slowly introduced the functionality as opposed to the big bang approach.

Enterprise Manager is good for restore operations and VAC for the management of jobs. Just need to combine the 2

[dellock6]

"IF" the final result is a fast, reliable and usable interface, would you really care if it's web-based or client-based?
I'm more practical, and I just want something that is easy (thus efficient) to use. And, if performance and user experience are comparable, a web UI is totally preferred, since I don't need to install or update any client, my list of compatible devices is as huge as my HTML code is not "infected" by custom code (html5 is not just fancy, it's the broadest option we have so far). I've seen many solutions using web UI with no issues at all, usually, this is a problem (like VMware) where there's a history of a good installable client. I'd guess what would be the opinion of a new VMware admin using 6.5 with its HTML interface for the first time, he would not even care about the C# client probably...

Oh, and back to the original request, with an installable client, now we would need to have TWO different clients to maintain anyway, one for windows and one for mobile phones. And which phones? iOS, Android... So it's probably three clients. And no client for Linux, or Mac? With HTML, again, you only need one client.

[mkretzer]

Oh, and back to the original request, with an installable client, now we would need to have TWO different clients to maintain anyway, one for windows and one for mobile phones. And which phones? iOS, Android... So it's probably three clients. And no client for Linux, or Mac? With HTML, again, you only need one client.

The thing is: Even VMware is doing a seperate mobile App for VSphere - because HTML5 does not really scale well to the small screen (so it seems).

I really find it confusing that companies go away from "fat clients" on the PC but at the same time start creating "fat apps".
People seem to want Apps. So why not keep the fat clients?

I see only one reason not to: MacOS and Linux/ChromeOS.

[smoore33]

+1 for please do not do this, for the reasons already mentioned! Just say no! Please!

[oscaru]

Wmvare 6.5 html client has improved a lot, and performs well.
Having an alternative html UI would be great for admins using OS different than Windows, like MacOS or Linux

[HannesK]

+1 against HTML only

I talked to some QA guys from a software company that is currently migrating to HTML5 and they told me that it is "a mess". From their perspective it is easier to develop fat UI for different operating systems instead of browsers that follow no standards (HTML5 is not a real standard, it just looks like a "standard").

In general, you need really fast CPU, so it will not work on old devices. They say that Chrome usually works. Firefox ESR is okay, all other Firefox versions unsupportable. Microsoft Edge does not have all features yet and it is a mess to test because you have to install tons of OS versions as you cannot install Edge in different versions. Internet Explorer does not support latest features of HTML5 and will never do (Edge will do that). Safari is the "new IE" - it just breaks everything. Although on iOS everything should be rendered by Safari engine, this does not guarantee that it looks the same in Chrome, Firefox and Safari on iOS. Simulations have to be done on real devices of different generations, screen resolutions etc. because simulations are not reliable. Android: same story. Ah, and don't forget Window laptops with touch-displays. They behave different than non-touch devices.

Yes, they will be able to do it but they will need many more resources than today (and they don't have 250k customers).

If they succeed, their customers will be happy because from a customer perspective HTML is really cool. If they fail, well, see VMware...

[Cragdoo]

+1 against HTML only

Don't think I've mentioned HTML only, but as an alternative

So now that VMware has announced the end of the Web client, effectively forcing everyone to use the HTML client in future, will Veeam be re-writing their vCenter plugin to integrate into the HTML client? ..if so then next logical step is their own HTML client ...I jest

[Gostev]

will Veeam be re-writing their vCenter plugin to integrate into the HTML client?

Yes, in fact the work has already started.

[hyvokar]

I'd disagree and I'll refer you to the VMware web client as a great example of how to handle the migration. The fact that VMware allowed you the choice of the C# client while the were developing the web client should really help people wean themselves onto a new client.

You are kidding, right? I mean, vmware has been building their web client for over 3 years now, and it still doesn't work. And none knows, which version of host client / web (flash/html5) client / browser they should be using (it really does not matter, since now you will be needing thick client, web client AND powershell cli/ssh to get things done). Check https://communities.vmware.com/thread/477686 to see, how happy people are with web client.


So +1 for veeam NEVER going for the web client.

[rawtaz]

+1 for a web based API to support a HTML5 client, assuming it is done properly (but that's pretty much a given expectation, why would anyone ask for a badly designed or non-working HTML5 client).

There seems to be a lot of FUD regarding HTML5 in this thread. I'm not sure everyone in this thread understands how well a HTML5 based interface can work. Probably due to having been exposed to bad ones. Of course, it's just not HTML5 we're discussing here (also JS,CSS and the backend stuff), but for sake of brevity let's continue to use that word alone.

Regarding the VMware thing though; You cannot blame HTML5 for what VMware did. Their failure is based on two things; 1) their initial decision to replace the vSphere Client with a Flash based client (this was about the most stupid thing they could have done, and in light of what any web developer would have told them, had they just asked, it's even more silly), 2) their incompetence or lack of effort (you decide which) to make the client better during the time it's been out there.

By #2 I mean that if they just wanted to, they could fix the issues in it rather swiftly and release a client that works well and has the features people are annoyed with the lack of. They seem to be getting there, but it's not a matter of whether "HTML5" can do it, it's about VMware just getting it done. Just because they didn't do it right, doesn't mean it can't be done right.

I've been developing web based applications for more years than I can remember, and I can definitely tell you that HTML5 and related technologies is perfectly capable of providing a well designed, highly usable and user friendly interface even for Veeam stuff. It's just about doing it right. If there's a problem here, it's not the technology.

Regarding the development of it, sure, there's sometimes a lot of headaches due to this and that browser (they all have their pros and cons), but in general HTML5 has been around for so long now, that all or most of the things you need to build this type of client is there and supported by the browsers that are relevant for this discussion. It's possible the effort needed to produce this client compared to one that is more platform specific is greater though, as there are more parts involved to get right.

Someone mentioned CPU load, but this isn't really rocket science - the frontend we're talking about here isn't going to do a ton of processing. None of what it needs to do is CPU intensive enough to be a problem AFAIK. And sure, there can in some cases be a bit of network delays, but as long as you're not on a slow connection it should just be fine. Just think about how much actual data needs to be transported to your UI, in the cases where there's the most going on in the current client - not very much at all.

One thing I would appreciate is if we could get to a point where we don't need Windows systems just to run Veeam. But that's probably a bit far away, since even if we get a web GUI, there's still the actual backup controller, proxy, etc that has to be run on Windows. So from that perspective, my personal use case for a HTML5 client is rather limited. What I need to do I can do in a Windows client, since I have to have Windows set up for Veeam anyway :/

If there's a HTML5 client created, then heck yes, it definitely should be working through an API that other people can build stuff around if they want! That's one of the pros with this type of solution. So perhaps, as some people here seemed to suggest, the best way forward into HTML5 land is to simply provide that API, so the community might start writing som stuff around it, showing the way to what might later become a design and feature set in the final client.

Also, make the things open source so people can contribute.

[nitramd]

What's with the hatred of a web/HTML5 client? Is the impiication that Veeam would produce an equally crappy product given VMware's experience? I think not!

We can accomplish amazing things with a web browser on a smartphone or tablet.

Here's a +1 for a well thought out/designed Veeam HTML5 client as an alternate to the current PC only client.

[mkretzer]

@nitramd If that is so why so many companies provide a "fat" app on Android and IOS (for example VMware watchlist which is really good)?

[nitramd]

@mkretzer, it's really quite simple. Taking Apple as an example, in 2015 the App Store took in total revenue of $20 billion with developers taking in ~$14 billion while Apple took in ~$6 billion. For 2016, the App Store's total revenue was more than $28 billion with ~$8.5 billion going to Apple and almost $20 billion going to developers.

With this economic model, clearly there's a lot of money to be made selling "fat apps". I would posit that there's nowhere near that amount of revenue generated by using a web browser, i.e. Apple would not be making revenue from a service provided.

[tdewin]

Well one thing about those phone apps is that they can be used offline (e.g most of the time, this is actually the paying part of the app). Also by making an app, you can cache a lot of data so you don't need to re-download all the pictures all the times (or cache other data)

We are talking about managing B&R so by default, you would need be able to be connected. Probably you will be working from a fixed station where bandwidth is less an issue.

And finally it doesn't mean that if you are designing an HTML5 client, it HAS to support running it on a phone or tablet or whatever. It is of course something to consider. I think rawtaz nailed it here. If we would start with a good Rest API, then who knows what the community could build. Building a limited app for smartphone, would certainly be something we could do. Imagine being able to just check on your jobs and restarting them from the bar (hopefully not to drunk). I even considered building this on top of VAC. BTW all those phone apps, how do you think they communicate with mother ship to get the latest data?

I love this discussion because it shows a versatile set of opinions, not only among the end-users but also between Veeam employees

[Didi7]

Agreed, the VMware vSphere Client is still not fully equipped with all features the vSphere Web Client offers, but it develops very well. Using Chrome in combination with the HTML5 vSphere Client is ok and in our enviroment with 15 locations (and same amount of data centers) and more to come, performs very well, but VMware should push development much more, as promised on last years VMworld. Adobe Flash Player (necessary for the vSphere Web Client) is a no go, specially since this plugin tends to crash from time to time.

Using the VMware Fling version of the vSphere Client, you don't need to wait for new developments coming up with new vSphere releases ...

https://labs.vmware.com/flings

Therefore, I am not against a web console for Veeam B&R at all, if it's speedy enough

Regards,
Didi7

[nitramd]

@tdewin, I should have mentioned that I would want to use a smartphone or tablet in place of laptop especially when offsite; on a phone/tablet, I would rather use a browser than yet another app. Is it possible to use a browser to manage B&R? I don't know but I would expect that the smart people Veeam should be able to figure that out My apologies for the lack of clarity.

@Didi7, I've just started using the Opera browser after being disgusted with Edge, Firefox, and Chrome - so far so good with Opera, much less heartburn. Thanks very much for the information regarding the Fling I'll have to try it out.

-nitramd

[rawtaz]

I just noticed that there's a subforum named RESTful API, then I found the reference for it as well. I had no idea! Not sure if this is only available in the Enterprise version? Nonetheless, seems like there's already a starting point on the topic we're discussing here

[nielsengelen]

The current Restful api only allows you to do things that can be done in the Enterprise manager. Not the full console hence this thread started to create a full blown API .