A Brief About mPOS - Mobile Point of Sale

mPOS - Mobile Point of Sale

Before we know about mPOS - Mobile Point of Sale, we have to understand what is POS - Point of Sale. Point of Sale - POS or Checkout is the place where a retail transaction is completed. It is the point at which a customer makes a payment to the merchant in exchange for goods or services. At the Point of Sale the retailer would calculate the amount owed by the customer and provide options for the customer to make payment. The merchant will also normally issue a receipt for the transaction. The POS in various retail industries uses customized hardware and software as per their requirements. Retailers may utilize weighing scales, scanners, electronic and manual cash registers, EFTPOS (Electronic Funds Transfer at Point of Sale — is an electronic payment system involving electronic funds transfers based on the use of payment cards, such as debit or credit cards, at terminals located at points of sale.) terminals, touch screens and any other wide variety of hardware and software available for use with POS. For example, a grocery or candy store uses a scale at the Point of Sale, while bars and restaurants use software to customize the item or service sold when a customer has a special meal or drink request.

The modern Point of Sale is often referred to as the Point of Service because it is not just a Point of Sale but also a Point of Return. Additionally it includes advanced features to cater to different functionality, such as inventory management, CRM, financials, warehousing, etc., all built into the POS software. Prior to the modern POS, all of these functions were done independently and required the manual re-keying of information, which can lead to entry errors.

mPOS - Mobile Point of Sale in a single word, a "Dongle Plus Smartphone" innovation for modern POS system. An mPOS - Mobile Point of Sale is a smartphone, tablet or dedicated wireless device that performs the functions of a cash register or electronic Point of Sale (POS) terminal. 

mPOS implementations allow service and sales industries to conduct transactions in place, improving the customer experience and freeing up valuable real estate that would otherwise be dedicated to a POS counter. An mPOS can also be cost-effective, allowing a small business owner to conduct transactions without having to invest in an electronic register or pay someone to support the software. 

Any smartphone or tablet can be transformed into an mPOS with a downloadable mobile app. Typically, when the business owner registers the app, the vendor sends the business owner a card reader that plugs into the mobile device's audio jack. Some mPOS software vendors also provide optional hand-held docking stations (called sleds) that allow the mobile device to read barcodes and print receipts. 

Depending on the software, a mPOS can operate as a stand-alone device that's simply linked to the business' bank account or it can be an integrated component of a larger, legacy POS system. To protect cardholder data, customer data is encrypted and stored in the cloud -- not on the device.

Popular mobile POS vendors include PayPal, Square, Intuit and VeriFone. 

NOTE:   mPOS implementation requires Strong Security Awareness.  

Quick Reference Guide - CRUSH & Ceph

CRUSH

CRUSH (Controlled Replication Under Scalable Hashing) is a hash-based algorithm for calculating how and where to store and retrieve data in a distributed object-based storage cluster.

CRUSH is the pseudo-random data placement algorithm that efficiently distributes object replicas across a Ceph storage cluster. Cluster size needs to be flexible, and device failure is going to happen. CRUSH allows for the addition and removal of storage devices with as little movement of data as possible. Ceph utilizes the CRUSH algorithm to compute where data can be found or should be written. This eliminates metadata bottlenecks, which increases overall efficiency accessing data in the cluster. Ceph clients accessing storage and Ceph devices that replicate data to their peers both run the CRUSH algorithm. This allows the work to scale linearly with the size of the cluster.

CRUSH is an algorithm that can calculate the physical location of data in Ceph, given the object name, cluster map and CRUSH rules as input.

CRUSH distributes data evenly across available object storage devices in what is often described as a pseudo-random manner. Distribution is controlled by a hierarchical cluster map called a CRUSH map. The CRUSH map, which can be customized by the storage administrator, informs the cluster about the layout and capacity of nodes in the storage network and specifies how redundancy should be managed. 

CRUSH replicates data in multiple locations and fault domains. So when a disk fails, CRUSH replicates data across available OSDs. There is no need for RAID, which typically just adds to the hardware cost.

Ceph and CRUSH allow you to work in a heterogeneous structured environment that frees you from vendor lock-in and expensive proprietary hardware. CRUSH is also self-managing and self-healing, this reduces the overall need for human intervention in your data center.

CRUSH is one of the key features that makes Ceph powerful and uniquely scalable compared to other storage systems that we see today.

Ceph

Linux's impressive selection of file systems is Ceph, a distributed file system that incorporates replication and fault tolerance while maintaining POSIX compatibility.

CRUSH was designed for Ceph, an open source software designed to provide object-, block- and file-based storage under a unified system. Because CRUSH allows clients to communicate directly with storage devices without the need for a central index server to manage data object locations, Ceph clusters can store and retrieve data very quickly and scale up or down quite easily.

As if the dynamic and adaptive nature of the file system weren't enough, Ceph also implements some interesting features visible to the user. Users can create snapshots, for example, in Ceph on any subdirectory (including all of the contents). It's also possible to perform file and capacity accounting at the subdirectory level, which reports the storage size and number of files for a given subdirectory (and all of its nested contents).

Ceph is a distributed object store and file system designed to provide excellent performance, reliability and scalability.

Goals

• Easy scalability to multi-petabyte capacity (Required for BigData)

• High performance over varying workloads (input/output operations per second [IOPS] and bandwidth)

• Strong reliability

Note:

Ceph is not only a file system but an object storage ecosystem with enterprise-class features. Ceph isn't unique in the distributed file system space, but it is unique in the way that it manages a large storage ecosystem. Other examples of distributed file systems include the Google File System (GFS), the General Parallel File System (GPFS), and Lustre etc. The ideas behind Ceph appear to offer an interesting future for distributed file systems, as massive scales introduce unique challenges to the massive storage problem. 

Although Ceph is now integrated into the mainline Linux kernel, it's properly noted there as experimental. File systems in this state are useful to evaluate but are not yet ready for production environments. 

Geetika Technosoft Pvt Ltd - GTechnosoft & GTechEd Family Wishing All of You Happy Independence Day

Quick Reference Guide - Cloud Storage Gateway

Cloud Storage Gateway

A Cloud Storage Gateway is a hardware- or software-based appliance located on the customer premises that serves as a bridge between local applications and remote cloud-based storage. 

A Cloud Storage Gateway is a network appliance or server which resides at the customer premises and translates cloud storage APIs such as SOAP or REST to block-based storage protocols such as iSCSI or Fibre Channel or file-based interfaces such as NFS or CIFS.

According to a 2011 report by Gartner Group, Cloud Storage Gateways were expected to increase the use of Cloud Storage by lowering monthly charges and eliminating the concern of data security.

A Cloud Storage Gateway appliance provides basic protocol translation and simple connectivity to allow the incompatible technologies to communicate transparently. The gateway may be a stand-alone computing device or a virtual machine (VM) image.

As the market has evolved, some vendors have dropped the word "gateway" in favor of the word "controller" to emphasize the idea that their gateway products do more than just serve as a bridge. 

Unlike the Cloud Storage Services which they complement, Cloud Storage Gateway use standard network protocols which integrate with existing applications. Cloud Storage Gateway can also serve as intermediaries to multiple cloud storage providers. Some Cloud Storage Gateway also include additional storage features such as backup and recovery, caching, compression, encryption, storage de-duplication and provisioning.

Many of today's Cloud Storage Gateway products provide data deduplication and compression capabilities to make use of available bandwidth efficiently and move data as quickly as possible. Reducing the data footprint also lowers cost, because cloud providers charge for over-the-wire transfers as well as for storage space. Other popular features include snapshots and version control, the ability to use local storage as a cache, automated tiered storage and encryption. 

A Brief About GCE - Google Compute Engine

GCE - Google Compute Engine

Google Compute Engine is a service that provides virtual machines that run on Google infrastructure. Google Compute Engine offers scale, performance, and value that allows you to easily launch large compute clusters on Google's infrastructure. There are no upfront investments and you can run up to thousands of virtual CPUs on a system that has been designed from the ground up to be fast, and to offer strong consistency of performance.

The Google Compute Engine (GCE) is an Infrastructure as a Service (IaaS) offering that allows clients to run workloads on Google's infrastructure. The Compute Engine provides a scalable number of virtual machines (VMs) to serve as large compute clusters for that purpose.  

Virtual machines (VMs) are offered as standard Google Linux-based VMs; also customers may use their own system images for custom virtual machines. Virtual machines are offered in a number of memory configurations with up to 16 virtual cores each. The number of allowed instances makes it possible to run thousands of virtual CPUs working on a task.

GCE can be managed through a RESTful API, command line interface (CLI) or Web console. GCE's application program interface (API) provides administrators with virtual machine (VMs), DNS servers and load balancing capabilities. VMs are available in a number of CPU and RAM configurations and Linux distributions, including Debian and CentOS. Customers may use their own system images for custom virtual machines. Data at rest is encrypted using the AEC-128-CBC algorithm. 

GCE's scalable number of allowed instances makes it possible for an administrator to create clusters with thousands of virtual CPUs. GCE allows administrators to select the region and zone where certain data resources will be stored and used. Currently, GCE has three regions: United States, Europe and Asia. Each region has two availability zones and each zone supports either Ivy Bridge or Sandy Bridge processors. GCE also offers a suite of tools for administrators to create advanced networks on the regional level. GCE instances must be within a network to ensure that only instances within the same network can see each other by default. 

Compute Engine is a pay-per-usage service with a 10-minute minimum and per-minute billing thereafter. There are no up-front fees or time-period commitments. GCE competes with Amazon's Elastic Compute Cloud (EC2) and Microsoft Azure.

Google Compute Engine offers many capabilities

Create virtual machines with a variety of configurations

• Launch a standard boot image based on Debian or CentOS 6.2 images, or create your own image.
• Create a 64 bit x86 Linux-based virtual machine (VM) instance. Google Compute Engine offers a variety of machine types that you can choose from for your instances.

Maintain and store data in persistent block storage

• From a VM image, mount persistent block storage (persistent disk) that maintains state beyond the life cycle of the VM instance. Data on persistent disks are retained even if your virtual machine instance suffers a failure or is taken offline. Persistent disk data is also replicated for additional redundancy.

Manage network access to your virtual machines

• Use your virtual machines alone or connected together to form a compute cluster
• Connect your machines to the Internet with a flexible networking solution that offers static and ephemeral IPv4 addresses for your instances.
• Use the built-in layer 3 load balancing service to distribute heavy workloads across many virtual machines.
• Use an easily configurable firewall to set up network access to your instances.
• Create an internal network of virtual machines or set up access to external traffic by setting up customizable firewall rules.
• Connect your VM instances to each other and to the Internet with our fully encapsulated layer 3 network. Our network offers strong isolation to help protect your instances from undesired access.
• Locate other instances in your project using DNS lookup of VM names.

Use a variety of tools and OAuth 2.0 authentication to manage your virtual machines

• Access your virtual machine instances through the Compute Engine console, RESTful API, or through a simple command line tool.
• Take advantage of OAuth 2.0 to authenticate to the RESTful API to create and delete virtual machine instances, disks, and other resources. Also, leverage OAuth 2.0 to seamlessly integrate with other Google Cloud services such as Google Cloud Storage.
• Use service account identities to authenticate your instances to other services, and remove the need to push keys into VM instances.

Note:  Google Compute Engine does not guarantee 100% uptime, so you should take steps to make sure that your service can easily regenerate the state on an instance should an unexpected failure occur. If you do not, your service will be adversely affected if your instances fall offline.