I am new in Service Now platform, developing a custom app using the service portal and I am looking for some architectural advice from experts.
My storyline is my service is gonna serve different companies as per their requirements by easy codebase maintenance. for example, I am having a base app which has some concrete requirements that fit for all companies, but there will be some other features for company specific, like feature A for company A, feature B for company B and so on. So my initial plan was like classic software development that is to have a single codebase using git that will have multiple feature branches that will deploy to multiple instances. But sometimes some situation where I might need to merge the branches that is not possible now. My question here is there any alternative way to do that? Other possible scenarios here is should I go with a single instance with ACL based data separation? (but that not feels scalable to me cause the amount of the data will be huge after some time) or is that possible to apply regular SAAS architecture like multitenancy(single app with multiple databases) with some configuration wise feature separation?
Thanks in Advance.
Related
I many articles where writers show how to deploy a Laravel app/website on shared hosting they discourage doing that. In some other quora questions where the answers state that it is possible but has some security risks. So what security risks does this practice implies.
The honest answer depends on the type of project and-or customer (agency vs interprise).
If you are working for a smaller project and there is no on-going development (extra possible invoicing) to it I will recommend using a shared hosting.
But if your budget is pretty high and that application needs to grow, handles sensitive user data, automated deployments, unit testing together with Docker and Vagrant for local development. I would recommend using AWS or digital ocean.
The biggest problem using AWS is that it pushes the responsibility to you in keeping the operating system and PHP-version up-to-date.
With interprise customers, I would recommend using services like:
Use a security scan (https://detectify.com/)
Use a Firewall (https://www.cloudflare.com/en-gb/)
Basically it all depends on the type of customer you are dealing with.
But for a really small / tiny projects, just use a shared hosting and basically never forget to use CSRF, ReCaptcha, throttling requests, ... Be smart about it.
I am currently investigating possible tools with which to develop a workflow solution for a company that would be used by the staff to process incoming work and ensure incoming work is routed to the correct people for evaluation and are authorised by the relevant managers before work commences, and that the work is signed off when complete.
Is Microsoft Power Automate the right tool for this kind of work, or is it [simply] a tool for automating ones own personal tasks? I'm looking for something that could be used to develop a tool that would be used by everyone in the company.
I've looked at the various videos but it looks like it might be just something for automating ones personal tasks rather than building something to be shared. Is this correct or can it be used as a software development tool for developing a custom solution for a company?
Look at Business Process Flows (BPFs).
https://learn.microsoft.com/en-us/power-automate/business-process-flows-overview
The following text is from "Why use business process flows?" on the above link:
Business process flows provide a guide for people to get work done.
They provide a streamlined user experience that leads people through
the processes their organization has defined for interactions that
need to be advanced to a conclusion of some kind. This user experience
can be tailored so that people with different security roles can have
an experience that best suits the work they do.
Use business process flows to define a set of steps for people to
follow to take them to a desired outcome. These steps provide a visual
indicator that tells people where they are in the business process.
Business process flows reduce the need for training because new users
don’t have to focus on which table they should be using. They can let
the process guide them. You can configure business process flows to
support common sales methodologies that can help your sales groups
achieve better results. For service groups, business process flows can
help new staff get up-to-speed more quickly and avoid mistakes that
could result in unsatisfied customers.
You can create broad, or detailed, BPFs, to cover company wide business processes. You can also call on separate normal flows, validations, and more. There are a lot of ways you can use a BPF to move things forward in a company.
Power Automate (aka MS Flow) is a low code/no code business workflow management or process orchestration software, getting more power with Robotic Process Automation & Virtual Agents inclusion.
The concept is having variety of connectors for all the available SaaS solutions (name anything like Dynamics, Salesforce, Oracle, SAP, Twitter, Facebook, Exchange mailbox, OneDrive, SharePoint, etc) to act as both Trigger and Action to achieve what we want. At worst case we can use REST APIs to complete the project setup.
Community demo the usefulness of it by showcasing the automation of personal stuffs but it has more. MS Flow is the alternate for Dynamics CRM 365 workflow and SharePoint workflow as well. Definitely it’s an enterprise candidate to solve company wide problems like onboarding, approvals, and many other workflow solutions.
Personally I would look at Azure Logic Apps for that level. It has just about the same connectors as MS Flow , but with the addition of better management, troubleshooting and extensibility capabilities and you get all the benefits of security in Azure and compliance good stuff that companies would need
We are planning to use Azure Service Fabric for a data-oriented multi-tenant application. Typically 100+ customers each with 5 - 100 users.
Looking at the documentation, I concluded that the best approach is to use an Application instance for each customer, rather than trying to use Profiles to achieve multi-tenancy.
Is this the best way to go ?
An application instance for each customer is a good way to handle multi-tenant situations on a single cluster, yes. There are Service Fabric applications that do this today (Azure DB is a notable one).
Here are some things you get with this approach:
Each application instance gets its own process, which means you have process-level isolation per tenant.
Each application instance is composed of one or more services, which means you can use a "microservices" architectural style for the application.
Each application instance can be created with unique parameters, so you can have various setups for each tenant. For example, you can do things like offer higher availability to certain tenants by using higher replica set size settings for the services in their application instance, or you can offer higher data capacity by using a higher partition count setting for the services in their application instance.
These are generally good things for data-oriented multi-tenant situations but whether or not its the best way to go of course depends on your specific requirements.
I'm working on a project that is set up as multi-tenant, separate users, data stores, etc. However, as I look further into different scenarios, I see things that may not mix well with multi-tenancy, or at least as I understand it.
Tenants can be hierarchal
Company A
West Region
East Region
Company B
Campus A
Campus B
Company C
Tenants can provide resources to another resource
Company A creates a resource
Company A shares it with Company B with specified permissions
Company C shares a resource with Company B
Company B can now use resources provided by Company A and C
I'm not tied to multi-tenancy, but I want to make sure that whatever pattern I choose, I am following the best practices of the pattern.
Is hierarchal multi-tenancy defined well enough to actually attempt? I don't see much online about it, except for a proposed Open Stack project and a research paper in only 2014. I could potentially use hierarchal users instead, but there are, of course, other benefits to tenants.
Now given that I want tenants to be able to share resources, in any direction, maybe I don't need hierarchal tenants. Maybe a need a normal flat multi-tenant pattern with just an added layer of sharing. One tenant would share to another tenant or maybe a user in another tenant.
In the latter, each user seems like they become their own tenant, with their own data. It seems like it is more and more like a social network. in Facebook, I can share things to others, they can share things to me, there is no direct hierarchy, but brands will make pages that reflect the idea of a hierarchy, without actually having one. For instance, Microsoft has Microsoft, but also Xbox, Xbox Support 1, Xbox Support 7, Windows, Bing, etc.
So I've started here with a multi-tenant architecture in front of me and now I'm thing a business grade "social network" is what I really need.
Do either of those tracks make sense? Any thing you would have me change or consider?
In cloud computing, multi-tenancy (MT) is commonly accompanied by tenant isolation. If we take the Wikipedia definition, MT is independent of sharing.
In an MT architecture, one instance of a software serves multiple tenants (or groups of users). This is in contrast to multi-instance software in which multiple instances of a software serves multiple tenants.
The main benefit of the MT architecture is of cost - software updates can be done on the single instance to benefit all of the tenants. MT software provides a common base of functionality for tenants, but commonly have interfaces that allow each tenant to customize branding & workflows.
Your project looks to be MT with sharing capability. Let's assume each Company wants to be able to share access to some resources. The architecture then should have sufficient flexibility for the tenant to be able to control access to resources. The underlying frameworks should be fast, secure, and reliable, and auditable.
Since your focus is on sharing flexibility, it's important that the architecture supports letting tenants define access to resources the way you and they want - tenant to tenant, or tenant to some user.
In my opinion, I would consider starting with a "default-deny" architecture - one that doesn't share anything by default, and allow the tenants to setup rules for access to resources.
Short version: Multi-tenancy is generally independent of interactivity.
In medium to large organizations what team or group typically support middle tier components like Oracle Application Servers?
(Unix Team, DBA Team, Or Application Development/Support Team)
In a client server application design the delineation of ownership between the server and the client is very clear. In the client server case the Unix Administrators manage the servers and the development support team manage and support the clients. (and the DBA's support/manage the database)
Recently at our shop the lines have become blurred; the introduction of an Oracle application Server (OAS) has popped up;
OAS seems to require a very unique set of skills but also show some similarity to the client server skills. (part Unix Admin, Part Dba, Part Application Developer/Client Support)
What have others done when confronted with this kind of challenge......??
Does a completely new team form that exclusively supports the Middle Tier??
Our It Group has 3 Unix Admins; 3 Application Support staff; 3 Dba's to give the perspective of the size of the teams....
There are a couple of different options, to my mind:
1) Roll it into the application development/support team as this is part of an application that isn't necessarily where only Admins are useful. There should be a separation between development and support to some extent as different tools may be used and some may have a stronger skill set for one over the other such as if one prefers investigating things then support may be a better fit.
2) Platform management team which is a separate group where there is a separation of the layers involved in the applications the company produces. I used to work for a company where the middle tier and back-end were managed by one team that was separate from the Applications group which seems appropriate if there is the plan of having that middle and back-end tiers become a platform for the company to pitch to other companies to use how they see fit in terms of making their own applications on top of this API.
I can see a logic in using either method depending on how one sees what the IT arm offers in a sense.
For large organizations, you generally eventually get to a point where there are dedicated teams to manage the middle tier web servers and application servers.
The problem for smaller organizations generally comes that when you first deploy the app servers, there may not be enough admin work to justify a separate person in that role, at which point you have to cobble together time from other teams. It's not particularly unusual for DBAs to manage the app server (particularly for Oracle DBAs managing Oracle Application Servers). It's also not particularly unusual for the Unix admins to manage the app server. Either way, though, some of the work will inevitably benefit from input from the other team.
IMHO there should be a single "Oracle" team, comprising DBA's, unix admins, application admins, and even a network person for big installations. There is really only one system, although it has multiple tiers and technologies. You do not want four teams all passing the buck round when a system fault occurs. Ask me how I know ;)