Swipe to navigate through the chapters of this book
As businesses grow, their IT system grows in three ways: the transaction volume increases as the business expands, the system becomes more geographically dispersed as the business enters new markets, and the system increases in complexity as additional processes are automated. Each of these aspects of growth involves many components and relationships in the IT system, and cloud implementations play an important role.
Please log in to get access to this content
To get access to this content you need the following product:
Kevin Ashton is usually attributed with coining the IoT phrase when he was working on automated inventory control for Proctor & Gamble. See www.rfidjournal.com/articles/view?4986 . Accessed September 2015.
Onboarding is convenient jargon for the entire process of taking on a new member of an organization. It usually starts at hiring and includes orientation and training, providing necessary tools and facilities (such as a cubicle, chair, and computer), enrolling in human resources and payroll accounting programs, opening computer system accounts, establishing authentication and authorizations for security, and so on. In IT discussions, onboarding often focuses on establishing IT accounts and security. The reverse of onboarding is off-boarding.
A terabyte is a trillion bytes. A petabyte is a quadrillion bytes. A few years ago, the entire Library of Congress was estimated to contain 3 petabytes of information.
See Marvin Waschke, Cloud Standards, Apress, 2012; pp 124-131 have a discussion of the Consistency, Availability, Partitioning (CAP) theorem and its implications for system communications. The CAP theorem asserts applications integrated over an unreliable network must balance data consistency with data availability. In other words, if completely accurate data must be available at every instant, the network must be perfect. If a perfect network is not available, consistency and availability must be balanced. Since perfect networks are only theoretically possible, availability and consistency are always a compromise. Most Internet applications settle on “eventual consistency,” which places availability above consistency but guarantees that the data will eventually be consistent. Mobile devices with intermittent or varying connections exacerbate the need for eventual consistency.
For more discussion on spoke and hub architectures, see www.enterpriseintegrationpatterns.com/ramblings/03_hubandspoke.html . Accessed September 2015.
For a detailed discussion of the message bus pattern, see Gregor Hohpe and Bobby Wolfe. Enterprise Integration Patterns. Boston: Addison-Wesley, 2004 (Kindle location 3386). Note that a message bus and an enterprise service bus (ESB) are not identical. An ESB provides access to services, frequently via SOAP web services. A message bus provides access to data and events, not necessarily services.
When storage was expensive, data duplication was avoided to save storage space. I cannot recall a single instance in my experience when a decision to deduplicate data solely to save storage space was a good decision. The code complexity and maintenance never justified the cost savings. Of course, the fact that the price of storage has decreased continuously for a long time has something to do with this, but not entirely. Infrastructure costs seldom exceed the cost of complexity. There are many good reasons for avoiding duplication, but saving storage is seldom one of them.
In distributed environments, including clouds, eventual consistency, discussed in note 4, puts a premium on availability over consistency but insists that the system eventually attain consistency. This applies to caches as well as data stores.
- The Harder They Fall
- Sequence number
- Chapter number
- Chapter 8