Multi-tier and/or ditstributed apps, do they have the same meaning ?
When we talk about layers in these apps, is it physical layers (database, browser, web server,...) or logical layers (data access layer, business layer,...) ?
Maybe these two sentences do convey intuitively the distinction between distributed and multi-tier:
Distributed: You replicate the processing amongst nodes
Multi-tier: You split the processing amongst tiers
In one case, the same processing is replicated over several nodes. In the other case, each tier has a distinct responsibility and the processing running on each tier differ.
Both notions are not exclusive: you can have non-distributed multi-tier apps (if there is no form of redundancy/replication), distributed apps which are not multi-tier, but also multi-tier apps which are distributed (if they have some form of redundancy).
There would be a lot more to say about the distinction, but the difference (to me) is essentially there.
ewernli has the mostly correct answer here. The only missing piece from the original question concerns physical and logical layers.
From a distributed and/or multi-tier perspective whether the layers are physically separate or just logically so is immaterial. Meaning, it doesn't matter. You can create multi-tier and even distributed applications which resides entirely on the same machine instance.
That said, it is more common to separate the tiers into different machines built specifically for that type of load. For example, a web server and a database server. Or even a web server, several web services machines, and one or more database servers.
All of these features, distributed, multi-tier, and/or load balanced with logical and/or physical layers are just features of the application design.
Further, in today's world of virtual machines, it's entirely possible (and even likely) to set up a multi-tier, distributed, and load balanced application within the confines of a single real machine. Although, I'd never recommend that course of action because the point of load balancing and distributed services is usually to increase availability or throughput.
Multi-tier means that your application will be based on multiple machines with different tasks (Database, Web application, ...). Distributed means that your application will run in multiple machines a the same time, for example your website could be hosted on 3 different servers.
For multi-tier applications we speak generally about physical layer. But in every application you can/should have different logical layers.
Related
I have a question regarding best practices with containers. Is it an anti-pattern to have a database in a container?
I've seen implementations of DBs in containers a couple times now and I'd love to get y'all's thoughts on it. From my understanding, containers should be lightweight and effectively stateless. They should also operate as cattle, not pets (as in, easily destroyed and you don't rely on one container staying to perform business functions).
From what I know of DBs, they aren't usually cattle, and depending on the application they aren't lightweight. They're also pretty much inherently stateful.
It's pretty clear that I'm skeptical of DBs being hosted in containers, but I'd really love to hear what y'all think. I'm not too familiar with DBA work so hearing from those with more experience (especially if you've implemented it and have experiences you can talk to) would be great.
Its a great question, though its a bit broad. It completely depends on what exactly you are running and how you plan your workloads.
The thing to keep in mind about containers is that there really isnt any magic here. Containers ultimately boil down to kernel level (cgroup) limits imposed on a process and the orchestration layer (eg Kubernetes or CloudFoundry Diego) are responsible to reacting to when the container is killed off for crossing these limits (eg out of memory).
In general, there are a number of high level factors to keep in mind
What are the data durability requirements for this project
What are the workloads (eg hourly spikes, unpredictable load, etc)
What is your uptime SLA and can you clients handle failing over to new masters in your data tier gracefully
Most importantly, is containerization the right pattern for what your project's data tier is trying to achieve.
Beyond this, you have to look at characteristics of your orchestration environment. If you need to be able to persist disk contents, you need to make sure you pick a container orchestrator that is able to fill this requirement.
You may have something like a sharded MongoDB cluster using the In-Memory engine for a caching layer that requires a bit more capability than a typical key value store like memcache (eg ability to query/filter the cache itself). Depending on your project's requirements, it may be perfectly fine to lose this "cache" layer and rebuild it on demand.
In other workloads. You could run something like enterpriseDB ARK to provide clustered, highly available, containerized PostgreSQL deployments on top of Kubernetes. This comes with its own challenges, but it enables you to implement a service broker model in your micro services architecture to deploy and persist the data tier for each of your micro services in a way that mitigates a monolithic data tier which is prone to chatty neighbor problems in this type of architecture.
I am using MVC architecture.My Question what are the advantages and dis advantages in running client and server in different ports or different servers
Your question refers to the separate development of two different aspects of the application and these are: the backend API and the front-end. Its more of an architectural choice
Having APIs built separately from UIs, achieves:
Less coupling. This way one can expand/upgrade/enhance both apps independently and flexibly, that too in different technologies.
Extending the above point, APIs also provide the option of universal connectivity from various consuming clients such as mobile/web/IoT thereby giving the developer greater ingress across the spectrum. This helps in gaining business advantages over the competitors
Complex business processes can also be composed by way of stitching together (orchestrating) atomic API endpoints
Security: Putting everything up into one client facing application, including backend functionality raises obvious security red flags.
Scalability: Both the apps (UI and API) can be scaled independently and elastically depending on their usage
One obvious drawback, if you will, is the "overhead" associated with the separate implementation of both sides and it can be an overkill if the use case is quite simple and the potential consumers of the app's functionality are quite less and its meant to be used/accessed in a secure environment (let's say on the internal network in a given corporate).
Like all design considerations, the above are also circumstantial as there is no one silver bullet but at the very least these are some considerations on which the design of the given app depends on.
HTH
I'm curious how you would handle following Database access.
Let's suggest you have a Computer which Hosts your database as part of his server work and multiple client PC's which has some client-side-software on it that need to get information from this database
AFAIK there are 2 way's to do this
each client-side-software connects directly to the Database
each client-side-software connects to a server-side-software which connects to the Database as some sort of data access layer.
so what i like to know is:
What are the pro and contra's of each solution?
And are other solutions out there which maybe "better" to do this work
I would DEFINITELY go with suggestion number 2. No client application should talk to a datastore without a broker ie:
ClientApp -> WebApi -> DatabaseBroker.class -> MySQL
This is the sound way to do it as you separate concerns and define an organized throughput to the datastore.
Some benefits are:
decouple the client from the database
you can centralize all upgrades, additions and operability in one location (DatabaseBroker.class) for all clients
it's very scaleable
its safe in regards to business logic
Think of it like this with this laymans example:
Marines are not allowed to bring their own weapons to battle (client apps talking directly to DB). instead they checkout the weapon from the armory (API). The armory has control over all weapons, repairs and upgrades (data from database) and determines who gets what.
What you have described sounds like two different kind of multitier architectures.
The first point matches with a two-tier and the second one could be a three-tier.
AFAIK there are 2 way's to do this
You can divide your application in several physical tiers, therefore, you will find more cases suitable to this architecture (n-tier) than the described above.
What are the pro and contra's of each solution?
Usually the motivation for splitting your application in tiers is to achieve some kind of non-functional requirements (maintainability, availability, security, etc.), the problem is that when you add extra tiers you also add complexity,e.g.: your app components need to communicate with each other and this is more difficult when they are distributed among several machines.
And are other solutions out there which maybe "better" to do this work.
I'm not sure what you mean with "work" here, but notice that you don't need to add extra tiers to access a database. If you have a desktop application installed in a few machines a classical client/server (two-tier) model should be enough. However, a web-based application needs an extra tier for interacting with the browser. In this case the database access is not the motivation for adding this extra tier.
I've been designing quite a few Windows Forms applications lately (data-entry apps, office integration, etc), and although I've always designed with logical tiers in mind, the "middle tier" business logic layer has always been hosted on the desktop PC (i.e. physical client-server).
As I approach more complex applications, I find myself yearning for a physical middle tier instead, with the desktop client passing requests back to an application server to process business logic (which may change regularly) and interfaces. It feels like I'm missing out on factors such as scalability and maintainability that are more native to Web apps.
I'm curious to know how far other WinForms developers have taken their middle-tier separation:
How much processing (if any) do you perform on a middle-tier server?
What communication method are you using - WCF, remoting, web services, etc?
How much is performance a factor, and how often do you roundtrip to the server?
Is there are a benefit in moving business logic onto a separate tier, or is it more practical to host components locally on a PC (and just make sure you have a good deployment model to push out regular releases as business rules change)?
Alternatively, should I be guiding customers away from WinForms completely if these factors are involved? With alternatives such as Silverlight and even ASP.NET w/ AJAX, the reasons to choose a WinForms client seem to be shrinking.
What is important to keep in mind is that there is a trade-off between the ease of development with a seperate middle tier vs all of the scalability benefits etc. What I mean by this is that you have to refresh interface mappings etc in your code, you have to deploy a middle tier somewhere for your testers to use, which needs to be refreshed etc. Furthermore, if you are lazy like me and pass your Entity Framework objects around directly, you cannot serialise them to a middle tier, so you then need to create DTO's for all of your operations etc.
Some of this overhead can be handled by a decent build system, but that also needs effort to set up and maintain.
My preferred tactic is to keep physical seperation in terms of assemblies (i.e. I have a seperate business logic / data access assembly) and to route all of the calls to the business layer through an interface layer, which is a bunch of Facade classes. So all of these assemblies reside within my windows app. I also create interfaces for all of these facades, and access them through a factory.
That way, should I ever need the separation of a middle tier, and the trade-off in terms of productivity is worth it, I can separate my business layer out, put it behind a WCF service (as that is my preferred service platform) and perform some refactorings in terms of what my facades hand out, and what they do with what they accept.
This is one example of why I tend to always do work in a web environment. If the network is available to your client application for service calls, it's certainly available to send and retrieve data from a web server.
Certainly, client restrictions can alter your final path, but when given the chance to influence the direction, I steer towards web-based solutions. There are deployment technologies available that give you an easier upgrade path than a traditional desktop package, but there's no real substitute for updating a server-based application.
Depending on your application, there are several performance issues to keep in mind.
If your work is very similar between various clients (shared data), then doing the processing on a middle tier is better because you can make use of caching to cut down on the overall processing.
If your is different between clients (private data), then you won't have much gain by doing the processing at a middle tier.
I'm facing the following challenge:
I have a bunch of databases in different geographical locations where the network may fail a lot (I'm using cellular network). I need to keep all the databases synchronized but there is no need to be in real time. I'm using Java but I have the freedom to choose any free database.
How can I achieve this?
It's a problem with a quite established corpus of research (of which people is apparently unaware). I suggest to not reinvent a poor, defective wheel if not absolutely necessary (such as, for example, so unusual requirements to allow a trivial solution).
Some keywords: replication, mobile DBMSs, distributed disconnected DBMSs.
Also these research papers are relevant (as an example of this research field):
Distributed disconnected databases,
The dangers of replication and a solution,
Improving Data Consistency in Mobile Computing Using Isolation-Only Transactions,
Dealing with Server Corruption in Weakly Consistent, Replicated Data Systems,
Rumor: Mobile Data Access Through Optimistic Peer-to-Peer Replication,
The Case for Non-transparent Replication: Examples from Bayou,
Bayou: replicated database services for world-wide applications,
Managing update conflicts in Bayou, a weakly connected replicated storage system,
Two-level client caching and disconnected operation of notebook computers in distributed systems,
Replicated document management in a group communication system,
... and so on.
I am not aware of any databases that will give you this functionality out of the box; there is a lot of complexity here due to the need for eventual consistency and conflict resolution (eg, what happens if the network gets split into 2 halves, and you update something to the value 123 while I update it on the other half to 321, and then the networks reconnect?)
You may have to roll your own.
For some ideas on how to do this, check out the design of Yahoo's PNUTS system: http://research.yahoo.com/node/2304 and Amazon's Dynamo: http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
Check out SymmetricDS. SymmetricDS is web-enabled, database independent, data synchronization/replication software. It uses web and database technologies to replicate tables between relational databases in near real time. The software was designed to scale for a large number of databases, work across low-bandwidth connections, and withstand periods of network outage.
I don't know your requirements or your apps, but this isn't a quick answer type of question. I'm very interested to see what others have to say. However, I have a suggestion that may or may not work for you, depending on your requirements and situation. particularly, this will not help if your users need to use the app even when the network is unavailable (offline access).
Keeping a bunch of small databases synchronized is a fairly complex task to do correctly. Is there any possibility of just having one centralized database, and either having the client applications connect directly to it or (my preferred solution) write some web services to handle accessing/updating data rather than having a bunch of client databases?
I realize this limits offline access, but there are various caching strategies you can use. (Which of course, leads you back to your original question.)