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.
Related
Hi I am new to microservices architect and have few questions related to its deployment on production environment.
I am using spring boot microservices and want to deploy them on any open source plantform like kubernetes.
Previously I have all deployments on local servers(conventional hardware). So I don't want to move to any cloud service for now, its part of future planing. I want to have a deployment strategy that should work with servers and in future when I want to move to cloud, effort should be minimum. I need some expert suggestions. I have created a POC of deploying apps to kubernetes with minikube where I am using docker container. But for docker private repositories I need to buy their enterprise services.
And for any cloud platform I also need invest money.
What are the other choices where I can deploy microservices on my conventional hardware.
Caas vs PaaS, CF vs K8s
There are Two ways of doing it. Actually three, the third being not moving to cloud. If moving to cloud, you do it either via OCF or via Docker. for OCF, we have lot of providers including Pivotal. For Docker, you go via Kubernetes. Again there are a lot of providers, AKS, PKS, GCP, etc.
The choice is always yours.
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.
I'm building an event-driven microservice architecture, which is supposed to be Cloud agnostic (as much as possible). Since this is initially going in GCP and I don't want to spend a long time in configurations and all that, I was going to use GCP's Pub/Sub directly for the event queue and would take care of other Cloud implementations later, but then I came across Spring Cloud Dataflow, which seemed nice because these are Spring Boot microservices and I needed a way to orchestrate them.
Does Spring Cloud Dataflow support Pub Sub as it's event queue?
Would it make my life easier in terms of configuration and setup going that path, rather than choosing a non native broker?
It'd be useful first to unpack the Spring Cloud Stream's "binder abstraction" because it is using this framework, you'd have a portable event-driven streaming application, which can run locally in your laptop or any cloud of your choice against the desired message broker.
Learn more about the binder-abstraction here. Here are all the available binder implementations of choice. Google PubSub is an option, and it is maintained by Google here.
Now, let's talk about Spring Cloud Data Flow (SCDF). Once when you have built the streaming applications, you could use SCDF to design+create a data pipeline made of such applications. There's the option to mix and reuse the collection of utility applications that we build, maintain, and release as well. The utility applications can be packaged with Google PubSub or other binders. More details here.
When you deploy the data pipeline, SCDF will resolve and download the individual applications to deploy them natively on platforms like Kubernetes or Cloud Foundry. We have users doing the same in a variety of cloud infrastructure (VMs, Bare-metal, EC2, Rackspace, etc.), including DIY platforms, too.
While also automating the deployment of the applications, SCDF will automate the configuration setup based on naming conventions derived from stream/task and application names as a combination. So, when the apps bootstrap, they would have automatically received the connection configurations (from SCDF) and as well the destination/topic to connect to along with the other metadata to reason through a collection of apps as a "stream" or a "task/batch" data pipeline. This allows you to monitor and manage the pipelines centrally.
Lastly, there's the native ability in SCDF to rolling-upgrade/rolling-downgrade 1 or many applications in a data pipeline without impacting the upstream or downstream consumers in production. More details here. There's a webinar recording (demo starts at ~41.25) on how to do with CI/CD automation.
At the moment we have some monolithic Web Applications and try to transfer the projects to an microservices infrastructure.
For the monolithic application is an HAProxy and Session Replication to have failover and load balancing.
Now we build some RESTful microservices with spring boot but it's not clear for me what is the best way to build the production environment.
Of course we can run all applications as unix services and still have a reverse proxy for load balancing and failover. This solution seems very heavy for me and have a lot of configuration and maintenance. Resource Management and scaling up or down servers will be always a manually process.
What are the best possibilities to setup production environment with 2-3 Servers and easy resource management?
Is there some solution the also support continuous deployment?
I'd recommend looking into service discovery. Netflix descibes this as:
A Service Discovery system provides a mechanism for:
Services to register their availability
Locating a single instance of a particular service
Notifying when the instances of a service change
Packages such as Netflix's Eureka could be of help. (EDIT - actually this looks like it might be AWS specific)
This should work well with continuous delivery as the services can make themselves unavailable, be updated and then register availability again.
I understand JMS spec allows me to write MDBs. Then I can deploy them on an appserver like websphere or jboss (and they have inbuilt implementation of JMS provider which is Java EE compliant). The question is when to use a full fledged product like IBM WebSphere MQ or ACtiveMQ instead of using App server's inbuilt JMS provider.
This appears to be a good reference to what you are asking, specific to IBM products but can be generalized to using an application server integrated messaging system vs a standalone messaging system - http://www.ibm.com/developerworks/websphere/library/techarticles/1109_wallis/1109_wallis.html
A built in JMS provider, such as WebSphere SI Bus, possibly others, are built for JMS messaging.
WebSphere MQ (MQSeries), ActiveMQ etc. have clients for multiple languages and are built for applications other than Application Server hosted applications to connect to it (C++, Java SE, Python, etc).
Say you want a local messaging server on the same physical server (or network?) as a non JavaEE application, you don't want to install a Java EE App Server, but want a stand alone messaging server instead (WebSphere MQ, Active MQ).
That said, ActiveMQ, for instance, is the messaging system inside Apache Geronimo. So there is overlapping here.
Then there is a whole discussion about management, clustering and security. Java EE messaging systems are pretty much optimized to follow the cluster layout of Java EE. In other deployment scenarios, the clustering might be optimal in other ways, such as cluster for different security zones. Also security models and management tools might be different in stand alone messagaing servers.