Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] A Composable Platform Over Profiles



On Thu, May 3, 2018 at 10:05 AM, Jason Greene <jason.greene@xxxxxxxxxx> wrote:
Our pricing model does not care about the ratio of app server instances to applications. It’s just based on hardware (virtual/physical) cores.

-Jason

How does that change the scenario that I mentioned - assuming that the existing cores are already optimized/saturated? The way I see it, adding more runtime instances on existing cores just adds more overhead on system resources (irrespective of how lightweight the runtime is); resources which might as well be utilized by additional app(s) in case of unified deployment. May be I am missing something here.

Also, how do I justify the value proposition of having discrete runtimes - does it improve operational efficiency? perhaps, reduce cost in some indirect way? given the escalating impact on other costs that I mentioned.

-Mrinal


On May 2, 2018, at 8:39 AM, Mrinal Kanti <mrinal.kanti@xxxxxxxxx> wrote:

Its primarily due to licensing costs. Its easy to justify additional server licenses as a function of capacity because that's a need that is easily appreciated by business. But asking for additional server licenses to realize discrete deployment for individual apps is very difficult (putting it mildly) unless the client already use some existing cloud based infrastructure that allows independent scaling up of individual apps. What if the deployment landscape still constitutes multiple stand-alone servers? I am NOT trying to divert this conversation towards cloud vs stand-alone servers deployment debate. But given the constraints that one has to work with stand-alone servers how do you explain the value proposition of having discrete app runtimes especially when it does not demonstrate appreciable value (to business) over the existing unified deployment model.

The cost quickly escalates when you factor in associated license fees for third-party caching and monitoring solutions and additional server licenses required for clustering (or other high-availability solutions) required for each of those apps in discrete runtimes.

Also from operations point of view it becomes more challenging for monitoring and managing configuration for those "additional" server instance across multiple environments. (Again I am not talking about cloud)

Provisioning new virtual machines is not the hardest part (relatively speaking). Clients already have the capability to spin up virtual machines configured with app-servers based on pre-configured images. Application deployment is executed as a separate process triggered upon the completion of the server provisioning. Again, this scenario may be typical in some cases but I have had more than one client following this strategy.

Also, if I look at the current pricing model [1] it doesn't discriminate between web-profile or full-profile. If I understand correctly, the customer is charged for the full-profile irrespective of the profile they choose for their applications during deployment.

My line of thought is based on the assumption that we are discussing stand-alone servers. As I said in the beginning, the challenges and value proposition would definitely differ for cloud based deployments.
-Mrinal




On Wed, May 2, 2018 at 12:04 PM, Heiko W. Rupp <hrupp@xxxxxxxxxx> wrote:
On 1 May 2018, at 23:54, Mrinal Kanti wrote:

> *Multiple app deployments:* A typical application server instance in any

I wonder how much this is still true. On one side from the
Container point of view, but also from the pricing pov.
In the past you did a lot of those "stunts" because license
cost and the fact that it was hard to provision new (virtual)
machines for projects, so the once provisioned server worked
as such a virtual machine at a higher level. Now with
OpenStack and containers it is much easier to provide a single
server per app quickly.
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community


_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community



Back to the top