Re: [jakarta.ee-community] WildFly Domain Mode in Containers

[Ruslan Synytsky <synytskyy@xxxxxxxxxxxx>]

Hi Mauro, thank you for your valuable feedback! 

You touched the important points we have not described in the article as it was too long already, and most likely it's better to discuss as a separate and a more broad topic. 

On 22 May 2018 at 18:33, Mauro Vocale <mauro.vocale@xxxxxxxxx> wrote:

Hi Ruslan,
I have read your blog post but I disagree with two aspects that you described.
First of all it seems that you associate the cluster and high availability features with the use of the domain mode. This is not true. Wildfly has got the same features whether it is used in standalone mode or in domain mode. So you don't need to configure a domain to obtain cluster in container environment.

Absolutely, HA can be achieved with multiple standalone servers, I'm not sure that the article claims opposite. If so please give me a hint in a which part. We can probably mention this point as a disclaimer or somewhere at the beginning of the article. The main advantage of the domain mode, as we know, is the integrated Java native ability to use centralized management capabilities via UI and CLI.  

 

When you say "The old question at the official developers portal is still not answered with any adequate instruction that just proves the presence of the issue." you have posted a screenshot of a conversation of 2014.

Sorry for referring to that old one..., I found no other such highly related topic on the domain mode. If you can provide a useful link we will add it to the article.   

The second one is related to the management web console: the purpose is to have a unique entry point to configure and manage a group of servers, simplifing the management of the configurations.
In a container enviroments you don't need it and you don't change configurations: changing a container is wrong, you should change its image.

 

The absence of the domain is not an issue but it's a choice: you can obtain cluster and HA in standalone mode, you don't set static IP in order to enable communication between domain and host controller, and you don't change the image settings, never. You can migrate a JEE monolith application, distributable and stateful, using a wildfly standalone mode, without touch the code.

Ok, this one is a harder one as this topic is opinionated. Changing any state in a running application container is considered as an anti-pattern. Use volumes or change the base image - this is how it should be done right. Cool. It works awesome. That should be done as soon as possible during migration to containers according to current best practices. No doubts. 

It makes sense to mention here, that moving some parts of the file system to a shared and highly available storage was a good practice a long time before the containers came to the stage. Nowadays we can get the whole file system as a service https://aws.amazon.com/efs/ regardless of the virtualization type we use. However, application containers force to follow that rule "right now" with no exceptions. Because currently application containers lose the state every time you restart it. 

Now let's just imagine for a minute that containers can keep the state including the file system and network regardless of downtimes of the underlying infrastructure. Software Defined Storage can handle all container filesystem, restoring everything at a new live hardware or VM node. In other words, container state is resurrected with all data and network settings. With a good storage and network configuration the restoration process is fast. Usually file system size of stateful containers, for example WildFly Worker Nodes, are not so big anyway, because a big data goes to the storage in any case.   

So, why would customers heavily invest in applying new ways to deliver applications, if migration to a stateless design is not a core competency of their company? Many would prefer to focus on the business issues instead of giving developer reimplementing already working workflows. Repatching, rebuilding and redelivering containers to secure productions takes a lot of efforts. Almost any company needs an ops team for managing farm of certified images and get familiar with a new orchestration platform requirements. 

Extending the topic of stateful containers, new Stateful Set @ K8S aims the same - keep the state, do not worry about it, migrate already working solutions and focus on the business value. So, with this article we share our opinion how it can be done without major adjustments and investment into migration efforts for getting immediate benefits with lightweight containers.  

 

By the way, the console looks great and the other aspects of the product seems very interesting.

Thanks, our team invested a lot of love in the UX. One of the major aspect of the platform is a freedom of choice regardless of language, technology stack or cloud provider. So, this time we decided to share our experience working with WildFly, which is a great product! Hoping to publish a next one about running Java EE with Thorntail soon. 

 

my2cents

Thank you

 

Mauro Vocale

2018-05-22 15:59 GMT+02:00 Ruslan Synytsky <synytskyy@xxxxxxxxxxxx>:

Hi folks, I would like to share our latest solution for migrating some sort of legacy Java EE applications to containers. The article at the link below describes the concept of the decomposition approach we use for WildFly clusters running in Managed Domain mode.    

https://jelastic.com/blog/wildfly-managed-domain-in-containers-auto-micro-clustering-and-scaling/

We know that new projects prefer not to use managed domain mode due to its complexity and issues while running inside containers, but based on the feedback we receive there is a lot of companies that still run legacy Java EE workloads in VMs. So we decided to spend some efforts for sharing our knowledge on building micro clusters as a transition point to the desirable microservices. 

Any constructive feedback will be highly appreciated. 

Regards 

  

--

Ruslan
CEO @ Jelastic

_______________________________________________
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

--

Ruslan
CEO @ Jelastic