Benefits of having MID servers on AWS vs On-Prem.

[Avro Guha]

Benefits of having MID servers on AWS vs On-Prem. Which will be better and why ?

Right now we have MID servers on both AWS Cloud and On-Prem but I want to understand the benefits of having MID server on a cloud infrastructure compared to On-Prem. Cloud is good for applications but is it good for MID servers ? 

[David Sorf · Accepted solution]

Hi Avro,

I was expecting that you are having probably mixed environment and because of that you asked this question. From my perspective I would stick to main idea which is similar to this:

MID server is extension of ServiceNow to connect to local resources where you are not able to connect directly from cloud where ServiceNow SaaS is hosted. Even not mentioning VPN which is another option but used in very specific situations.

Therefore my suggestion would be to place MID server close to devices which you are connecting to and not move them far away and have VPN between your MID server cloud and your intrnal network, unless you have many MID servers hosted in public cloud and specific usage of that.

Advantage of scaling and bursting performance you would probably use in case you are running performance extensive tasks on MID server and then answer is YES = use cloud and flexible scaling and elasticity.

On other side when you using it for integrations (eg. LDAP, ODBC, REST or SOAP) then it is not so crucial for CPU performance as it mostly forward messages which retrieves via ECC queue. In that case I would go more for easier and safer networking solution and if you are still interested in elasticity and scaling on premise I would suggest you to use MID server running in docker container which gives you much more flexibility even onsite. 

Did I answer your question? Was it helpful or you need more help. If you ask generic question I can answer also in generic mode. Please let me know if interested in MID server running on premise in Linux Docker container. Can share that as well.

Kind regards,

David

[Gaurav Shirsat]

Hi Avro Guha

Benefits Of AWS:- The Most Efficient benefit of AWS is that Due to the huge complex network of Data Centers the Storage Facility of AWS is Strongest.

• A single pane of glass to manage the virtual services in public and private cloud environment including approvals, notifications, security, asset management, and so on
• The ability to re-purpose configurations through resource templates that help to reuse the capability sets
• Seamless integration with the service catalog, with a defined workflow and approvals integration, can be done end to end right from the user request to the cloud provisioning
• The ability to control the leased resources through date controls and role-based security access
• The ability to use the Service Now discovery application to discover the infrastructure components or the standalone capability to discover virtual resources and their relationships in their environments
• The ability to control and manage virtual resources effectively with a controlled termination shutdown date
• The ability to perform a price calculation and integration of managed virtual machines with asset management
• The ability to automatically or manually provision the required cloud environment with zero click options.

ON Premises:-

The  real benefit of On Prem is that you have COMPLETE control over your data, but you have to seriously weigh that with the manpower necessary to maintain all the servers and software required to run Service Now on a day-to-day basis.

Please go through those two attachments too.

Please Mark Correct and Helpful

Thanks and Regards

Gaurav Shirsat

[Avro Guha]

Hi Gaurav,

Thanks for sharing those details, but what I see is, you are talking about ServiceNow cloud design and benefits and then ServiceNow cloud discovery capabilities.

I am asking benefits of hosting MID server on cloud, which has nothing to do with ServiceNow cloud architecture.

Thanks

Avro

[Gaurav Shirsat]

Hi Avro Guha

Now I got what u r looking for.

please read the whole document.

 MID Server uses AWS and Azure APIs for retrieving the data. The reason I know  is that the (billing) data that clouds provide could be very extensive and would put a lot of strain on your instance without being pre-processed by the MID server first.

And yes, you could run it on your laptop.

Among  other things in Cloud Management the MID Server is used for :-

• processing the billing data from the public cloud providers. This is a very demanding task - offloading it primarily increases instance performance.
• Since Cloud Management now supports many more scripting languages besides JavaScript to interact with cloud   resources, the MID Server also functions as a run time environment for these languages.
• Much the same like power shell or ssh in orchestration, which cannot be executed on the instance but need a separate host with the respective capability.

There are many reasons we use a MID server in Service Now ITOM.

As Cloud Management is part of ITOM, we also have the capability to use a MID server.

• Placement. Best practice for MID servers is to put them in the data center they are to discover or map or orchestrate. This is no different in Cloud. If you are using the AWS West 2 region, then I recommend putting a MID server there. If you are also using the Azure West 2 region, then put a MID there. Now you have 2 MID's deployed. Sort through the MID capabilities so that your API calls to Azure go through the Azure MID and the ones to AWS go to AWS. This will improve the performance of the API calls for Cloud. Additionally, the MID will be in a position to perform post-provisioning tasks like hooking up to Chef or running Bash or Power shell scripts. If you think about what it takes to deliver and discover a VM end-to-end, then a MID server is required for many pieces of it: Chef or Ansible, interrogating the VM after provisioning, running scripts, getting IP's or reporting them to Infoblox, etc. So, proximity to those resources makes the most sense.                                                                                                        
• Scale. Technically speaking, if we were to pull out that "one piece" of the provisioning cycle and say, "Yeah, we can go from Our Cloud to Their Cloud," there would still be scaling issues associated with it. Your example of Billing is the biggest case. To consume a 1 gig billing file straight into the instance is asking a lot of your cluster. Service Now will happily charge you to upsize your instance, but my hunch is that you can get a few VM's for MID servers for a whole lot cheaper. For customers with large-scale cloud deployments, MANY MID servers are recommended for Cloud, Discovery, and Orchestration.                                                                                                     
• ECC. As it turns out, CMPv1 was based on Orchestration and uses the ECC Queue. We had a concept called "Node 0" where we did the ingestion for billing and cloud API calls inside the instance. However, this just wasn't practical from a scaling standpoint. It made the product "one off" from the rest of Orchestration.                                             
• Futures. The time it takes to process billing files is tremendous. We have been looking at alternatives, such as deploying Lambda functions to process AWS bills. Additionally, there's a limited value to having the data in the instance. In the future, we may keep the data stored in the cloud it is native to and make smart queries to a Lambda, RDS, Dynamo, or some other service to resolve the data. We have customers with AWS billing files of 10 G or greater per day. It simply doesn't make sense for us to spend processor time parsing 10G each day for (a) what it costs to store the data, even in "digest" form, in the instance, (b) the value of that data to the customer. I don't know what the future exactly holds, but I would say big changes in how we process billing will happen after London. Whether they ship in Madrid or New York or Orlando, I'm not sure. What I know is that this inefficiency is on our radar for improvement, and we have some top talent that has already taken a few "concepts" at what it might look like down the road.

I Hope this is useful

Please Mark Correct and Helpful

Thanks and Regards

Gaurav Shirsat

[IamGroot]

Hi Avro,

You most certainly be aware that MID server is a Java application running on Windows or UNIX host. Having a system(host) either on-premise or on AWS and having MID Server running on them will not be directly beneficial. My reasons: 

Lets see, system requirements of a MID server are not very high, and if you want to increase MID server performance the most you could do is increase its number of threads (200 highest) but that too doesn't guarantee that the performance will increase linearly.

Say, we have increased the thread count to 200, now it becomes resource-intensive and would need more fuel (CPU speed, memory etc), here cloud benefits (auto scale, burst performance etc) can kick in and provide the needed power to let MID server operate at  optimum level, but as ServiceNow says the performance increase might not be linear(with the increase/decrease of threads)

The alternative benefit (but complicated) we could have from hosting mid server(s) on Cloud is the ability to spin another/set of mid server(s) with similar configuration settings to handle peak loads and then reclaim it when no longer needed. Haven't done this yet but working on a valid use case to implement it.

But if one wants to keep it simple, I would suggest to continue to anaylze mid server performance and add necessary amount of mid servers as needed closest to the relevant systems.

Please Mark Correct and Helpful

Thanks

BR

Rajiv