I was wondering about the way the data are transferred between the layers of a n-tier architecture ? For example, in spring web mvc, under which format do they move from one layer to another ?
In a n-tier architecture, the format of the data is generally defined by the tier. If you are communicating between a database tier and a business logic tier, it will probably be JDBC. If it is between a business-logic tier and a web tier it will probably be either a service protocol (JSON, SOAP, etc), or a remoting protocol (RMI, etc). If it is between the client (web browser) and the web tier, it's probably HTML or JSON.
Related
Cloud ML from Google is serverless technology, If serverless architecture doesn’t care about how many servers were created behind the scene then why do we give scale tier option in Cloud ML.
Serverless doesn't mean that your application or process is not running under a server, obviously it is. Serverless is an abstract concept, is a type of architecture where the servers "doesn't exists" to the developer, they don't have to worry about anything, only develop the code, set parameters as you pointed, the maximum number of servers or their Memory utilization (to not to have an enormous bill at the end of the month), and then their app will work and autoscale when it's needed.
Just curious if this is possible or how you would accomplish this.
Regardless if I use duration based stickiness or application based, when the instance a user is connected to fails their session gets reset because they have to connect to a new server.
Is there a way to not have this happen? To be able to have that session persist even if the instance they are connected to dies? Im also using SSL with a cert if that changes things.
The only way to accomplish that is persisting your session state in some Storage service, could be a database table, s3, Caching service, NoSQL table, Etc.
These are some approaches
Session state Inside Your Database
Saving session state inside the database is common in lightweight web frameworks like Django. That way you can add as many front servers as you like without having to worry about session replication and other difficult stuff. You don’t tie yourself to a certain web server and you get persistence and all other features databases provide for free. As far as I can tell, this works rather nicely for small to medium size websites.
The problem is the usual: The database server may become your bottleneck. In that case your best bet may be to take a suitcase full of money to Oracle or IBM and buy yourself a database cluster.
Reference: Saving Session Data in Web Applications
Session state inside a Caching service
Amazon ElastiCache offers fully managed Redis and Memcached. Seamlessly deploy, operate, and scale popular open source compatible in-memory data stores. Build data-intensive apps or improve the performance of your existing apps by retrieving data from high throughput and low latency in-memory data stores.
DynamoDB
Amazon DynamoDB is a fast and flexible NoSQL database service for all applications that need consistent, single-digit millisecond latency at any scale. It is a fully managed cloud database and supports both document and key-value store models. Its flexible data model, reliable performance, and automatic scaling of throughput capacity.
Regardless the approach you use, a middleware must be deployed along with your app to manage the stored session state.
Middleware: Could be either a thrid-party solution or your own solution.
Resources
AWS Session Management
Amazon ElastiCache
Amazon DynamoDB
Middleware for session management (Google results)
Though it is not a direct programming related query, I was looking out for the approach one should have if web services fail in Service Now application. How to handle the data at source during the web service outage and how to trigger data transfer after the resolution of web service incident?
Posted the same question in Service Now community and the response is
"Service Now operates 16 data centers and availability is 99.995%. You can try store and process functionality at source during Service Now down time."
The business continuity is planned in such a way that the web-service will failover to another DC causing no disruption to the users/applications.
So the risk is very minimal (infact near to 0) and the scenario can be ignored.
I'm about to get an Amazone ec2 account for my 4 e-commerce websites. Sometimes there is a big traffic or i have to make a lot of queries to generate some products feeds.
But there is something i can't figure out about this system : Why there is different instances specs ?
I mean if i pay per hour, then why don't i get the smallest instance spec, and if needed the auto-scale will make 2 or 100 instances to deal with the traffic.
So can someone advice or explain why should i or shouldn't do what i said above ?
And why there is different instance sizes ?
Thank you
Not all applications are same, the number of requests these web applications handle quite different, basically Amazon AWS provides various flavors of virtual servers http://aws.amazon.com/ec2/instance-types/, some are best suitable for E commerce websites with predictable bursts, blogs with less usage, Compute intensive apps, Media Streaming Servers which requires higher RAM etc.
You decide the best suitable type and size of the virtual server for your application to begin with and then scale up and scale down based on the load. AWS provides reference use-cases and best practices here http://aws.amazon.com/architecture/ to architect elastic, scalable and fault tolerant web services.
How is state managed between sessions? I know that in Azure, client-specific states are stored in SQL Azure. I'm wondering if this is done similarly in AWS?
Do the various instances of your application all access a DB somewhere where the state is stored? Is state management much different depending on which technologies you are using?
At a 'homework' level, Amazon Web Services is loosely comprised of two different sets of things:
infrastructure services (EC2, EBS), which you manage yourself
higher level services (S3, DynamoDB, ELB), which Amazon manage for you
When you upload a file to S3, it is stored across a number of machines in a number of different data centers, and Amazon is responsible for finding and returning the file when you request it (as well as making sure it doesn't get erased by a machine failure.)
With something built on top of one of the infrastructure services, such as an application running on EC2, you are on your own as to how you store and synchronize state:
One server, state in memory (bad)
Load balancing with no state handling (very bad!)
Load balancing with sticky sessions (sensible, but not enough by itself; if that server falls out of the pool, the other servers have no idea of who you are)
Load balancing with servers with a common state server
How do you store state? Traditionally a database (possibly Amazon RDS) with a memory cache (such as Elasticache - Amazon's managed memcached-compatible cache). Amazon's new DynamoDB service is a good fit for this use, as a fast, redundant, key-value store.