Our way to rethink PaaS with devops automation | Hacker News Reader

Our way to rethink PaaS with devops automation

visualops.io

34 pointstbronchain58 comments

An interesting approach; I'm however skeptic as to how well DevOps lends itself to be visualized. And even if the techniques and products do now, futures ones may not, or require a lot of work to bring into this.

>VisualOps is created with a goal of both "easy to understand" and "total control".

I don't know, this seems almost too ambitious to me. I'm wary of car analogies, but alas: While everyone can drive a car, does this yet qualify as "total control"? Assuming I'd like to control everything about my engine - resulting in a shitload of controls on my dashboard, is that car still easy to understand (to me yes, to my mum, - or a newcomer for that matter - doubtfully so)? And by hiding the additional controls behind a "ADVANCED CONTROLS" cover kinda defeats the "easy to understand" part, how soon until HOWTO's appear whose first instruction is to lift said cover?

I'm sure there are boatloads of loopholes in my analogy, but you get the general idea. Not really sold on the concept, but if somebody can offer insightful comments, I might be convinced. Not easily though.

>Complicated data format Even if someone hacked into our servers, took a copy of the data, stole our soure code or laptop, they still cannot get your information.

Remove this sentence ASAP. It's an insult to everyone with at least a basic grasp on good IT and security principles. wtf; just because it's supposedly complicated a determined adversary cannot break the code?

Hi Roeme, thank you for your comment!

>VisualOps is created with a goal of both "easy to understand" and "total control".

We tried or best to associate the easy understanding to full control. I totally understand your point, and this is the idea behind VisualOps: you need to deal with complicated tools if you want to get total control (eg. Chef with OpsWorks), or you need to make some concessions if you want something easy (eg. PaaS platforms like Heroku).

With VisualOps, you have a total control of your instances software configuration, as well as the "hardware"/"network" specifications available by AWS.

>Complicated data format Even if someone hacked into our servers, took a copy of the data, stole our source code or laptop, they still cannot get your information.

I think there is a confusion there. What we meant is that the AWS credentials are store on specific servers, which are not accessible by the employees here. These credentials aren't accessible using data stored on employees computers or internal git repos Thanks for telling us, we will modify this sentence, and sorry for the confusion.

I missed that sentence, but agreed that it should be removed. I don't think "complicated data format" is a good selling point. Quite the opposite really.

Hi Michael, We are not sure what you means by "I don't think "complicated data format" is a good selling point.", could you tell us more? Thanks!

The FAQ suggests that the fact you use a complicated data format is a good thing and beneficial to security. I really doubt this is true.

Right, we have modified this part. By "complicated data format", we actually meant strong encryption algorithm. Sorry for the confusion.

Reading this, and skimming over your other comments I suspect that english isn't really your first or second language...consider asking a friend with a english cert above FCE level to help you out with translations. No need for a professional service, but a wee bit better than currently might help you.

Because...between "complicated data format" and "strong encryption algorithm", there are not just worlds, but universes. Subsequently, this correction also sounds suspicious to somebody who assumes you are fluent in english (or is used to it).

We'll do, thanks for the advice :)

There's a ton of software that's been built to do a lot of this in the really unsexy / "not very hot at all" enterprise software space with the sticker label of cloud provisioning / application deployment automation where everyone has spent a long time trying to visualize deploying groups of machines out to suit their oftentimes not very technical stakeholders (yes, DC managers that aren't actually that technical is extremely common in the Fortune 500). Examples: VMware vCloud Director + VCOps + Orchestrator, CA's AppLogic, and even HP's Cloud Service Automation. All of these are directly in the value proposition category of "automate your provisioning and monitoring / ops of your systems." Almost all of them involve some form of a visual programming language with drag 'n drop capabilities just the same as your UI shows and with the usual hallmarks of small DSLs that creep into the components.

I have to ask where you guys think you fit into the market between start-up style home-grown devops stacks (expensive in labor and time instead of capex) and these 7-figure products (capex-heavy, but OOTB solution in theory) when so much has already been done and acquired away by pretty much every large software vendor.

I agree the concept isn't totally new, and has been seen somewhere else. However, despite of various feature differences, we think we made the efforts to distinguish ourselves in two parts: 1. we try very hard to simply the process to define a complex, multi-tier template; 2. VisualOps is a service, not an editor or designing tool. we continuously managed your app once launched to make sure it runs in the defined state.

Isn't this whole approach based on the (imho wrong) idea that "DevOps" means developers [trying] to manage servers/infra?

IMO DevOps is about smarter Ops using "development" (i.e. automation, reproducible system config systems) rather than ad-hoc management of individual servers.

To me this reminds me a lot of some MongoDB fans - they have no real need for Mongo, they just don't want/know how to define a usable schema for a relational DB.

Hi Stephen, Very interesting comment here. We do think that DevOps has different definitions, and in our opinion, none is really wrong, as all comes back to the same idea. Let me explain this. DevOps is all about reducing the gap between development and operations. This is done allowing "smarter ops" to use "development", but also helping developers to realise some operations. VisualOps is made for both sides. We hope that VisualOps could help developers who don't want to spend too much time on operations, but also, we created VisualOps to act like a programmable configuration manager (like Chef, Puppet ...).

I understand your point but personally a developer who wants more control over operations, but isn't able/willing to learn to write recipies/config packages/what-have-you and relies on a visual tool like this is going to raise alarm bells for me.

A developer relying on (current) visual tools isn't really a developer to me anyway. But I'm totally willing to give in here; the idea of visual programming has been around longer than me (search wikipedia for a start), and let's not forget that in digital circuitry visual tools are used (and are of use) a lot.

Indeed! Visual tools makes the approach more "human". Simplified tools don't mean dummy tools. It's actually the total opposite: a developer forced to do deal with Ops is less likely to do some mistakes using a simpler tool, than trying to deal that things that he doesn't (and doesn't want to) understand. I understand the other point of view, that we better start by learning the most complicated things (I've started to learn programming with C and ASM, although I'm a 90s guy), and the whole challenge we have with VisualOps is to make the learning and usage easier, without breaking the knowledge.

IMO the idea is about the capability of "automation, reproducible system config systems", not who should do what.

I agree with the first part but the last part (who should do what) is still relevant.

The majority of developers I have met and worked with have a cursory knowledge of infrastructure/server management at best. That is not a criticism against them at all. But I still wouldn't trust most of them to configure infrastructure outside a local/dev/"sandbox" environment.

You wouldn't rely on a HTML template file that your graphic designer created with Photoshop -> Export to Dreamweaver would you?

No. But that's a problem to be solved with how we leverage the tool, not the tool itself.

Right, but as I said in the other thread - if someone wants to work in Ops/Ops-ish, but can't learn a recipe/packaging system, I doubt a GUI tool is going to improve the results.

Hi Stephen. We understand your opinion, as I replied to someone else before, there are different ways to take the problem, and one of our biggest challenge is to make the learning easier without breaking the knowledge. I would just add that VisualOps isn't just a GUI tool. We have spent a lot of time to adapt SaltStack source code to something we think to be the right approach. Also, more features are on the way, and we count on your support to bring them to life! Check out our public roadmap board for more details (you're welcome to vote for your favorite ones): https://trello.com/b/wQdmsmp0/madeira-idea

Makes me think of https://jujucharms.com/

Similar by some means, from my point, visualops.io is closer to AWS VPC resources.

founder here. Yes, the UI looks similar. However VisualOps is not an editor to create your app, it continuously manages the apps to make sure they runs in the desired state.

I am a developer who needs to do AWS sysadmin sometimes and does not have the time to learn Chef, Puppet, etc. So I think I am a target user and I like the concept. I tried it and find it very hard to use.

* Hints or error messages appear in the top banner. This is not obvious. If you moved the messages closer to where I am looking, that would be more helpful. You could simply move the message to the middle of the screen or in some cases pop-up a tooltip next to the component that has the error or hint. It also does not help that the news banner is a similar color to the error message box.

* It is not clear what the blue, green, etc arrows and squares mean. I tried hovering to see if a tooltip appeared with a short description but none did. I think the blue arrows are for networking, but not totally sure.

* I have no clue how to connect any of my instances to the public internet gateway or even if I can. I tried connecting an instance directly and I also tried using an LB.

I don't know if any of my UI suggestions are correct so please take them with a grain of salt. Just trying to give possible ideas that may help. Like I said, I like the concept and I think it has potential. But I think a lot more work is necessary to make it easy to use.

>does not have the time to learn Chef, Puppet, etc.

Dude, get out ASAP where you work or read puppet's tut NOW. Puppet began to be of real use to me after between half to one full workday (~8hrs.). IMO that's what you need to be able to invest at any sane workplace.

(Still learning; but now it's more like design patterns when you already know $LANG)

Thank you for your comments! We will consider them and try to improve our UI this way. Also, we are working on the realisations of video tutorials, which may help the comprehension during the learning phase.

You're missing the most important part of networking with your potential customers. Provide a contact point to the potential customer where he can get help in setting up the instance today. It's good that you're incorporating his feedback but why not ask him to contact you and help him set up on your platform. Just a suggestion.

We have contacted you though by email using the one you have registered with. Please, come back to us with some of your availabilities to setup a session where we could help you to build your application.

This is interesting, but I already have a rather complex app deployed at a fairly large scale and complexity.

I would like too be able to have a tool that will diagram out my infra from access to my AWS console though, that would be interesting. [[EDIT: It looks like it does this.. Ill check out that function just to see what it produces]]

I think this wil work for smaller, less complex implementations/apps, though.

WRT to @roeme's comment >skeptic as to how well DevOps lends itself to be visualized, though; have you seen StackDriver.com?

I swear by it - its farking fantastic for getting visibility into the performance of our cloud.

Indeed =) we do provide this functionality. Import as stack/app isn't possible yet, but is in progress. About StackDriver.com, we'll have a look about this!

Nice tool. I think it gives a good starting point to understand common topologies ... but beyond that ... I am not sure.

Also, does it export templates to CloudFormation? I'm wary of using a SaaS to manage my infrastructure if it doesn't give me a way to revert to core AWS services.

Mi Maslam. Indeed, VisualOps is a good starting point to understand common AWS topologies. However, it goes much further! In fact, VisualOps allows you to configure the software layer of your AWS instances, directly from the IDE! It allows you to define which packages you want on which instance, their configuration, the sources repositories, the scripts to launch, and so on! - Yes, you can export VisualOps stacks to CloudFormation templates. Unfortunately, doing this, the configuration management won't be possible.

What exactly is used under the covers for provisioning the AWS resources, cloudformation? If so is it possible to export the cloudformation template after resources are created in the gui? I could see this being extremely useful if that's the case.

We use a custom version of Boto (AWS Python API) to provision AWS resources. However, yes, it is possible to export your stacks as CF templates.

Would be interesting to hear from them on the rationale of why they chose Salt stack compared to puppet, chef or ansible. I figure they must have given it a good analysis since it seems to be a heavy part of what VisualOps/Madeiera is about.

Indeed, this has been a hard decision to make! There are several reasons behind this choice. 1- We think SaltStack is actually taking the right approach of configuration management. Their "states" are easy to understand, and the users don't waste time trying to figure out what does what. 2- We did have thought about Ansible (similar about 1- idea), but their "distribution" approach is different. Indeed, Ansible uses SSH to configure the remote hosts and not a dedicated agent. This is not the was we wanted to take the problem (we are providing or own backend, and using salt only on the agent-side). 3- Even if the technology isn't doing the product, Salt is written in Python. We love Python, and it helped us a lot to integrate their engine in our agent.

The idea behind PaaS is to abstract away underlying infrastructure. Here it seems users are managing servers, load balancers and interconnects directly. While very cool, this style of automation is a far cry from PaaS.

We think that there is a huge gap between IaaS platforms and PaaS platforms, that had to be filled. PaaS solutions have their users, IaaS also, but many people want to get the ease of use of PaaS services without their restrictions and the customisations possibilities of IaaS solutions without their configuration complexity. VisualOps is aimed to fit to those people, giving a human approach to IaaS solutions.

This is very similar to the BlueMix beta from IBM on SoftLayer. https://ace.ng.bluemix.net/

We will have a look at this, thanks!

Just a quick FYI, on the iPhone, your logo is on top of the nav links making it impossible to open the blog and really hard to click on about or documentation.

Thanks for comment! We'll fix this ASAP.

Brilliant! This is how I (a developer "forced" to manage a few servers) always wished Puppet would work.

Thanks! Don't hesitate to contact with us if you have any question.

Will this work with Spot instances? I looked through the documentation but didn't see it mentioned anywhere.

Hi Patrick, unfortunately, I'm afraid not at the moment. This is in our roadmap though, stay in touch ;)

Cool concept.

Question - Why not use cross account IAM roles instead of asking for API keys?

We allow you do use IAM roles to give us access to your AWS account, as explained in the documentation (http://docs.visualops.io/source/getting-started/aws.html)

What I am seeing is a straight IAM Role. I meant cross account, so visualops AWS account will be given permission.

http://docs.aws.amazon.com/IAM/latest/UserGuide/cross-acct-a...

Cross account IAM access is on our roadmap. You can vote for it on our public roadmap board: https://trello.com/b/wQdmsmp0/madeira-idea

beautiful website. want to help you out with a typo i spotted: at the bottom with Ensure, runing should be running.

Thanks for letting us know! We'll fix this ASAP.

Your homepage is delightful.

Thanks you! =)

this is what i am looking for.

Thanks Frank! Glad we can help =)

amazing

Thanks!

Reply on news.ycombinator.com