I'm developing a webservice on IBM Bluemix with Liberty for Java and Cloudant and I have to cache some data in memory.
The auto-scaling component creates new instances of my application and I would a shared cache between instances.
Is there a sort of Memcache in IBM Bluemix like in Google Cloud?
Have you looked at Redis:
https://console.bluemix.net/catalog/services/databases-for-redis or https://console.bluemix.net/catalog/services/compose-for-redis ? That should sort out your inmemory store needs.
Related
I am developing a high performance service in spring boot. It is deployed to Openshift and running in multiple pods.
Now I need some configuration which is stored in a database and read by all pods. Data can be changed through a web app.
I would like to do some performance tuning on the database part. What is best to do?
Migrate to a H2 database running in a single pod and the other ones connect to this?
Or some kind of redis caching?
Is there any kind of best practise or recommendation to do this?
Currently we are exploring Redis as distributed in-mem cache which would be hosted on AWS via Amazon elasticache.
For Redis cluster connection from application, we are using Jedis client.
What are the cache property settings supported from client side?
org.springframework.data.redis.cache.RedisCacheConfiguration does not give much options other than TTL(time-to-live). IS there any other way to set more cache properties from client-side like enabling ssl, memory size etc.?
I am new to Microservices. (Learning phase). I have a question. We deploy microservices at cloud. (e.g. AWS). Cloud already provide load balancing and logs. And We also implement Load Balancing(Ribbon) and logs(Rabbit MQ and Zipkin) in Spring Boot.
What is the difference in these two implementation? Do we need both?
Can some answer these questions.
Thanks in advance.
Ribbon is a client side load balancer which means there is no any other hop in between your client and service. Basically you keep and maintain a list of service on your client.
In AWS load balancer case you need to make another hop in between the client and server.
Both have advanges and disadvantages. Former has the advantage of not having any dependency to any specific external solution. Basically with ribbon and service discovery like eureka you can deploy your product to any cloud provider or on-premise setup without additional effort. Latter has advantage of not needing an extra component of service discovery or keeping the cache of service list on client. But it has that additional hop which might be an issue if you are trying to run an very high-load system.
Although I don't have much experience with AWS CloudWatch what I know is it helps you to collect logs to a central place from different AWS components. And that is what you are trying to do with your solution.
I have a functioning application using Spring Boot, Rabbit MQ & MySQL DB locally. I'm curious, how I can upload this app to the AWS Environment and get it working seamlessly.
The only part where I'm lost is how to get RabbitMQ in the cloud? Any suggestions?
I see three options for your needs :
Use AmazonMQ managed service. This uses ActiveMQ under the hood, and supports the AMQP protocol (so you can continue to use the RabbitMQ client). Here's an article on how to do it : https://aws.amazon.com/blogs/compute/migrating-from-rabbitmq-to-amazon-mq/.
Use a third-party managed service (such as CloudAMQP). This is similar to the first option, but you can choose a RabbitMQ provider if you wish.
Install RabbitMQ on an EC2 instance and manage it yourself. This is the most flexible option, but it will require more effort on your part and it will probably cost more. I would recommend this option only if you have special requirements that are not met by using a hosted service.
In all cases, I would also recommend to use a messaging library such as Spring Messaging or Apache Camel to isolate your code from your messaging implementation. This will reduce the boilerplate code you need for messaging and allows you to focus on your application logic.
Where is Mule ESB intended to be on a cloud
SalesForce appears to be a huge offering.
I assume the Heroku component will always reside on a IaaS (probably AWS)
I am still confused on where the Mule ESB would actually sit. WOuld that sit inside an IaaS that Heroku might be on
WOuld the Mule ESB sit on a Legacy system to integrate the Heroku requests with the traditional legacy
Would Mule ESB sit on the Iaas to actually simulate a PaaS app server
If it does sit on an IaaS, would you have to installe the Mule ESB manually, or would it come as a cloud option on one of the IaaS, like Azure PaaS on Azure IaaS
Thanks
MuleESB is a container (just like tomcat, jboss are). IaaS providers could provide or not integration, to be honest I havent gathered to find out who provides it or not as I usually use Cloudhub.
However, the natural cloud choice for deploying an application to the cloud would be CloudHub, an PaaS for Mule Applications.
Mule ESB is intended to sit between apps as an integration bus. So data in one application can be replicated/transformed/transferred to another application. Mule ESB itself is an application container, so it will need to be installed on a server somewhere if you don't use Cloudhub.
You would develop an integration application with Anypoint Studio and deploy that app to Mule ESB or Cloudhub.
CloudHub itself is a way of deploying Mule Applications into a cloud computing platform (EC2 on AWS) without worrying at all about the infrastructure behind it. Most "Cloud" computing just means you don't worry about where it goes because everything can talk to everything anyway. So Mule can sit in the "Cloud" in a lot of different ways:
You can use your own datacenter and install it onto a server that
you own
You can create an Amazon EC2 Instance (or any other cloud
platform provider) and install Mule into that instance
You can use CloudHub to run your app directly and not instantiate your own
instances, letting CloudHub run that for you.
"Cloud Computing" is a way to abstract away some of the commodity infrastructure of computing. But you will always need a CPU/Memory/Storage/OS somewhere, what model you choose depends on how much you want to manage personally.