Hi Mariano.
All I can say is that your mileage will clearly vary. We have customers and people in our communities who do care about disk space and memory consumption, and the profiles help.
Mark.
Hi,
@Mark While I do agree with you that just a full profile + tools is most definitely not enough, there's a few things I believe you might have misinterpreted from Arjan's responses. I also have a few questions on clarifications: - All of my experience on cloud has been working over Bluemix/IBM Cloud as a PaaS, so I'm used to having disk space being billed only for data/io, not for deployment. I The machine/API/platform I want to use is usually priced based on relevant resource consumption, so disk space is billed for on databases (and other persistence modules), while apps/processing modules tend to be billed by memory/processors.
Sometimes, you get a limit to the disk size you are allowed (so you wouldn't be able to deploy 2TB of code into a single Liberty module), but they tend to be reasonable sizes for the general intended use of each module.
I can easily imagine that this would be different for IaaS solutions, since disk size/allotment would actually be one of the resources involved there.
I can also imagine that SaaS would not care about this issue at all.
So, ignoring the costs of on-site stacks (seeing as those are a whole different kettle of fish), where would we actually need to be careful of using a smaller profile, instead of the full profile, because of disk constraints?
I can't see this being anything more than a very specific edge case involving Netflix-sized microservices infrastructures deployed onto an IaaS layer, where having thousands upon thousands of microservices, each consuming a few dozen extra MBs on disk space that's being paid for, would end up being relevant.
Anything else, and I can't see how you wouldn't be directly using some SaaS, or PaaS, for a considerably lower amount of microservices, without bothering to pay for disk space, or your IaaS solution would be small enough that the extra disk space would not impact as hard on the final costs: if you had a hundred microsvcs, all consuming an extra 50MB, for a total of 5GB to 6GB, that would add up to about $20 per year in the most expensive AWS disk space (Amazon File System space costs around $0.35 per GB/month)
- Private deployments would, of course, be a different story, since every MB being spent (and every MB being wasted too, for that matter) has been paid. Of course, we're still talking about less than 1TB for 3K concurrent installations of 200MB sized apps, so that's just as irrelevant as before (specially if we consider that once we've paid for all the storage architecture, we're not paying a cent more before we need to do some maintenance replacements)
- Now, memory space, THAT's the real issue here, and for those I would perfectly agree that an extra 50MB per app can scale up to huge costs in no time:
Anything that requires more than 20 apps running at the same time (like pretty much any micro solution) would start from the get go with an extra cost estimated in the GBs/month.
- And here, we run into the second issue: standard static configs (as proposed by Arjan) are most definitely NOT profiles. They don't require certifications for every allowed API configuration, they don't have TCKs, they don't limit you if you need to switch configs.
A profile is a spec and cert, with all the tests needed, all rolled into a single item. They also acknowledge that cert ONLY on a specific set of APIs (ant their interactions). This means that, if you ever need to switch between two impls of the same vendor intended for different profiles, you'd be as 'neck-deep' into a migration issue as if you switched between two vendors of the same profile impl (dependency checks, code refactoring and testing, etc)
If we were to have a JakartaEE spec/tech that enabled a standardized way of configuring an implementation's internal pruning tool, that would allow us to migrate the EE pruning config without issues (of course, as long as you didn't use the impl specific values/params/options)
Would it solve every issue? Of course not, but it would make things easier, without the need of spawning three dozen profiles. If we spawned a profile for every single vendor implementation of every single use case, then profiles would be utterly useless. There HAS to be some generalized standardization at some level.
- I do, however, agree with having a higher profile count than now, with a more clever hierarchy/architecture defined for them. The fact that we're trying to cover a half dozen environments/use-case types (app server, web server, micro, desktop, mobile, iot, etc) should tell us that we need, at the very least, as many general base profiles.
However, profiles should be a base CERTIFICATION of an environment and it's component interactions, not a minimal environment.
- I can also see the vendor's side, where asking them all to cert for a full profile would keep us limited to the current situation, with a half dozen giants spending over-six-figure budgets on their offerings, while no small vendor can crop up.
Having, as I said in the previous bullet point, a half dozen base profiles could allow the proliferation of environment-targeted vendors to start their business
- As I said in a previous post, I believe we could keep a "simple" hierarchy of:
"Full Profile (Everything under the JakartaEE sun" - App Server - Web Server - Cloud > Micro - Super Minimal Only Barebones Micro > etc... - etc... - In such a hierarchy, the full profile would most probably never see the light of day (since event vendors with all base profiles would find it more comfortable to keep all base profiles in separate offers), and only exist to occupy that zero-level position (as the full Jakarta EE umbrella profile)
_______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
--- Mark Little
JBoss, by Red Hat Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork. Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873 Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)
|