I believe I understand this in terms of hardware, where multiple individuals 'share' the same processing and memory for their solutions. But I've been looking at gmail and facebook, are those multi-tenanted solutions? Is it that as long as my solution can support multiple users, its multi-tenanted?
You can read this post concerning your question.
Multi-tenant vs multi-user
Any system may have multiple users. In a
multi-user system multiple users can
use the application (e.g. Exact
Synergy). The term multi-user does not
imply anything for the architecture of
the system. On the other hand, while a
multi-tenant system is a multi-user
system, multi-tenancy tells us
something about the architecture of
the system: namely that multiple users
share the same application and
database instance. Note that it is
possible to have a multi-user system,
which is not multi-tenant.
Related
I have a requirement to persist some data in a table (single table). The data is coming from UI. Do i need to write just the system API and persist the data OR i need to write process and system API both? I don't see a use of process API in this case. Please suggest. Is it always necessary to access system API through process API or system API can be invoked without process API as well.
I would recommend a fine-grained approach to this. We should be following it through the experience layer even though we do not have must customization to the data.
In short, an experience layer API and directly calling System layer API (if there is no orchestration/data conversion/formatting needed)
Why we need a system API & experience API? A couple of points.
System API should be more attached to the underlying system. And if
in case, in the future, it changes then it should not impact any of
the clients.
Secondly, giving an upper layer gives us the feasibility to add
different SLAs, policies, logging and lots more, to different
clients. Even if you have a single client right now it's better to
architect for the future. Reusing is the key advantage of these APIs.
Please check Pattern 2 in this document
That is a question for the enterprise architect in your organisation. In this case, the process API would probably be a simple proxy for the system API, but that might not always be the case in future. Also, it is sometimes useful to follow a standard architectural pattern even if it creates some spurious complexity in the implementation. As always, there are design trade-offs and the answer will depend on factors that cannot be known by people outside of your organisation.
We have 3 applications, all the three are different technologies, Python, PHP and ASP.net.
These applications interact with each other using web-services. We have also used Docker for Continuous Integration. Again all these app are on different vm's, python is on Linux and other two are on windows. I have few questions:
Will there be any issue while scalability?
There are a lot of API calls across all the 3 apps will that hamper the app performance?
From what I understand, your application consists of a number of microservices written in various languages (which implies the use of microservices architecture). Now, here are the answers to your questions:
There shouldn't be any issue in scaling-out the services since that's one of the prime benefits of microservices architecture. In fact, you have the freedom of scaling-out each service individually.
Well, there certainly will be some network overhead, which is the case in most applications that use microservices. The use of a high bandwidth internal network for the purpose will make sure the calls over network do not hamper the performance (more details here: https://softwareengineering.stackexchange.com/questions/275734/how-do-microservice-system-architectures-avoid-network-bottlenecks).
Can someone clarify for me exactly what permissions are required to read from and write to performance counters? I'm not seeing that I need any kind of special permissions to read/write performance counters and that's contrary to most resources I've found.
A training that I took, as well as most resources on the web, indicate that managing performance counters (creating, deleting) requires admin permissions, and reading/writing requires admin or membership in the local Performance Monitor Users group. I've verified the first, but as for reading/writing, I don't seem to have any problems doing this on my Win8.1 machine as a non-admin user. I can read perf counters using perfmon, PowerShell and the .NET API and write to custom perf counters using the .NET API, all as a non-admin.
Has this changed across OS versions? Or perhaps something in my corporate domain policy allows for it?
Only non-interactive logon sessions require the user to have membership in the Performance Monitor Users or Administrator groups in order to read performance counters.
Note that I am not a Microsoft employee, and I have not found any documentation that provides an authoritative statement of this behavior. I only determined this behavior through my own testing.
Specifically, when logging on with LogonUserEx, if the logon type is LOGON32_LOGON_NETWORK, LOGON32_LOGON_NETWORK_CLEARTEXT, LOGON32_LOGON_BATCH, or LOGON32_LOGON_SERVICE, then membership in one of the previously mentioned groups is required in order to read performance counters. However, if logging on with LOGON32_LOGON_INTERACTIVE or any of the other miscellaneous login types listed in the LogonUserEx documentation, then membership in one of the previously mentioned groups is not required in order to read performance counters.
Additionally, I determined that Vista RTM did enforce this restriction for interactive login sessions, and the current relaxed state for interactive login sessions was introduced in Vista SP1. While there are practically no users running Vista RTM today, this is good context to keep in mind if you read documentation or other advice that may have been written back then (or more recent advice that may have been blindly copied from older advice).
I have an web application that is separated in several components. For some reasons (pricing) I'm considering to deploy future components in different clouds.
Does anybody has references and experience on this to tell me if this is definitely not good? I know that components being in different networks will decrease the performance. At the same time, I do not like the idea of losing the power of choice where the new components will be.
Must Microservices based systems be all in the same network? How do you handle this problem?
Having worked with multiple services in the past I can tell you that services are made to work across separate networks. This is why there are security protocols like CAS, SAML, OAUTH, HTTPS, and HMAC to name a few.
So as long as you are able to deal with the management of the networks, and you have good security around your services (and I assume you do), then I would not be worried about breaking some unspoken microservices rule. Remember that microservices, if written well and are useful, are expected to be used across the Internet, especially for the Internet of Things, so they are expected to be used across multiple networks.
When you start trying this, I would pay very close attention to the bandwidth charges. AWS as an example you are ok if you are in the same region. Bandwidth between services will not cost much if anything. Lets say you use AWS and Google Cloud. Now you will be paying for the bandwidth between the 2 providers.
As a suggestion I would look at Docker as a possible solution to your problem/concern of vendor lock in.
You would be restricted to providers that support docker but in theory you could migrate quickly between providers easily since your application would be abstracted from each cloud providers architecture.
Performance, will take a hit with anything leaving the providers data center. I suppose with some investigation you might try researching providers that use a common internet exchange. This would help minimize a few hops at least.
I'm in charge of building a complex system for my company, and after some research decided that Camunda fits most of my requirements. But some of my requirements are not common, and after reading the user guide I realized there are many ways of doing the same thing, so I hope this question will clarify my thoughts and also will serve as a base questión for everyone else looking for building something similar.
First of all, I'm planning to build a specific App on top of Camunda BPM. It will use workflow and BPM, but not necessarily all the stuff BPM/Camunda provides. This means it is not in my plans to use mostly of the web apps that came bundled with Camunda (tasks, modeler...), at least not for end users. And to make things more complicated it must support multiple tenants... dynamically.
So, I will try to specify all of my requirements and then hopefully someone with more experience than me could explain which is the best architecture/solution to make this work.
Here we go:
Single App built on top of Camunda BPM
High-performance
Workload (10k new process instances/day after few months).
Users (starting with 1k, expected to be ~ 50k).
Multiple tenants (starting with 10, expected to be ~ 1k)
Tenants dynamically managed (creation, deploy of process definitions)
It will be deployed on cluster
PostgreSQL
WildFly 8.1 preferably
After some research, this are my thoughts
One Process Application
One Process Engine per tenant
Multi tenancy data isolation: schema or table level.
Clustering (2 nodes) at first for high availability, and adding more nodes when amount of tenants and workload start to rise.
Doubts
Should I let camunda manage my users/groups, or better manage this on my app? In this case, can I say to Camunda “User X completed Task Y”, even if camunda does not know about the existence of user X?
What about dynamic multi tenancy? Is it possible to create tenants on the fly and make those tenants persist over time even after restarting the application server? What about re-deployment of processes after restarting?
After which point should I think on partitioning of engines on nodes? It’s hard to figure out how I’m going to do this with dynamic multi tenancy, but moreover... Is this the right way to deal with high workload and growing number of tenants?
With my setup of just one process application, should I take care of something else in a cluster environment?
I'm not ruling out using only one tenant, one process engine and handle everything related to tenants logically within my app, but I understand that this can be very (VERY!) cumbersome.
All answers are welcome, hopefully we'll achieve a good approach to this problem.
1. Should I let camunda manage my users/groups, or better manage this on my app? In this case, can I say to Camunda “User X completed Task Y”, even if camunda does not know about the existence of user X?
Yes, you can choose your app to manage the users and tell Camunda that a task is completed by a user whom Camunda doesn't know about. And same way, you can make Camunda to assign task to users which it doesn't know at all. This is done by implementing their org.camunda.bpm.engine.impl.identity.ReadOnlyIdentityProvider interface and let the configuration know about your implementation.
PS: If you doesn't need all the application that comes with Camunda, I would even suggest you to embed the Camunda engine in your app. It can be done easily and they have good documentation for thier java APIs. And it is easily achievable.
2. What about dynamic multi tenancy? Is it possible to create tenants on the fly and make those tenants persist over time even after restarting the application server? What about re-deployment of processes after restarting?
Yes. Its possible to dynamically add Tenants. While restarting the engine or your application, you can either choose to redeploy / or just use the existing deployed processes. Even when you redeploy a process, if you want Camunda to create a new version of the process only if there is a change in the process, that's also possible. See enableDuplicateFiltering property for their DeploymentBuilder.
3. After which point should I think on partitioning of engines on nodes? It’s hard to figure out how I’m going to do this with dynamic multi tenancy, but moreover... Is this the right way to deal with high workload and growing number of tenants?
In my experience, it is possible. You need to keep track of various parameters here, like memory, number of requests being served, number of open connections available etc., then accordingly add more or remove nodes. With AWS, this will be much easier as they have some of these tools already available for dynamic scaling in / out nodes. But that said, I have done this only with Camunda as embedded engine application(s).