Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] About Profiles
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)

Mariano Amar

Senior Consultant

email/hangouts: mariano.amar@xxxxxxxxxx
skype: marianoamar

AVISO DE CONFIDENCIALIDAD DE CORREO ELECTRÓNICO

Esta comunicación contiene información que es confidencial y también puede contener información privilegiada. Es para uso exclusivo del destinatario. Si usted no es el destinatario tenga en cuenta que cualquier distribución, copia o uso de esta comunicación o la información que contiene está estrictamente prohibida. Si usted ha recibido esta comunicación por error por favor notifíquelo por correo electrónico(info@xxxxxxxxxx) o por teléfono (+54 11 3249 7503)

This communication contains information that is confidential and may also be privileged. It is for the exclusive use of the recipient. If you are not the intended note that any distribution, copying or use of this communication or the information it contains is strictly prohibited. If you have received this communication in error please notify us by email(info@xxxxxxxxxx) or phone (+54 11 3249 7503)


On Fri, May 18, 2018 at 10:47 AM, Mark Little <mlittle@xxxxxxxxxx> wrote:

On 18 May 2018, at 14:40, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

Hi,

On Thu, May 17, 2018 at 1:46 PM, Mark Little <mlittle@xxxxxxxxxx> wrote:
This isn’t just about vendor choice. You are certainly not alone in being happy with the full profile option. However, there are other classes of users/developers that aren’t and these have existed since the dawn of J2EE. For example, some people want to deploy their favour app server on to constrained devices which may be running on the cloud where an additional 50MB costs real money when run for hours or days or weeks or longer.

I wonder, is there in practice any service / device where a mere 50MB of disk space makes all the difference?

You mean apart from cloud (yes, those 1 cent costs do add up, and there’s private cloud deployments of which you may be unaware and have some funky architectural choices behind them), IoT? Oh and maybe it’s not just 50MB but some modern implementations can still be a bit “plump” in some areas ;)


 
Some developers want to reduce the maintenance complexity or boot time of their favourite app server by stripping out those capabilities they don’t want.


For that particular issue a static configuration (such as liberty's server.xml and in limited way JBoss/WildFly's standalone.xml), and/or the aforementioned prune tool would work just as well.

And then we get into the world of portability. As a developer I want to know a priori that my app will work across app servers and I really don’t want to have to check when I do the migration. Having app server A and B both say they support and are compliant with Profile X is extremely useful.


 
Now you could argue that these developers could just do this themselves anyway, e.g., JBossAS has supported this kind of pruning from the start. However, if you want portability and interoperability of your apps so you’re not tied to a specific app server implementation/vendor, having standardised profiles is the right approach.

Or a standardised static config, perhaps?

And what would we call those static configs. Oh hold on, let me suggest … profiles? ;)


Kind regards,
Arjan

 

Mark.


On 16 May 2018, at 23:16, Dominik Hufnagel <mail@xxxxxxxxxxxxxxxxxxx> wrote:

As a user of JavaEE, I do not get the idea behind having multiple profiles. May someone can explain the benefits for users? If I can have a single profile with all available features, I would take it and I do not bother using a server which is 50MB larger of one with a „smaller“ profile. I can understand that it could be harder for vendors to enter the market having to provide the full profile. But for me, this would not be an argument for using smaller profiles. I’d rather take a server from a vendor which offers me the full profile. 
 

If I would use the MicroProfile and want to have JPA, do I have to add external dependencies? I really like some of the new APIs of the MicroProfile and would be happy to see them coming to JakartaEE.

Dominik
 
 
Von: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@eclipse.org] Im Auftrag von Mark Little
Gesendet: Mittwoch, 16. Mai 2018 11:42
An: Jakarta EE community discussions <jakarta.ee-community@eclipse.org>
Betreff: Re: [jakarta.ee-community] About Profiles
 
Hopefully others have responded already but … it’s for both: quick summary … vendors so they can ensure conformance and users so they can ensure portability and interoperability of their apps.
 
Speaking with my MicroProfile hat on, I for one would not want to trade the current MicroProfile for a full Jakarta EE profile and neither would our users.
 
Mark.
 
 
On 7 May 2018, at 17:33, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
 
So then the first question is perhaps; who wants profiles and benefits from it? Is a profile intended for vendors or for users?
 
 
---
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)
 
_______________________________________________
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

---
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)


_______________________________________________
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

---
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)


_______________________________________________
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