[Nyetan]

Zero offense intended; the following are my honest-to-goodness impressions of your product.

1. I have no idea what it is. DIY (presumably) microservices? And, there's a way to use AWS without servers (is this a reference to Lambda?) The title of your product is 'Digital Enterprise End-to-end Platform', which looks impressive but on further inspection appears meaningless.

2. Reading further into your github page and looking at the DEEP marketplace, I think you're selling software-as-a-service deployments? Something like Sandstorm or Openshift, I'd imagine.

3. Aah, okay, so you're making an abstraction layer on top of AWS -- but it doesn't seem like that permits any portability between cloud platforms. Is the only benefit to using your system easy deployment onto Amazon's product?

[eistrati]

@Nayetan - none taken, very good and thoughtful feedback! Let me answer your questions:

1. DEEP is designed to be Platform-as-a-Service for serverless environments that developers and businesses could use in their own accounts. AWS Lambda is one of those services. The fact that right now only AWS provides the full spectrum of services made us build it on AWS first.

2. "Sandstorm makes it easy to run your own server" and "OpenShift gives you all the tools you need to develop, host and scale your apps in the public or private cloud" - so I would say neither, because the goal as you further described is to be able to support cross-cloud providers, while above ones are service-specific (am I wrong?)

3. You are correct. Right now it's an abstracted layer on AWS, and we are planning to add in near future more providers like Azure, Google Cloud and more. For now, it makes the developer job easy by abstracting everything except application layer, and have it scaled at AWS size, which is virtually infinite.

Does it make sense? And to go even further, what would you improve in our documentation? :)

[Nyetan]

1. Aah, makes sense.

2. The similarity with openshift is due to their Marketplace [1], but it pretty much ends there. Sandstorm as well for much the same reason (easy deployments of premade services).

3. Mmhm, makes sense.

As for documentation changes, please highlight what improvements your product makes to the status quo! The 'DEEP for Developers' section tells me that it adds abstraction on top of AWS' model services, but beyond that, I don't see any improvement to working on the bare metal, so to speak. Like, Sandstorm [2] (sorry, just heard about them so they're on my mind right now) says that they handle authentication themselves. That's wonderful; I hate reimplementing auth for every project! Or even PyPy [3]: I _could_ use CPython, but their product runs faster and uses less memory. Why should I bother to learn DEEP and add another level of dependency to a project?

[1]: https://marketplace.openshift.com

[2]: https://sandstorm.io/#developers

[3]: http://pypy.org/

[mitocgroup]

Again, very much appreciate your feedback. This is the main reason why we've posted it here, to get some discussions and learn together what is relevant nowadays to developers and what is not, so we don't have to reinvent the wheel.

To touch base on your example with authentication, we are working on deep-security library that everybody will be able to reuse without any effort. We are approaching security in every layer similar Amazon IAM, and since we are using microservices architecture, developers don't need to write any security specific code, because it is automatically generated at deploy. Everything is collected at deployment time from every layer and applied on AWS for backend and database, while on frontend is exposed in UI as role-based access. Does it make sense?

[Nyetan]

It's starting to come together :) I'll keep an eye on your repo; I'm still curious about various specifics that will likely be elaborated upon in time.

[mitocgroup]

Thank you, Neytan! We'd be happy to notify you when we are open for public beta, but again feel free to email at [e-mail] to get an early access ;)