Conference App goals

[Ken Finnigan]

All,

Ondro's post [1] about updating the conference app triggered some related ideas, but I wanted to raise them separately.

In the beginning the conference app was built with the goal of each MP.io implementor developing a single microservice as part of the application that would run on their implementation. Doing so allowed us to showcase multiple implementations running that each provide a microservice to be consumed in a single overall application.

Since that time the conference app was altered to support every microservice being run on a single vendors implementation.

Now that we have more MP.io releases of varying content, and with increasing speed, I think we need to revisit these changes.

If we expect every microservice to run on every vendors implementation, and that the conference-app is always updated to the latest MP.io release, there will be occasions where a vendor implementation may not work with the latest MP.io release. This raises the problem of anyone wanting to use the conference app with an implementation potentially being uncertain as to whether that vendors implementation works with the latest MP.io release that conference-app uses, or encountering errors because features in a new MP.io release are not working or prevent deployment.

I would prefer if we went back to the original idea of each vendor implementation being focused on a single microservice within the conference-app, as there are plenty of opportunities to expand the application to have additional microservices as new vendors support MP.io. It would also show how a single application could not only use microservices running on different vendors, but also have them running against potentially different MP.io releases. To me that's a more realistic representation of a real life situation than the entire application and all its microservices being updated to new versions at the same time.

Thoughts?

Ken

[1] - https://groups.google.com/forum/#!topic/microprofile/S1BWq5UODYM

[sst...@redhat.com]

As the scope of the MP features increase, there will be implementations that simply do not provide all features, so focusing on separate microservices is good. It would be good if each microservice should have a collection of profiles for different vendors to illustrate how to run that microservice with its collection of MP features on different vendors.

[Kevin Sutter]

Let's see if I understand your proposal...  The original Conference App was developed by the following vendors' app server teams (with input from other individuals as well):

microservice-schedule - Payara
microservice-session - Wildfly
microservice-speaker - TomEE
microservice-vote - Liberty
Angular UI - Tomitribe

And, as you have stated, the original intent was to show how all of these various microservices could run on the individual app servers and still provide a cohesive application.

But, due to various reasons, we've started to stray from that intent and we're now trying to allow all services to run on a single app server.  For example, all microservices running on Liberty, or Wildfly, or whatever.  Might be good for vendor conferences, but it's straying from the original intent.

And, as each vendor determines what portions of MicroProfile they wish to support, attempting to keep this multi-vendor microservice application running on a single vendor's implementation may prove difficult, if not impossible.  Just too many branches to create and maintain.

The proposal on the table is to allow each vendor to update their designated microservice for the MicroProfile features that they plan to support.  So, as an example, if Wildfly only planned to support Config 1.1 and JWT 1.0, then the microservice-session would only be updated to support those features.  Updating microservice-session to use FT 1.0 would not be in their cards.  But, maybe providing additional profiles to run microservice-session on other app servers that support Config 1.1 and JWT 1.0 would be in the cards.

And, if a vendor really wants all of the services to run on the latest version of all of the specs, then they are welcome to fork the repo and maintain their own version of the application.

I'm not ready to say +1 on this idea yet.  Just wanting to ensure I got the gist of the proposal correct.

Thanks, Kevin

[Ken Finnigan]

You've explained what I was meaning better than I had Kevin, and yes that's the general gist.

The key points for me are complexity in ensuring all implementations can all run the same MP.io release, otherwise the conference app will have broken services depending on which implementation you're trying to execute with.

It's more realistic to have different parts of the application supporting different functionality, as would be the case as different parts of an application are updated for new things.

It also simplifies the poms to only be concerned with a single implementation for a microservice. Flip side is we need to think about the architecture and what pieces are missing to ensure that there is a minimum of one microservice for each MP.io vendor implementation.

Ken

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6124bdc9-2811-4c40-9361-d0393bb160ff%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Kevin Sutter]

Right, and if we get more vendors implementing MicroProfile components, then they can develop their own microservice that links in with the Conference app.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/CgLUMa2t_WQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe7Q6LG7DSVyViF%2BZEX9CNtdiQjAHVUkw3U78U8FXXmaeQ%40mail.gmail.com.

[sst...@redhat.com]

Also, as other implementations come along, they shouldn't necessarily have to create a new microservice. It would be good if one could just submit a new PR for a profile that enables that implementation to run the given microservice. 

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6124bdc9-2811-4c40-9361-d0393bb160ff%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/CgLUMa2t_WQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Ken Finnigan]

Unfortunately that's the exact thing I want to move away from and back to the original idea of 1 vendor implementation per microservice.

The reason being that having every microservice runnable on a single vendor implementation means that all vendor implementations must support the same version of MP.io used in the conference app for that to work.

For instance, if WF Swarm supports 1.1 but Liberty supports 1.2, that either forces the conference app to either follow lowest common denominator (1.1 functionality only) or stay with the latest (1.2) and some profiles will fail because they don't support 1.2 only features.

As I don't think its a realistic assumption that all MicroProfile vendor implementations will always support the same MicroProfile version at the same point in time.

Ken

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/edbd71a8-bc9a-4113-8ca3-c3da84f8a7cb%40googlegroups.com.

[Kevin Sutter]

>  As I don't think its a realistic assumption that all MicroProfile vendor implementations will always support the same MicroProfile version at the same point in time.

Agree.  Maybe not today, but very soon, especially with the content of MP 1.2 firming up.

[sst...@redhat.com]

Hmm, I'm not saying that at all. There is no reason for every microservice to run on a single vendor implementation. What I'm suggesting is that say the session service is using 1.1, and joes-mp-impl comes along supporting 1.1, they can sumbmit a profile for running the session service on joes-mp-impl.

Is the concern where someone want to update the session service to use 1.2 features and you don't want to have older implementations having to work on a branch?

[Ken Finnigan]

Ah ok, understand what you mean now.

Though I agree offering that might be nice, it still poses the problem of updating a single microservice would require coordination between vendor implementations within the profiles of that microservice to ensure they all can support a newer MP.io release.

I think the best way to handle multiple vendor implementations is with different microservices within the single app, but vendors are free to fork the repo to make all microservices work with their implementation only.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/2979eaa2-2b5a-4380-a2bd-98690f2adfd5%40googlegroups.com.

[Ondro Mihályi]

I think that it's reasonable that each service is maintained by a different participating vendor so that their latest version of implementation is guaranteed to be compatible with at least one of the services. It also means there's obvious default implementation for each service.

But we can also mandate the MP version required by each service and ensure there is at least one service for each MP version until all vendors support newer MP versions.

E.g.:
- schedule svc depends on MP 1.0, with a profile for all vendors
- speaker svc depends on MP 1.1, with a profile for Payara and LP
- session svc depends on MP 1.2 (once released), profile for approriate impl
- vote svc depends on MP 1.0, profile for all vendors

Each svc would have a default impl as was the initial intention, but it could have profiles for other compatible impls. Any service can later depend on a newer MP version if another svc works with an older version. E.g. vote svc can be changed to depend on MP 1.1 because schedule svc remains running on MP 1.0 (profiles for vendors without a MP 1.1 impl would have to be disabled for the vote svc obviously)
If we drop support for MP 1.0 then also the schedule service can depend on MP 1.1

In short - each supported MP version would have to be supported by at least one service, but it doesn't matter which service.

--Ondro

[Ken Finnigan]

My concern with this approach is two fold:

1. It means that each service has potentially a very confusing setup such as pom.xml having 1..n profiles. It makes it more difficult for our users to pull out a single microservice and see what's required to make it work. Even more so if different implementations have different configuration or code requirements, meaning we end up with src/main/payara/resources, src/main/wfswarm/resources, etc.
2. If we take the speaker svc from your example. If Payara is the "lead" of that svc and wants to update it from MP 1.1 to MP 1.2, what do they do about the LP profile? Do they comment it out to prevent it breaking, or do they leave it alone and let it break if someone runs that profile? Or the other way around, LP wants to update to MP 1.2 but they're not the "lead" for that service, what do they do?

When the conference app was originally created there were concerns raised by myself, and others, about adding a profile for each implementation to each service as it complicated the application. I fear we're heading back down that road again.

My preference would be for dozens of smaller services, "owned" by a single vendor implementation, instead of a handful of services with dozens of profiles for different vendor implementations.

Ken

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7d123b85-a7d3-40eb-854d-374c5123ce26%40googlegroups.com.

[Emily Jiang]

Ken,

For your first concern, as long as each service owner updates the instruction correctly, it should be fine. To improve this further, I think we should divide the conference app into 5 microservices. They should be loosely coupled and interrupt via service discovery. Each service should have a dedicated repo and everything is clearly documented and there won't be any confusion with the profile dependencies. Therefore, there will be microprofile-conference-scheduler, microprofile-conference-vote repos etc. We can expand this to add more services and create service interactions.

As for getting one profile to run all services, it should be that profile's responsibility. Obviously that profile needs to support the latest spec. Otherwise, it may not be able to run all services. We should not mandate this in MP though.

Emily

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Ondro Mihályi]

Hi Ken,

I agree that my suggestion may lead to lots of confusion. I could find simple solutions to each of your concerns, but let's just keep it simple and have each service coupled with specific implementation. If we want to demo more implementations, we can introduce more services. 

To reduce the effort for new vendors that want to join the conference app, they can alternatively copy any existing service and create an alternative version for their impl. E.g. there could be the microservice-schedule project with configuration for payara, and a copy named microservice-schedule-kumuluzee with configuration for kumuluzee or any other new vendor. In fact, we could rename all existing services to add a suffix that indicates the implementation used to make things clearer and straightforward, without looking into pom files.

--Ondro

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Ken Finnigan]

On Sat, Sep 9, 2017 at 5:30 PM, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

Ken,

For your first concern, as long as each service owner updates the instruction correctly, it should be fine. To improve this further, I think we should divide the conference app into 5 microservices. They should be loosely coupled and interrupt via service discovery. Each service should have a dedicated repo and everything is clearly documented and there won't be any confusion with the profile dependencies. Therefore, there will be microprofile-conference-scheduler, microprofile-conference-vote repos etc. We can expand this to add more services and create service interactions.

Though it would make starting the conference app a bit more complex and requiring more steps, it probably makes sense for each service to be in its own repository as you suggest. This is also more aligned with microservice deployment models and CI/CD for deploying a service from a single git repo, etc.

This opens up some interesting thoughts as to demo/promote this, but I don't want to pollute the thread with even more confusion!

 

As for getting one profile to run all services, it should be that profile's responsibility. Obviously that profile needs to support the latest spec. Otherwise, it may not be able to run all services. We should not mandate this in MP though.

Not sure I understand what you mean here. Can you elaborate?

 

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/89707f82-d558-44e7-976a-c273de1f4b0e%40googlegroups.com.

[Emily Jiang]

Ken,

As for getting one profile to run all services, it should be that profile's responsibility. Obviously that profile needs to support the latest spec. Otherwise, it may not be able to run all services. We should not mandate this in MP though.

         Not sure I understand what you mean here. Can you elaborate?

Sorry. I was talking about one runtime e.g. WebSphere Liberty to run all services. 

I do agree we have problems if we mandate one service multiple runtimes,  "speaker svc depends on MP 1.1, with a profile for Payara and LP". My suggestion is one service targeting one runtime. In order to add more runtime to the conference app, the best way is to introduce new services, as suggested by Ondro. The other suggestion is to create another demo app. 

Emily

[Ken Finnigan]

That's fine, as that aligns with what I was suggesting. One implementation per service, at least in MP.io sense. Vendors are free to fork and create version of every service that runs on their stack

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/f5f2d671-5a90-4638-b670-e18decd722cb%40googlegroups.com.

[Kevin Sutter]

I'm okay with this approach, but we should probably make that very clear from the README for the Conference App and/or Code comments to indicate the associated vendor of each service.  Or, like I think Ken mentioned...  Maybe we should just create separate repos for each service and make it very clear... 

--  Kevin

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/CgLUMa2t_WQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe69eJcVb73FJR1xBaFCMxWnW8dYP_uTG%3DL%3DgcBCiUr08g%40mail.gmail.com.

[Ondro Mihályi]

I wouldn't split the code to several repos - it would be confusing for newcomers and also much harder to work with for us. The app should be small enough to keep it in a single repo.

Otherwise I agree:
- maintain single impl per service, make it clear in the README which impl is associated with which service
- maintain the services as separate maven modules, without any shared modules or even parent pom
- for new impl, create a new service or copy existing service and provide an alternative to it

We can have a script in the root folder to start all necessary services, including the nodejs frontend and possibly service discovery registry etc.

--Ondro

[Emily Jiang]

We should do microservice architecture properly. Therefore, my suggestion is to split them up. In this way, it is much easier to manage. Each service can release at a different pace. This is recommended to way to do microservice though. They have their own lifecycle and they should interact via service discovery etc. 

For your concern Ondro, each repo can clearly document their service. It is easier for new comer, I think. 

Emily

[Ken Finnigan]

I also agree that splitting the microservices into separate repositories aligns with CI/CD, etc.

To alleviate some of the "pain" of splitting, perhaps the current repo could remain and it contains the UI pieces, along with details about the services, which repositories they're in, etc?

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b16f739b-140f-4006-be4c-9aabd5736d47%40googlegroups.com.

[Emily Jiang]

+1 Ken! 

On Tuesday, September 12, 2017 at 1:47:51 PM UTC+1, Ken Finnigan wrote:

I also agree that splitting the microservices into separate repositories aligns with CI/CD, etc.

To alleviate some of the "pain" of splitting, perhaps the current repo could remain and it contains the UI pieces, along with details about the services, which repositories they're in, etc?

On Tue, Sep 12, 2017 at 8:11 AM, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

We should do microservice architecture properly. Therefore, my suggestion is to split them up. In this way, it is much easier to manage. Each service can release at a different pace. This is recommended to way to do microservice though. They have their own lifecycle and they should interact via service discovery etc. 

For your concern Ondro, each repo can clearly document their service. It is easier for new comer, I think. 

Emily

On Tuesday, September 12, 2017 at 9:14:38 AM UTC+1, Ondro Mihályi wrote:

I wouldn't split the code to several repos - it would be confusing for newcomers and also much harder to work with for us. The app should be small enough to keep it in a single repo.

Otherwise I agree:
 - maintain single impl per service, make it clear in the README which impl is associated with which service
 - maintain the services as separate maven modules, without any shared modules or even parent pom
 - for new impl, create a new service or copy existing service and provide an alternative to it

We can have a script in the root folder to start all necessary services, including the nodejs frontend and possibly service discovery registry etc.

--Ondro

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Kevin Sutter]

Yes, +1 to Ken's suggestion.

Use the current microprofile-conference as the starting repo.  This would contain the overall instructions and angular UI.  And, then we could create microprofile-conference-vote, microprofile-conference-session, etc repos.  I think this would be clear enough.

--  Kevin

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/CgLUMa2t_WQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/0c468859-cf37-43b7-9c46-baeb003e7eac%40googlegroups.com.

[Ondro Mihályi]

I see that the majority is for a split and I'm not against, provided that it's done in a clean and documented way. Although I can't imagine that newcomers would clone several repos just to get started with a demo...

--Ondro

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Ken Finnigan]

I've had to clone multiple repos in the past, but we can also provide a script in the main repo that can clone all the required repos.

But, I'm hoping that wouldn't always be necessary.

I see splitting by service opening up the possibility for vendors to host the service they own somewhere, allowing someone to simply clone the UI and have it "find" those services for use. Thus a user would only need to clone the UI unless they wanted to play with the services directly. Granted that's not a super realistic discovery scenario, but would be an interesting exercise.

Ken

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/bba52d28-cda8-4dbb-a436-f3b390b51953%40googlegroups.com.