An Architect's vision

AWS announced Network Load Balancer for the Elastic Load Balancing service designed to handle millions of requests per second while maintaining ultra-low latencies. This new load balancer is optimized to handle volatile traffic patterns while using a single static IP address per Availability Zone. Static IP Addresses – Each Network Load Balancer provides a single IP address for each VPC subnet in its purview. If you have targets in a subnet in us-west-2a and other targets in a subnet in us-west-2c , NLB will create and manage two IP addresses (one per subnet); connections to that IP address will spread traffic across the instances in the subnet. You can also specify an existing Elastic IP for each subnet for even greater control. With full control over your IP addresses, Network Load Balancer can be used in situations where IP addresses need to be hard-coded into DNS records, customer firewall rules, and so forth.

 

 

Infrastructure   (ex: 6LowPAN, IPv4/IPv6, RPL) Identification   (ex: EPC, uCode, IPv6, URIs) Comms / Transport   (ex: Wifi, Bluetooth, LPWAN) Discovery   (ex: Physical Web, mDNS, DNS-SD) Data Protocols   (ex: MQTT, CoAP, AMQP, Websocket, Node) Device Management   (ex: TR-069, OMA-DM ) Semantic   (ex: JSON-LD, Web Thing Model) Multi-layer Frameworks   (ex: Alljoyn, IoTivity, Weave, Homekit)

In   software architecture ,   publish–subscribe   is a   messaging pattern   where senders of   messages , called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are. Publish–subscribe is a sibling of the   message queue   paradigm, and is typically one part of a larger   message-oriented middleware   system. Most messaging systems support both the pub/sub and message queue models in their   API , e.g.   Java Message Service   (JMS). This pattern provides greater network   scalability   and a more dynamic   network topology , with a resulting decreased flexibility to modify the publisher and the structure of the published data.

 A Raspberry Pi is a general-purpose computer, usually with a Linux operating system, and the ability to run multiple programs. An Arduino is a microcontroller motherboard. A microcontroller is a simple computer that can run one program at a time, over and over again. Raspberry Pi carries connection to the outside world [Bluetooth, wifi] and can be programmed with a variety of languages starting from Python. If your code is complex and large, you might not able rely on just the microcontroller. Arduino is more rugged and has a much wider operating voltage range. You can easily burn your Raspberry Pi with a 0.5 V more or less than 5V needed. Its design is very simple and there are very less ways to screw up. More importantly, it has got a pretty neat IDE to easily program. Thus, Arduino is more suitable for controlling your sensors & actuators in an home automation project.            

ACID is a set of properties that apply specifically to database transactions, defined as follows: Atomicity  - Everything in a transaction must happen successfully or none of the changes are committed. This avoids a transaction that changes multiple pieces of data from failing halfway and only making a few changes. Consistency  - The data will only be committed if it passes all the rules in place in the database (ie: data types, triggers, constraints, etc). Isolation  - Transactions won't affect other transactions by changing data that another operation is counting on; and other users won't see partial results of a transaction in progress (depending on isolation mode). Durability  - Once data is committed, it is durably stored and safe against errors, crashes or any other (software) malfunctions within the database.

The Relational Databases have the following challenges: Not good for Petabytes of data with variety of data types (eg. images, videos, text) Cannot scale for large data volume Cannot scale-up, limited by memory and CPU capabilities Cannot scale-out, limited by cache dependent Read and Write operations Sharding  causes operational problems Changing Table structure is a big challenge Consistency limits the scalability in RDBMS   Compared to RDBMS, NoSQL DBs are more scalable and provide better performance. NoSQL databases address the challenges that the RDBMS does not provide in case of below mentioned situations. A scale-out, shared-nothing architecture, capable of running on a large number of nodes A non-locking concurrency control mechanism so that real-time reads will not conflict writes Scalable replication and distribution – thousands of machines with distributed data An architecture providing higher performance per node than RDBMS Schema-less data model

C - Consistency means a client should get same view of data at a given point in time irrespective of node it is looked up from. All the servers in the system will have the same data so anyone using the system will get the same copy regardless of which server answers their request. A - Availability here means that any given request should receive a response [success/failure]. The system will always respond to a request (even if it's not the latest data or consistent across the system or just a message saying the system isn't working). P - Partition Tolerance means the system remains operational despite node or other hardware failures, the system is tolerant enough to these kind of failures. The system continues to operate as a whole even if individual servers fail or can't be reached. In distributed systems, consistency, availability and partition tolerance exists in a mutually dependent relationship. You cannot have all 3, for example, if you choose strict consi