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.
Related
i just arrived on this architecture, am doing a lot of research and i understood how it work in general but it's all theorical.
I decided to separate each step for the development of this architecture to start implementing so i can understand better these steps.
The first that i wanted to learn was the tenant provisioning, i wanted to apply it on AWS to mirror a production software example.
So, starting on that the common AWS service that i see most people using is AWS Cognito, but it's not clear in my mind the steps of the implementation, like how should i get the tenant data to onboard him in my app? Assuming it's tier based.
Should i have one database to store all tenants data separate from the application database?
I want to use microservices on this one because i think is better to onboard the tenant with different tiers and much more benefits.
Which AWS services should i use to make this process work? I'm not really asking about the implementation itself but a path to understand which services to use and how it connects with each other.
I hope i was clear about my doubts, english is not my mother tongue, sorry about that!
You are thinking in the right direction. However, there are decisions you need to make before diving into any saas service stack. I would start with
Planning my infrastructure - how many tenants/group.
the kind of tenant onboarding system you want
How will tenants onboard their users and manage authorization/authentication
Multitenant architecture, which needs to account for several things at the least like - DB model, shared vs isolated, data privacy, design keeping in mind industry data security standards
what will be your tenant deployment model. Remember one of the disadvantages of multitenancy is also slow time to market.
Your API stack needs to account for which apis needs to be multitenant and which are generic product offerings.
operational tool to monitor app health, client analytics.
how will you meter and bill the client and other non-functional decisions.
AWS offers good documentation to get started here : https://aws.amazon.com/blogs/apn/building-a-multi-tenant-saas-solution-using-aws-serverless-services/
I have a SaaS based multi-tenant monolith application (built with Django), that I want to divide into microservices based architecture. But I am not sure how to divide the application into correct partitions. And on what aspects should I take care of?
In case of monolith application, it's easy to understand that I have a tenant model that decides the schemas but how this will be done in microservices if I want each service to be multi-tenant? Or should I even make the services multi-tenant?
If you're already using OAuth and/or generating JWTs for user authentication/authorization, I'd recommend any new services that need tenant scoping to require a user access token be provided in requests just like your Django app. This lets you standardize how credentials and tenant scoping is expected to be passed, and verifying JWTs is a pretty easy process to implement.
That being said, it's also important to point out that you shouldn't require that services use access tokens or have any kind of tenant scoping at all. Not only is it possible that specific services don't require tenant scoping, but it's also possible that they might want to define a tenant differently from the main Django app (e.g. a simple tenant_id). For example, a payments service that only accepts a dollar amount and a credit card doesn't care what the tenant is and would be perfectly safe to call from the main Django application (of course you should prevent public access to the service too).
The best way to think about how new services should be designed is in a vacuum - without care for how other services are designed or how they store their data. Your service was built to perform a task and it defines for itself what parameters it needs to perform that task, how it executes that task, and how it stores the data it needs for future tasks. This independence from the design of other microservices in the stack is part of the power of designing service-oriented systems. It allows creators to pick the right tools for the job, and allows them to create meaningful features without needing to collaborate with dozens of team members that they often don't know.
Hope this helps, and good luck.
The closest I got to finding the actual difference is this article.
But I didn't understand what would make me choose one over the other and if microservices can also use a REST API and communicate via http.
I mainly didn't understand what a microservice is and if it can come instead of a webservice, other than the purpose of
breaking large software applications into loosely coupled modules
A microservice is a software architecture, which can be implemented with webservices.
A webservice is just a technology (one of many) for providing services over "web" or HTTP.
The main point is: a web service is (as the name announces) something that you would expect to "deal" with HTTP - in other words it does something in the context of the world wide web.
Whereas a microservice is not subject to the WWW context. At its core a microservice is supposed to provide one specific service - but there is no restriction to the http protocol for example.
Often a microservice implements a restful "web service" - but it doesn't have to be that way!
Beyond that, microservices are often meant as counter model to a huge monolithic application that serves many different kind of requests.
I got simple answer here that says :
Microservices is a new software architecture. It is based on web services. But it can be any service implemented as an independent feature that has its own database and can be deployed independently.
Microservices is an architecture wherein all the components of the system are put into individual components, which can be built, deployed, and scaled individually.
Microservices are the extension of web services.
Web services are typically vertical in nature(Provider-Consumer communication) whereas microservices are horizontal in nature
Microservices are seen as architecture due to the following.
microservices have belonged to one specific application.
microservices are addressing specific concern so that can be said as lightweight.
Changes are isolated in nature because the change in one microservice doesn't affect other (Ex. Changes done in login microservice does not affect the payment microservice)
Scaling individual microservices are easy.
Microservice usually has its own database.
Microservices : -
Microservice is a software architecture that can be used alongside web services. This method involves the splitting of large software applications into decoupled modules where microservices run unique processes and communicate through APIs. Its development can be through the use of either messaging, event-driven APIs, or using non-HTTP backed RPC mechanisms.
Microservices architecture saves the day when large applications fail or are down. If a particular service fails in communication, the overall application cannot be affected by the failure of a single module. The combination of microservices in Java, C#, Python, and mobile software development languages is possible. It can be independently deployed in service models for a business domain.
Web Services :-
A web service is just one of several technologies that can provide services over “web” or HTTP. As a specific type of service-oriented architecture (SOA), web services represent a web application’s functionality.
It defines a mechanisms interaction between an API and the main code by using standard HTTP protocol and universal formats of data representation such as XML, JSON, and so on. This allows software applications developed by different technologies to communicate with each other.
Web services are not involved with frontend development. They are not connected to any development languages or user device software platforms. The combination of different web services into a single one is also possible if written in different languages and for separate operating systems, just like in microservices.
Microservice is a subset of web services. Also used to name Architectures like "Architecture based on microservices"
Microservice is an artifact, not an architecture. Several world class companies know that
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-cfg-alb-shared.html
Before the microservice artifact, we had the classic web service or rest api. Even before this we had the Soap web services with XML.
So, as a summary when someone talk about microservice, he means a subset of web service with some characteristics that differentiate it from classic web services or rest api.
One main characteristic is a unique database or Database per Service
Here another characteristics from the goods like AWS. Some of them apply to rest apis or soap services. I will mark with bold some very specific for microservices.
https://aws.amazon.com/microservices/
Agility
Flexible Scaling
Easy Deployment
Technological Freedom
Reusable Code
Resilience
https://microservices.io/
Highly maintainable and testable
Loosely coupled
Independently deployable
Organized around business capabilities
Owned by a small team
https://www.baeldung.com/cs/microservices-db-design
Database per Service
CQRS
https://learn.microsoft.com/en-us/azure/architecture/microservices/design/data-considerations
Microservice is a piece of autonomous application that performs for a larger application architecture.
Web service is an approach to make the application available to other applications by web ui.
I've hosted my website on azure and now I want to schedule payments on a monthly basis. I am using Authorize.net for payments but I cannot use their recurring billing feature as it gives very little control. I've to perform checks in the database, make payments and update records. What should I use Azure Scheduler, Azure WebJob or Azure Functions a Worker Role?
Definitely not a Worker Role. They are very heavyweight and generally not worth the effort for a single, simple job like this.
Web jobs might be a good solution. It can run in the context of your web app, so you can use this with no additional cost. But you'll need to do some development with this - you have to create an app that calls Authorize.net.
If you only need to fire a single HTTP request, then using Azure Scheduler to schedule this HTTP action might be a good choice. You can configure the request itself (headers, payload) and it has error handling as well. But you might have to store sensitive information in the Azure portal, in the configuration of the scheduled job.
So I'd say forget about the Worker Role, then weigh simplicity against flexibility and development effort. That being sad, I would probably try it with the scheduler, and then move on to the WebJob, if I encounter something that is not feasible with the scheduler.
Edit:
Azure Functions can also be a good option - I'd say it's sort of a middle ground between the webjob and the simple scheduled option. It is part of the app services featureset, so it can run in the same appservice plan as the web app, so no costs. But here you have to code the http request to Authorize.net yourself as well. But Azure Functions is a lot more lightweight compared to webjobs - you do not have to create an exe (or ps script or whatever), you can just code the http request in a script editor inside the Azure portal. But you still have to do it yourself. This is a bit more flexible than the simple scheduled option though, which is something to consider when it comes to error handling.
So this is a good middleground, but I think it's still a lot of work given the complexity of the task (which is to fire a single HTTP request).
To get it working quickly, Logic Apps is a good choice. With Logic Apps, you can trigger it with a timer based on schedule you defined, use the out-of-box SQL/DocDB (depending on your exact scenario) to connect to your database. Although there's currently no Authorize.net connector available, you should be able to use the generic HTTP action to talk to its RESTful APIs. Most likely, you should be able to get this working very quickly. I'd also recommend submit a suggestion on aka.ms/logicapps-wish so we can track the request for Authorize.net connector, when available, is going to make this ever easier.
At my day job we have load balanced web servers which talk to load balanced app servers via web services (and lately WCF). At any given time, we have 4-6 different teams that have the ability to add new web sites or services or consume existing services. We probably have about 20-30 different web applications and corresponding services.
Unfortunately, given that we have no centralized control over this due to competing priorities, org structures, project timelines, financial buckets, etc., it is quite a mess. We have a variety of services that are reused, but a bunch that are specific to a front-end.
Ideally we would have better control over this situation, and we are trying to get control over it, but that is taking a while. One thing we would like to do is find out more about what all of the inter-relationships between web sites and the app servers.
I have used Reflector to find dependencies among assemblies, but would like to be able to see the traffic patterns between services.
What are the options for trying to map out web service relationships? For the most part, we are mainly talking about internal services (web to app, app to app, batch to app, etc.). Off the top of my head, I can think of two ways to approach it:
Analyze assemblies for any web references. The drawback here is that not everything is a web reference and I'm not sure how WCF connections are listed. However, this would at least be a start for finding 80% of the connections. Does anyone know of any tools that can do that analysis? Like I said, I've used Reflector for assembly references but can't find anything for web references.
Possibly tap into IIS and passively monitor the traffic coming in and out and somehow figure out what is being called and where from. We are looking at enterprise tools that could help but it would be a while before they are implemented (and cost a lot). But is there anything out there that could help out quickly and cheaply? One tool in particular (AmberPoint) can tap into IIS on the servers and monitor inbound and outbound traffic, adds a little special sauce and begin to build a map of the traffic. Very nice, but costs a bundle.
I know, I know, how the heck did you get into this mess in the first place? Beats me, just trying to help us get control of it and get out of it.
Thanks,
Matt
The easiest way is to look through the logs, but if that doesn't include the referrer than you may also want to monitor what is going out from your web to the app server. You can use tools like Wireshark or Microsoft Network Monitor to see this traffic.
The other "solution" and I use this loosely is to bind a specific web server to app server and then run through a bundle and see what it is hitting on the app server. You could probably do this in a test environment to lesson the effects on the users of the site.
You need a service registry (UDDI??)... If you had a means to catalog these services and their consumers, it would make this job of dependency discovery a lot easier. That is not an easy solution, though. It takes time and documentation to get a catalog in place.
I think the quickest solution would be to query your IIS logs and find source URLs which originate from your own servers. You would at least be able to track down which servers your consumers are coming from.
Also, if you already have some kind of authentication mechanism in place, you could trace who is using a particular service based on login.
You are right about AmberPoint. There are other tools that catalog the service traffic and provide reports showing what is happening to your services. Systinet, SOA Software and Actional also has a products similar to Amberpoint but Amberpoint has a free-ware version, I believe.