Amazon EC2 Auto Scaling helps users maintain application availability and allows users to automatically add or remove EC2 instances according to definable conditions.
N/A
TIBCO ActiveSpaces
Score 7.0 out of 10
N/A
ActiveSpaces from TIBCO supports an application infrastructure.
The operating system, CPU, RAM, and storage may be constructed in any configuration and readily altered after the build. The most important factor is the "sense of security."Problems may arise once every several years, but there is a significant difference when discussing how …
On the servers with fixed resources, Microsoft IIS was installed. In terms of storage capacity, the server has a predetermined limit. It's possible to run out of money before the next billing cycle begins. A higher price tag or more resources may be necessary to ensure …
The main reason is our total infra is created on AWS and we tend to use the natural service by AWS rather than third party tools, which has more advantages when the auto scaling interacts with other AWS services and its way easy to configure when we compare it with counter …
There are no reasonable alternatives to consider when you're building a highly available application of EC2 instances in AWS. There are alternative high availability architectures to consider, including but not limited Elastic Kubernetes Service or serverless architectures. In …
The Oracle Compute Instance Auto scaling features works very similar to the AWS once. However, the AWS EC2 Auto scaling feature has many more config parameters to it.
1 year ago, without auto scaling, every time we think we might have a peak in demand, we launch a new server manually. So far we did not buy it but sometimes the server was not used at all or we forgot to remove from load balancer. Cost was affected a little bit but human …
We tried with dedicated hardware load balancers with two servers a few years ago. It was a huge investment, and involves a lot of work, mainly on the server side. Also, that was not elastic. So if we wanted to go from 2 to 3 servers, we need to buy another server. That works, …
Before using TIBCO ActiveSpaces, we were storing all the data in Oracle database and due to large volumes of data response time was more and overall performance had reduced. With the introduction of TIBCO ActiveSpaces, we moved the master data to TIBCO ActiveSpaces for storing …
Actually, we are gradually replacing the Tibco ActiveSpaces with Redis (for caching purpose only) or Hazelcast (for embedded mode and also for in-memory distributed computation purpose + in-memory distributed IPC purpose).
One biggest advantage of the Tibco ActiveSpaces is it's ease of integration with the TIBCO suite of products. Hence it is more suitable to TIBCO AS in conjunction with the TIBCO suite of products.
All products could offer the same or different level of advantages. For the …
[Amazon EC2 Auto Scaling] is simple to set up and pretty self-explanatory. Never had issues around scaling up or down. [Now] we won't need to guess the capacity for our apps or services. The both scaling, up and down is simply perfect, you can actually stop checking every time for resources because this tool takes care of everything
TIBCO ActiveSpaces is only suited in the company where Tibco suites have been already used, the license cost is not a concern, it is only required for data caching purposes and only works in the client/server mode for middle-sizes of data. If the expectation is data cache + distributed computation or embedded IMDG is also one requirement or the data cluster needs span multiple data centers, other light-weight OpenSource IMDG solutions should be considered
TIBCO ActiveSpaces Tuple-based data structure is not flexible enough to support customized native data objects.
There is no secondary index option.
Doesn't provide "predicate based In-Grid distributed search and result aggregation."
only can be used as data cache, the node's only contribute memory but can not use the data partition owner node's computation power to apply the distributed computation customized by the user.
Cross data center replication (geographically) is a pain.
Encounter the performance issue when the data volume is huge, even according to the architecture design, linear scaling up should not have that issue.
Usability is good since we already know how AWS works. For those that are new it might be a little bit confusing at the beginning but they are improving it at a fast pace. Even though AWS keeps changing the user interface constantly, it is still powerful, understandable and easy to use. For technical people, they still offer the CLI.
TIBCO ActiveSpaces is easy to install and integrate with other product suites. It is easy to understand and implement as well. TIBCO ActiveSpaces supports multiple databases for storing the data(we are using Oracle Database). All the master data related to the users is being stored using TIBCO ActiveSpaces which keeps the data in memory and help to retrieve it quickly. It has helped to prevent concurrent login sessions by the same user as session details are stored in TIBCO ActiveSpaces and we override the existing user session with the new session details.
The platform works as is. The help and tutorials on the help page can help you to setup the entire platform without problems, and also provides help on a huge variety of problems. Amazon also provides support plans. We have the basic support plan, but Amazon offers three support tiers, and we know that it works perfect.
The operating system, CPU, RAM, and storage may be constructed in any configuration and readily altered after the build. The most important factor is the "sense of security."Problems may arise once every several years, but there is a significant difference when discussing how to cope with hardware problems in the local age.
Before using TIBCO ActiveSpaces, we were storing all the data in Oracle Database and due to large volumes of data response time was more and overall performance had reduced. With the introduction of TIBCO ActiveSpaces, we moved the master data to TIBCO ActiveSpaces for storing data which needed frequent access in memory for faster retrieval. This improved the performance significantly and also made managing data easier.
We will devote more time to development than server administration, but we will require additional time if you migrate from another ecosystem.
Fault detection and reporting are automated in the old server, and bandwidth is fixed per month, but everything is manageable automatically. We only pay for the resources we use.
After some months, we met our return on investment (ROI).
Developers with basic knowledge of TIBCO and general data knowledge can easily design and develop an ActiveSpaces based cached solution. As the ActiveSpaces concepts are very simple and easy to understand.
Some business areas can predict the high influx of a service usage during a certain period. Business will be highly rewarded if they can identify these business areas and provide a cached solution using TIBCO AS.
Again, this is not a TIBCO ActiveSpaces only advantage and this is true for any/all caching products.
Some examples for the previous points are
a. telecom company pre-loading (eager load) customer's usage for the last month, right before releasing/issuing the bills to the customers.
b. Airline industry loading the customer's itinerary a week before his travel start date. Hence the last minute scrambling to fetch the customer's itinerary travel plans can be avoided.