I have a big application where there are 5 ears deployed in JBOss7.1.1EAP server running in Red hat Linux on-prem connecting to an Oracle Database on-prem.
What is the best approach for lift and shift to AWS
Solution-1 : Create Jboss EAP instance in AWS EC2 and an RDS Oracle instance and deploy the ears and migrate the tables and data via aws DMS
Solution-2 : Dockerize JBoss EAP with ears in a container and also dockerize Oracle instance and create a network link between the two
Oracle DB size = 3847GB
Each ear size = 300MB
Which solution will fit the best and what are the pros and cons for each solution? Are there any other solution?
Quick preface, "best" is going to be subjective depending on how sensitive this project is to the amount of time for refactoring/learning new tools, how much you weigh cost savings, and the wildcard around managing more of the stack yourself. That being said, here are some considerations for the big two parts of your app:
RDS Oracle vs Containerized Oracle
Dockerizing the oracle DB means that you still need to handle security patching, and requires manual crafting of scaling up/out policies, something that RDS abstracts significantly. Amazon DMS makes it extremely easy to migrate your data from your existing on-prem database to RDS. Additionally, the move to RDS enables you to use other valuable co-features, like RDS Performance Insights, a tool that offers introspection into cluster resource impact from queries and operations, and RDS Proxy for handling connection pooling.
JBOss compute options
If you're currently running on-prem and are trying to lift and shift to cloud, the path of least resistance will be a direct migration to a properly sized EC2 instance. I'm not very familiar with the exact architecture here, but it sounds like there's a persistent server with various sub-applications (ears). In the long term, it sounds like a persistent compute layer (EC2, ECS, Fargate depending on your desired level of abstraction) for the core service, with various scaleable components (containers via ECS/Fargate) would make sense. If significant refactoring to a microservice architecture is not something you're looking toward, then keeping things as they are as a monolith on single node/EC2 instance/container would work.
Related
We have a quite large monolithic app (java/spring) and we are considering splitting it up to microservices and using spring-cloud to utilize existing solution for some common problems (discovery, redundancy etc.). Currently we run one instance (with different modules) per client.
Some of our clients are small and one VPS handles it and others are larger and might use multiple servers.
The problem is that this "pack" of microservices should be isolated for each environment - they might be slightly different.
As I am reading through resources about Cloud Foundry - which looks really great - it seems that it would be best to run an cloud foundry instance per client and I am afraid that that is overkill and quite a lot of work to get one client running (which I would like to automate as much as possible).
Ideal Solution
BEGIN
We provide servers with heterogenous OS, possible containers (VM/docker/jail/...) with restrictions where they may rur and finally services with restrictions in which containers they may run.
When creating new environment I just provide list of services to run in it and the Solution creates containers, deploys services in them and sets up communication channels (message broker) between them.
It should also handle upgrades, monitoring, etc.
END
What approach would you recommend? Or please could you share your experience from building similar thing?
Thanks
You could provide each customer with their own space in a single CF instance where all the microservices are deployed.
I'm relatively new to Java EE and have already began to hear about the many different types of systems that can be clustered:
Virtual Machines (i.e. "that appliance is a cluster of VMs...")
Application servers, such as Tomcat, JBoss or GlassFish (i.e. "We're running clustered JBoss...")
Clustering APIs like Terracotta
Databases, like Oracle ("clustered database")
Cloud applications ("A cloud is basically a cluster...")
Wikipedia defines "clustering" as:
A computer cluster consists of a set of loosely connected computers that work together so that in many respects they can be viewed as a single system.
I'm wondering how clustering works for each of these "cluster types/methods" (mentioned above) and how they relate to one another.
For instance, if one could benefit from having a clustered application, he/she would probably put them on a clustered app server and then throw a cluster manager into the mix (again, like Terracotta).
But because the phrase "clustering" seems to be used in vague/ambiguous ways, I'm not seeing how each of these ties into the others ones, or if they even do. Thanks in advance to any brave StackOverflowers out there who can help me make sense of this interwoven terminology!
To me, clustering implies a number of qualities to a system but it boils down to fault tolerance -- server, networking, and data persistence. There are both loosely and tightly coupled systems and all flavors in between. Tightly coupled systems have the clustering performed at level close to the hardware. Many of the old clustering systems were more tightly coupled with the applications often not recognizing that they were clustered.
Loosely coupled systems are the norm these days with a large degree of the fault tolerance accomplished at a software level entirely. Systems in the cluster only share network connectivity to be able to accomplish fault tolerance. Usually there are some specialized load balancers which route requests to the various cluster servers using specialized hardware (sometimes just software) to accomplish this.
All of the examples you mentioned have some sort of "clustering". It is going to take a very long answer to describe the details about how each of the architectures accomplish this. For me, the differences are what comes "for free" when you use the architecture, and how much work you will have to do to get it to work optimally.
How you mix and match the solutions you've mentioned depends on what your architecture looks like and your requirements. You can have a Terracotta store for local high speed persistence and the cloud for the rest. You can use Glassfish as your application server and utilize Terracotta as your persistence layer.
Here are my thoughts about the technologies you listed:
Cloud applications ("A cloud is basically a cluster...")
Cloud applications are the easiest to work with obviously. Your only job from an architecture standpoint is to pick a good cluster provider. Certainly Amazon and Google will do it "right" in terms of fault tolerance and data integrity. There are many other players that probably do it "good enough" and are cheaper. You program to their APIs which come with their own set of limitations and expenses. One problem with cloud applications is that it most likely will be very hard to switch to a new one. Again, you might have some [large] portion of your application running on cloud servers and have some local systems for your higher latency requirements. The trend is to put most production functions in the cloud or at least start that way until you get too big or need some services they can't provide.
Clustering APIs like Terracotta
Databases, like Oracle ("clustered database")
JBoss
These 3 systems provide their own clustering capabilities. They may require you to do a lot of machine and service layer configurations to get the system running well in a production environment. I hear good things about Terracotta which is a distributed persistence layer. I've used Jgroups a lot which is under Jboss and it can be tricky to get running right but Jboss may also have some good default configurations/documentation. Oracle is most likely going to be hardest to cluster right. DBA's make a lot of money tweaking Oracle configurations.
Virtual Machines (i.e. "that appliance is a cluster of VMs...")
Application servers, such as Tomcat, GlassFish
These are the most amorphous to define in terms of clustering. Some VMs are considered "clustered" in that they share networking hardware and power backplanes but are really not clusters when compared to cloud computing certainly. As mentioned, there are some clustered hardware solutions that are very custom and will require a lot of specific domain knowledge to get running well.
I have very little experience with application servers such as Tomcat and Glassfish. We have our own clustering software on top of Jgroups and run Jetty entirely. Application servers are not, in themselves, "clustered" but packages such as Jboss and Terracotta run on top of them to provide clustering and they have internal projects which have clustering software written for them.
Hope some of this helps.
Here's a quick whack at it. How you cluster depends on what your goals are. Here are some thoughts that also tie in to GlassFish.
A cluster enables multiple instances to be managed as one since they share a common configuration. If you make a change to a configuration, such as defining a new resource, then all instances that belong to a cluster inherit that change. Deploying an application to a cluster deploys it to all instances of that cluster.
A cluster provides service availability. If one instance fails, deployed applications are still available on other instances.
A cluster can offer session availability. If an instance dies while a user has items in their shopping cart, then another instance can take ownership of handling that user's session such that the shopping cart contents are still there. The user never knows a backend server has failed.
With GlassFish, HTTP session state can be managed by GlassFish (built-in), delegated to a coherence grid, or the application can manage state itself (using terracotta, database, etc). The benefit of using the built-in capability is that it works out of the box and has gone through stress testing, QA, etc. The benefit of externalizing is that you can potentially get better scalability since you decouple session management and application logic. Externalizing lets the JVM focus on executing business logic, and uses less HEAP space since backup sessions exist elsewhere. Oracle has tested / QA'd externalizing to the Coherence Grid, and is a formal feature of the commercial Oracle GlassFish Server. If you roll your own via database, then you need to manage & QA itH yourself.
I am about to develop my masters project using Flex as front end, BlazeDs, Java Web Services and MongoDB in the backend. I am looking to deploy and manage it on a cloud. (The application analyzes financial data from various sources, I will need to query multiple endpoints for news articles and DB for processing)
It is my experiment to usage of cloud rather than deploying on my local for demo and presentation purposes.
I saw heroku (http://www.heroku.com/), but I am not sure if it allows flash.
Please suggest a cloud application platform which allows Flex, BlazeDs, Java Web Services and MongoDB?
Amazon Web Services is a good place to start. You can have a instance ready in like 15-30min from signing up. If you are just experimenting, you ought to try to get the Amazon Linux Image (AMI) up and running. Scour the net on HOWTO set up Tomcat, for your requirements it might be too much to go J2EE, but you might know better.
But a word of advice, it's better to get your application working on a local machine first. Then drop the programmer hat and put on the deployment hat 100% cause it's a b!tch configuring deployment environment for Tomcat configurations, Blaze DS, Mongo's failover servers, load balancers and all kinds of non-programming tasks. You will want to work your development stack close to home so you can diagnose quickly.
Cloud business is great only when you want 1) Not use your home PC and bandwidth as a server 2) You want to have global mirror points to your application so that user's latency in one area of the world is not slower than another part of the world 3) You want to distribute computing load burden on one application across many instances of the same application.
Clouds are relatively cheap to deploy but if you got an application that hording GB's of bandwidth and storage, be prepared to fork over $1000's+ in costs. You can save money by going with an OS with no licensing costs to get a better rate.
http://en.wikipedia.org/wiki/Eureka_Streams
http://www.eurekastreams.org/
Eureka Streams uses a shared nothing architecture. It uses Memcached, Apache Maven, PostgreSQL and Hibernate. It uses Shindig for OpenSocial.
It makes use of Java Message Service (JMS), Java Persistence API (JPA), Lucene and Google Web Toolkit (GWT). It makes use of the Apache JServ Protocol (AJP), OAuth and Representational State Transfer (REST).
The tech sounds solid as hell, and it was developed by Lockheed Martin, but I just want to be sure before I commit to anything that this "enterprise" solution will function as fantastically as it sounds outside of a single-node intranet environment.
Thoughts?
Edit: As stated in the title, I'm specifically concerned with scalability and security.
We built Eureka to scale to enterprise sized populations. We're currently deployed on about 40,000 employees and are soon going to have to scale to over 100,000. We've run performance tests with these points in mind.
To scale to something Facebook sized we'd probably have to start using something like Cassandra. That said, we've made the architecture robust enough to be able to support switching out data sources, so if this ever had to be done, it wouldn't be a rewrite.
As for security we use Spring Security with a few default authentication mechanisms including a straight Forms auth provider, ldap and kerberos. You can create new authentication mechanisms pretty easily.
The OpenSocial container part of Eureka Streams has an OAuth implementation allowing OpenSocial applications to connect to external resources using OAuth 1.0a.
Feel free to post in the Google Groups discussion with any specific technical or other questions:
http://groups.google.com/group/eureka-streams-dev
To answer your question about scalability, we build our front-end data objects asynchronously and store them in the memcache distributed in-memory caching system. Search is distributed too in that each web node has a fully copy of the search engine. Every search is performed locally, and as you create more web front-ends, you're also scaling search.
I am considering to develop an web application with Spring and OSGi. It seems like they fit together nicely. What are the options for clustering and loadbalancing such an app and what are the pros and cons of each?
Neither OSGi nor Spring were created to solve problems such as high-availability, clustering or load-balancing. You could, of course, build a clustered and load-balanced system using Spring and OSGi, but you are probably going to need something else as well, such as a way to detect and communicate node failures and load levels.
Since you are building a web application, most likely you will be using one of the many application servers. Good AS products provide clustering for you. Some also provide load balancing. You can also achieve load balancing through a completely independent setup of your own, using Apache for example to front your main application servers.
If you are really bent on creating your own solution, I have seen JGroups being used in multiple products to provide the necessary infrastructure to build a clustering and/or load-balancing solution. Some of the distributed in-memory caching products use JGroups, for example.
Talking about distributed caches, products such as Ehcache can help with scaling and load-balancing problems.