This is about a Reporting Server solution.
I need some advice to choose a product, which will hold a SQL Database Server and a Web Service App (one that will make a call to a stored procedure and run an SSIS package - not much processing here -) and SSRS. I'm not familiar with this, it needs to be available 24/7, as I said there's no much processing just synchronizing data (few hundreds of thousands of records), what do you suggest me?
Requirements:
SQL Server Enterprise 2017: this will hold the database and execute
the SSIS package.
We have an SSIS package that will be executed from a .Net Web Service app which will execute a Stored Procedure on users demand.
The Server needs to run Reporting Services (SSRS).
Considerations:
Storage: Database will hold around 750K records (all text).
Bandwidth: There will be synchronization (data retrieval or updates
only) with an external system.
Use: the client has asked to consider a dedicated instance since they
will use it at their own discretion.
Now the only issue is, as far as I know, we can't call a Stored Procedure from the outside system (outside the server), or at least I have not found a way to do that, that's why I want to host both solutions in one place, so the Web Service App can call the Stored Procedure Locally.
So now I'm wondering, what should I do? should I leverage a full VM? how much will cost?
If you want to do PaaS and not have to manage infrastructure, take a look at the Azure App Service Environment is an Azure App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale. This capability can host your:
Windows web apps
Linux web apps
Docker containers
Mobile apps
Functions
For SQL you can use Azure SQL Database Managed instance,a new deployment option of Azure SQL Database, providing near 100% compatibility with the latest SQL Server on-premises (Enterprise Edition) Database Engine, providing a native virtual network (VNet) implementation that addresses common security concerns, and a business model favorable for on-premises SQL Server customers. This is a fully isolated instance of SQL server.
I suggest you host a static site on blob, an Azure function on consumption model to make calls to SQL database and a SQL database. Of course, there are alternative architecture you can use, however all depends on detailed requirements.
Related
I need to deploy multiple web jobs for my current project. However, none of them will be too resource intensive, so I will be using the same App service plan. I am trying to decide between
Create separate App Services per Web Job and deploy them all into the same App Service Plan OR
Create a single App service, and deploy multiple instances of the Web Job into that same app service, with different web job names to make them unique
I know this answer may be based on different opinions, but I am hoping you could share some things to consider. For e.g., one advantage of #1 is that it is easier for me to deploy each web job separately in that option. Any other things that I should consider?
Thanks!
#Snooks, Web Apps are designed to run multiple Web Jobs and there is no platform limit (although there might be practical limits depending on what your web job is doing). My suggestion would be to go with route 1 from a management perspective. This will make life easier when navigating through the portal etc.
A third option to consider as well would be Azure Functions (serverless). While many customers create app services that aren't hosting any web site just to use for the web job capability, the initial intention was for app services services to serve web sites and then also have automation capability via web jobs.
Since web jobs became so popular, Azure Functions was born to provide a more focused product on task/job automation (and much more) while running on a serverless platform. This means you only pay for what you consume, whereas with a web app, you pay a flat rate each month, no matter how much or how little you consume.
If your requirements state you must go the route of Web Jobs, I would certainly go with route 1 just to avoid having to manage multiple apps. If you are willing, I think it's worth looking into Azure Functions to see if it meets your needs.
I am new to cloud and still learning GCP, I exhausted almost all my free credit for GCP within 2 months while learning different modules.
GCP is great and provides a lot of things to ease the development and maintenance process.
But I realized using different modules cost me a lot.
So I was wondering if I could have a big VM box, install MySQL, Docker, and Java and React required components by myself, I can achieve pretty much what I want without using extra modules.
Am I right?
Can I use the same VM to host multiple sites by changing ports of API, or do I need to have different boxes for that?
Your question is out of GCP domain but about IT architecture. You can create a big VM with all installed on it. But you have to manage it by yourselves and the scalability is hard.
You can also have 1 VM per website, but the management cost is higher (patching and updgrade)! However you can scale with a better granularity (per website).
The standard pattern today is to explode your monolith server into dedicated services. The database on a specific server, the docker and Java in another one, and the react in a static component (like Google Cloud Platform).
If you want to use VM, you can use GKE and you containerize your application. It's far more easier to maintain your VM with an automatic tool like K8S.
The ultimate step, is to use serverless and/or full managed solution. Cloud SQL for your database, GCS for your static content, and App Engine or Cloud Run for your backend. Like this, you pay as you use and if you website is not very used, you won't be charged on it (except for the database).
What I already have:
An asp.net core on .NET framework project which uses DocumentDB as its storage
An Azure WebJob which listens to a queue that my web project writes messages to for e-mail sending and other processing
Successfully deployed and running on Azure
This all works fine. In addition to the web project there is a Model and Data class library to separate the application into layers.
Currently, the web application invokes a web service and will save the result (a quite large xml document) in the cache and keep it there for 24 hours. This is not ideal as it takes a long time the first time. What I want instead is a nightly batch job which invokes this web service and then stores (overwrites) the response into persistent storage which the web application will then use instead.
I'm confused about which Azure "service" to use for this. What I have started on so far is another WebJob and the idea is to use the same DocumentDb storage to persist the web service response every night. However, I already have all the database repository etc. set up in the web application (Data class library), is it ok to just reference this project from the WebJob instead of having to rewrite some of the same code in the WebJob?
Is it better to use some of the other Azure storage options for this WebJob instead? Like Table Storage, Blob Storage etc? Basically the structure of the data received from the web service is very simple. For each item I just need to store a url, a title, description and unique product id. Obviously the web application needs to access this storage too by simply looking up the product id, and never writing to this storage.
Also, I'm not entirely sure if there is a better alternative than Azure WebJobs for this task, but it seems like the right approach.
Any feedback is appreciated. I'm generally just confused/overwhelmed by all the different services that Azure provides.
I'll answer some of your questions...
A webjob works fine for this task. If you have a webservice that is always on adding another webjob seems like a good idea. If your webservice isn't always on, you could have a look at Azure Functions. Azure Functions is sometimes called webjobs 2.0.
As for storage in Document DB there is a file size limit for 2MB (give or take). So, you'll have to find another solution there. I think that Azure Tables also have limitations on storage size, so you'll have to split the file in smaller chunks. So, recommended solution is to go with Azure Blobs.
You'll find some good reading in this answer regarding Blobs vs Tables vs SQL
- Getting started with Azure storage: Blobs vs Tables vs SQL Azure
The recommended hosting stack for a Gyroscope application is Linux, Nginx/Apache, PHP, MySQL. What are the drawbacks of running Gyroscope on IIS and Microsoft SQL Server?
Gyroscope is written in PHP. So any dynamic web server that can run PHP would work. IIS can be extended to run PHP via ISAPI. The server can be optimized so that the performance and reliability is on par with Nginx or Apache.
Gyroscope comes with a collection of interchangeable database connectors. They are in the "connectors" folder in a fresh download (read: before deployment). Note that these files are not created equal. When a Gyroscope application is written for MySQL, one cannot simply change sql.php.mysql with sql.php.mssql. This is because MySQL and MSSQL has syntax differences.
As a framework, Gyroscope provides places for you to program the database interface. It works with any database or logical data storage such as a RESTful API. SQL databases are similar enough so it is tempting to "port" the code. In fact, most of the code can run without any changes. The code generator takes care of 90% of the cases. The main incompatibility is how records are paginated. In MySQL, "limit 10,10" returns the 10th to the 19th records. The syntax in MSSQL is more convoluted, and has to be written differently.
Unless a .NET application needs to co-exist on the server, there is little reason why IIS should be used. Gyroscope, or any PHP implementation, works better with the boost of HHVM and HAProxy.
Why would anyone use WSO2 Application Server instead of other application servers?
I rather encountered only problems with it, mainly due to class loading issues, so I would appreciate if someone could point out what are the advantages or the use cases when using WSO2-AS really makes a difference.
I can see the benefits of other standalone WSO2 products, but as far as the AS is concerned, I would rather rely on more lightweight servers and just package the libraries I need.
There are number of advantages on WSO2 Application Server.
1.) It provides in-built support for multi-tenancy, in case if you have isolated departments like organization there is no real need to have number of server instances you could simply create a new tenant.
2.) Automatic lazy loading support for tenants, web applications and web services. In a production system a particular tenant/web application/web service can be ideal for sometime it's a waste to allocate hardware resources continuously to such ideal applications specially if you use IaaS. WSO2 application server can detect such ideal tenant/web application/web service and release their resources and tenant/web application/web service will load again when a new request dispatch to the particular tenant/web application/web service.
3.) Wide range of deployment options, support to deploy on-premise, public or private IaaS , public or private PassS such as Apache Stratos. An an example one can deploy his application into WSO2 App Cloud (http://wso2.com/cloud/app-cloud/) instantly without downloading anything, later he can get same experience one of above platforms.
4.) Deployment synchronization feature, a clustered environment you may have very large number of nodes and upgrading application version and configuration changes across the cluster can be headache. Using Deployment synchronization feature you can modify only one node labeled as manger node and Deployment synchronization will take care about synchronize changes across the cluster automatically and consistently.
5.) When developing applications on WSO2 Application Server you can leverage carbon platform level features such as identity, registry, logging, distributed caching, multi-tenancy etc. As an example one can use identity features provided by the platform to mange users, roles permissions also for authentication and authorization without write something own.
6.) Inbuilt support for security standards such SSO among other WSO2 products.
7.) In-build monitoring capability for web services and web application through WSO2 BAM.
8.) Enhanced and rich dashboard for applications and services which facilitate to basic statistics, application management, security wizards, code generations, Try -It tools, run time logging configurations etc.
9.) Enhanced classloading mechanism (starting from AS 5.1.0), within one Application server instance you can have number of virtual server environments per application level. As an example one can specify an application run on minimal Tomcat mode or can assign to run Carbon mode which is ( Tomcat + Carbon platform).
When it come to your specific issue if you can specify your Application Server version and elaborate more on your classloading issue I can provide you more specific answer.
Having said above I want to mention that I'm from WSO2.