Dynode – A node.js client for Amazon's DynamoDB
Dynode is a node.js client, which enables you to work with Amazon's DynamoDB service with ease. Amazon's http api is complex and interacting with it is not so easy. This client does offer a simpler and more obvious way of working with DynamoDB, notably, without putting any restrictions on what you can accomplish with DynamoDB.
There are two different ways to use dynode: directly via the default dynamoDB client, or by instantiating your own client. The former is merely intended to be a convenient shared client to use throughout your application if you so choose.
Using the Default DynamoDB Client
The default client is accessible through the dynode module directly. Any method that you could call on an instance of a client is available on the default client:
var dynode = require('dynode');
// When using the default client you must first give it auth credentials
dynode.auth({accessKeyId: "AWSAccessKey", secretAccessKey: "SecretAccessKey"});
dynode.createTable("NewTable", console.log);
dynode.listTables(console.log);Instantiating your own DynamoDB Client
If you would prefer to manage your own client, potentially with different auth params:
Don't like to miss out any of our posts? Do Subscribe to our Feed
Amazon DynamoDB – a Highly Scalable and Fast NoSQL Database in the Cloud
Amazon recently introduced DynamoDB, a new Cloud based NoSQL database service designed to maintain predictably high performance and to be highly cost efficient for workloads of any scale, from the smallest to the largest internet-scale applications.
Customers can now launch a new Amazon DynamoDB database table, scale up or down their request capacity for the table without downtime or performance degradation, and gain visibility into resource utilization and performance metrics, with a few clicks on the AWS Management Console. In short, DynamoDB is ‘a fully managed NoSQL database’ that can be scaled up or down according to demand.
Amazon DynamoDB is based on the principles of Dynamo, a progenitor of NoSQL, and brings the power of the cloud to the NoSQL database world. It offers customers high-availability, reliability, and incremental scalability, with no limits on dataset size or request throughput for a given table. And it is fast – it runs on the latest in solid-state drive (SSD) technology and incorporates numerous other optimizations to deliver low latency at any scale. It also allows customers to offload the administrative burdens of operating and scaling distributed databases so they don't have to worry about hardware provisioning, configuration, replication, software patching, partitioning, or cluster scaling.
Check out a video explaining the basic concept:
Like what we post? Share your thoughts on the comments below. If you wish to get regular updates on what we post, do subscribe to our RSS Feed
MongoDB on AWS
Amazon Web Services (AWS) is a flexible, cost-effective, easy-to-use cloud computing platform. NoSQL software packages are widely installed in the AWS cloud. Running your own NoSQL data store on Amazon Elastic Cloud Compute (Amazon EC2) is a great scenario for users whose application requires the special benefits of structured storage software optimized for high-performance operations on large datasets.
This whitepaper written by Miles Ward of AWS will assist you in understanding one of the most common NoSQL options available with the AWS cloud computing platform—the open source application MongoDB. It gives you an overview of general best practices that apply to all major NoSQL options, and also examines important MongoDB implementation characteristics such as performance, durability, and security.
Are you looking for trusted consultant for deploying your applications to AWS Cloud? Contact us for more information.
How to Migrate Your Existing Applications to the AWS Cloud
Developers and architects looking to build new applications in the cloud can simply design the components, processes and workflow for their solution, employ the APIs of the cloud of their choice, and leverage the latest cloud-based best practices for design, development, testing and deployment. In choosing to deploy their solutions in a cloud-based infrastructure like Amazon Web Services (AWS), they can take immediate advantage of instant scalability and elasticity, isolated processes, reduced operational effort, on-demand provisioning and automation.
At the same time, many businesses are looking for better ways to migrate their existing applications to a cloud-based infrastructure so that they, too, can enjoy the same advantages seen with greenfield application development.
One of the key differentiators of AWS’ infrastructure services is its flexibility. It gives businesses the freedom of choice to choose the programming models, languages, operating systems and databases they are already using or familiar with. As a result, many organizations are moving existing applications to the cloud today.
Are you looking for a trusted development partner to migrate your existing applications to AWS Cloud? Contact us for more information.
How design for failure model counters AWS Outages
Were you affected by the recent AWS Outage? If so, you might be scratching your head and thinking hard to counter any such occurrences. George Reese explains how "design for failure” model could come in handy to tackle such outages.
So many cloud pundits are piling on to the misfortunes of Amazon Web Services this week as a response to the massive failures in the AWS Virginia region. If you think this week exposed weakness in the cloud, you don't get it: it was the cloud's shining moment, exposing the strength of cloud computing.![]()
In short, if your systems failed in the Amazon cloud this week, it wasn't Amazon's fault. You either deemed an outage of this nature an acceptable risk or you failed to design for Amazon's cloud computing model. The strength of cloud computing is that it puts control over application availability in the hands of the application developer and not in the hands of your IT staff, data center limitations, or a managed services provider.
The AWS outage highlighted the fact that, in the cloud, you control your SLA in the cloud—not AWS.
The Dueling Models of Cloud Computing
Until this past week, there's been a mostly silent war ranging out there between two dueling architectural models of cloud computing applications: "design for failure" and traditional. This battle is about how we ultimately handle availability in the context of cloud computing.
The Amazon model is the "design for failure" model. Under the "design for failure" model, combinations of your software and management tools take responsibility for application availability. The actual infrastructure availability is entirely irrelevant to your application availability. 100% uptime should be achievable even when your cloud provider has a massive, data-center-wide outage.
Most cloud providers follow some variant of the "design for failure" model. A handful of providers, however, follow the traditional model in which the underlying infrastructure takes ultimate responsibility for availability. It doesn't matter how dumb your application is, the infrastructure will provide the redundancy necessary to keep it running in the face of failure. The clouds that tend to follow this model are vCloud-based clouds that leverage the capabilities of VMware to provide this level of infrastructural support.
The advantage of the traditional model is that any application can be deployed into it and assigned the level of redundancy appropriate to its function. The downside is that the traditional model is heavily constrained by geography. It would not have helped you survive this level of cloud provider (public or private) outage.
The advantage of the "design for failure" model is that the application developer has total control of their availability with only their data model and volume imposing geographical limitations. The downside of the "design for failure" model is that you must "design for failure" up front.
Email Marketing Simplified with Amazon SES
Sending Bulk Emails with Amazon SES
Amazon Simple Email Service (SES) is a bulk and transactional email-sending service built on Amazon’s infrastructure used for years to send targeted emails to millions of customers. One of the main tasks it tries to accomplish is providing a service that can deliver large amounts of emails that are not rejected by destination ISPs which enforce filtering meant to deal with spam, as emphasized by Chris Wheeler, Technical Program Manager for Amazon SES:
You must get your house in order before sending your first piece of mail. Otherwise, your mail will end up in the spam folder, may not be delivered at all, or you may be blocked from sending any more mail.
To avoid spammers sending emails from SES, Amazon uses several tactics. Each email is programmatically scanned before being sent in an attempt to establish if the message is spam or not, and if includes malware. Messages tagged as spam by Amazon’s filters are not delivered and are reported back to users so they can change the content. The user is also informed if a message passes Amazon’s filters but is rejected by the destination ISP for spamming reasons. This helps Amazon have an idea about the quality of the emails sent by a certain user, talking the liberty to suspend an account that seems to be spamming until further investigation is carried on.
Then, a company wanting to use the service starts with a “sandbox”, a limited SES account allowing them to send maximum 200 messages/day, each one of them to a verified address. This helps with developing and testing the application sending emails, and to gain a good reputation by sending emails passing through filters. The next step is using the production account which allows sending emails to unverified addresses, but with a limit of 1,000 messages/day. This quota is gradually raised based on user’s need and a combination of several factors: “the amount of email that you send, the number of rejections and bounces that occur, and the number of complaints that it generates.” When all conditions are met, the quota is raised to 10,000 emails/day after 3 days, and 1M emails/days after 2 weeks. There is also a limit regarding the number of emails sent per second, starting with 1/sec, then 10/sec, the highest being 90/sec. More emails per day or per second can be sent after contacting Amazon and getting special approval. The entire process is designed to ensure users are not using SES to send spam. Read more…
Don't like to miss out any of our posts? Do Subscribe to our Feed
For porting your web site infrastructure to Amazon Web Cloud, contact us at www.amt.in

