Pragmatism and Enterprise Architecture

Two sides of same coin.

The role of architecture, albeit neither overtly tangible nor receives attention grabbing headlines, plays a critical role in the predictable daily operations and deliverance of committed services to customers. Those two attributes are more strategic than tactical. Predictability is a proxy for risk management, the ability to respond swiftly at a time of misfortune. Deliverance is a measure of dependability, trust, and branding that translates into leverage in negotiations, which in turn becomes a decisive factor when choosing a partner among equals. Good IT system architecture makes the critical difference between:

a) an enterprise's strategic advantage and an Achilles' heel

b) Citadel and McMansion

c) near-zero technical debt and a do-over

In the field of architecture, there are 2 complementary and contradicting concerns: Purity and Pragmatism. As always, there are proponents and detractors on both side of the aisle. Purists weigh interoperability of disparate building blocks, mutual co-existence, development and deployment simplicity, and low/optimal operational costs as uncompromising principles when developing architectural blue prints. Pragmatists weigh creating competitive moat through technical superiority, protecting intellectual properties with patents, and finessing the licensing model to maximize profitability when developing arch models. Understanding what the right mix of the two concerns helps make short and long term decisions that are both strategic and tactical.

How would it look without them?

An infrastructure engineer can easily read the specs, order, and assemble a bunch of pizza box-like server units from a myriad of brand name local vendors or white label vendors in Asia. They then download a personally delectable flavor of OS from an open source mirror or a professional services vendor and install them on top of the pizza boxes. Finally, they choose a run-of-the-mill web and app server combo from a traditional/reputed shop or chose a combo from state of the art neo noir style frameworks from an intrepid, iconoclast developer/group and configure them to their heart's content and put them into production—without architects.

A self-proclaimed network engineer orders run-of-the-mill network switches, routers, HBA, and cables from the Sears-style catalogue (even I've ordered from a 600+ page catalogue), creates a DMZ layer with iron-clad firewalls to thwart hackers, and configures authentication and authorization layers so that only the clan can get in - without architects.

In the same way, a database engineer follows instructions in the installation wiki and FAQ's of a traditional SQL or NoSQL Server product from a reputed vendor or picks one of many open source flavors, installs, and configures into the boxes the infrastructure engineer has built for them and turn them on in production—without architects.

A group of nocturnal application developers can write a bunch of cool applications and put them into production—without architects.

Voila, your entire IT system is now up and running. Currently, thousands of production servers run in enterprise data centers—without architects. It is not atypical that a bunch self-styled, innovative, young, and ambitious professionals make critical decisions on how to build servers, create databases, write applications, and operate the entire system.

Where is the Breaking point?

The ad-hoc IT infrastructure buildout, somewhat mercurial application development, and deployment and maintenance process will of course work, but it will only take you so far. Without incorporating pragmatic architectural considerations in the buildout, development, and operating model we know things break down at some point.

If history is any guide, the breaking point is always scale, performance, and the 99.999999% availability of the IT system for a 24/7 business model. Scale and performance are indicators of sustained business growth, and the 99.999999% availability is an indicator of brand, trust, and service commitment to customers.

If you need an example, look no further than the initial web application developed by Pierre Morad Omidyar, a software developer by trade and founder of eBay. Omidyar began to write the original computer code for an online venue to enable the listing of direct person-to-person auctions for collectable items. He created a simple prototype on his personal web page and on Labor Day in 1995 he launched an online service called Auction Web, which would eventually become the auction site eBay. The service was hosted on a website Omidyar had originally created for information on the Ebola virus.

Another example is the initial web application developed by Mark Zuckerberg, founder and software developer at Facebook, in his dorm room. There are several examples like this if you scour the web.

In both cases, the initial development and operating model - without incorporating established architectural considerations – of the IT system did not last long due to scale and performance shortcomings when their web based business applications experienced sudden and exponential growth.

Where the rubber meets the road

The complexity of technological choices and integration challenges that come along with them demands skill and experience in how to stitch together and tune different building blocks into the right set of useful/consumable products and services. Physical Infrastructure (H/W), data (DB's), application development platforms (middleware, frameworks), applications (CRM, HR, ERP, custom apps, etc.) and an array of deployment and operational tool sets are 4 critical components of any IT company to keep the revenue generating engine humming and running. Integration of infrastructure, application development, and database management tools require the skills and leadership beyond those of engineers and developers.

Architects:

Give physical shapes to concepts that have business value
Provide the blueprint
Compile the tool list and building blocks so that IT professionals and/or system engineers can build the infrastructure, and database folks can start constructing the data models, their ownership, and the intricate relationship between them
Specify details to the developers or software engineers so that they can focus on coding the applications
Guide the development of operating manual/standard operating procedures so that operational folks can start their long journey of learning how to "drive" the system on a day to day basis

Thanks,

Shak Kathirvel, Application Architect

Hypervisor – the magic behind virtualization

1. Virtualization. Why do we do it?

All modern operating systems are designed so that they have a one-to-one relationship with the hardware elements (CPU and its multi cores, cache memory, physical memory, storage, network, etc.). This one-to-one relationship makes economic sense with hardware elements with a single core CPU, single level cache and few hundred MBs physical memory. With the rapid advancements in chip fabrication methods in the last two decades, the popular off-the-shelf commodity servers that are available on the market today, say HP ProLiant Gen9, are equipped with multi core CPUs (12-18 cores) and 1.5 TB memory. These hyper powered machines when run on 1 OS-to-1 compute element configuration, use only 10-20% of their full computing capacity. How can we maximize the utilization of this precious and abundant computing resource to get full ROI? - Hypervisor Tech. It helps extract every ounce of the capacity and get much higher utilization out of our physical server resources.

A hypervisor is also known as a Virtual Machine Manager (VMM) and its sole purpose is to allow multiple "virtual machines" to share a single hardware platform. In the simplest terms - the VMM is the piece of software responsible for monitoring and enforcing policy on the virtual machines for which it is responsible. This means that the VMM keeps track of everything happening inside of a virtual machine, and when necessary, provides resources, redirects the virtual machine to resources, or denies access to resources (different implementations of VMMs provide or redirect resources to varying levels).

Types of Hypervisors

A type I Hypervisor is one that runs directly on the hardware without the need of a hosting operating system. There is no host OS and the hypervisor has direct access to all hardware and features. The main reasons to install a type 1 hypervisor are to run multiple operating systems on the same physical hardware without the overhead of a host OS and to take advantage of the portability and hardware abstraction. Bare metal is most often used for servers because of their security and portability to move from hardware to hardware in case of a crash. Examples of type I VMMs include the mainframe virtualization solutions offered by companies such as Amdahl and IBM, and on modern computers by solutions like VMware ESX, Citrix XenServer and Windows virtualization Microsoft Hyper-V.

A type II Hypervisor is one that runs on top of a hosting operating system and then spawns higher level virtual machines. These hypervisors run on a conventional operating system just as other computer programs do. Type-2 hypervisors abstract guest operating systems from the host operating system. VMware Workstation, VMware Player, VirtualBox and QEMU are examples of type-2 hypervisors.

2. Elements of Virtualization

CPU Virtualization: A virtual CPU (vCPU), also known as a virtual processor, is a slice (transient unit) of physical central processing unit (CPU) that is assigned to a virtual machine (VM). In other words, a Virtual Processor that is assigned to a virtual Machine is renting a slice of computing time from the physical processor. By default, virtual machines are allocated one vCPU each. If the physical host has multiple CPU cores at its disposal, then a vCPU essentially becomes a series of time slots on logical processors assigned to VM.

Logical Processor Math: Inside your physical processor, you can have more than one operations unit, called Core. Normally a physical processor core can only handle one thread (aka operation) at a given time (processor time slot). But when the technology Hyper-Threading is activated and supported, the Core can handle several threads (hyper threads) at once. Hence the number of hyper threads the core can support translates into number of logical processors the physical CPU can serve to the VM. So in short:

            Cores Count = Processor Count * CoresCountPerProcessor

            Logical Processor Count = CoresCount * ThreadCount

            So for a Quad Core processors, say Intel Xeon E3-1230 server with Hyper-Threading:

            Logical ProcessorCount = 4 * 2 = 8.

An Intel Xeon E3-1230 processor with four physical cores and HT enabled results in 8 logical processors. A virtual machine with 8 vCPU's will look a bit like this:

Memory Virtualization

A guest operating system that executes within a virtual machine expects a zero-based physical address space, as provided by real hardware. Memory Virtualization gives each VM this illusion, virtualizing physical memory by adding an extra level of address translation. In traditional computer architecture, the OS is responsible for allocating physical memory to processes which run inside its own process virtual address space. When accessing memory, the process virtual address must be translated by hardware memory management unit (MMU) to traverse the corresponding page table setup by the OS. When running inside the hypervisor environment, one more in-direction of memory address translation is performed.

As shown by the figure below, when running on the hypervisor the guest OS maintains a mapping from guest virtual addresses (GVA) to guest physical addresses(GPA), and the hypervisor translates from guest physical to machine physical addresses (MPA), i.e., the real physical addresses used to access the memory. Accordingly, the Machine Frame Number (MFN) is a page number in the machine physical address space whereas the Guest Frame Number (GFN) is a page frame number in the guest physical address space. Normally, each GFN of a guest OS is mapped to a unique MFN allocated by the hypervisor. The hardware page table used by hypervisor to translate from guest physical to machine physical address is usually referred to Guest physical to machine physical (P2M) table. In modern CPU architecture, most CPU now has hardware support for memory virtualization techniques. Taking Intel VT (Virtualization Technology) [1] as an example, when the Extended Page Table (EPT) feature is enabled in the Intel CPU, the hardware MMU, and for each memory access from guest VM, the process is as follows: 1. Walk through the page tables used by guest OS to translate from GVA to GPA 2. Walk a separate page table, i.e., EPT, setup by hypervisor to translate from GPA to MPA. Thus, the conceptual P2M table mentioned above just maps to the EPT table in the case of Intel architecture.

Storage Virtualization/Hypervisor

A storage hypervisor is a supervisory program that manages multiple pools of storage as virtual resources. It treats all the storage hardware it manages as generic, even though that hardware includes dissimilar and incompatible platforms. To do this, a storage hypervisor must understand the performance, capacity, and other service characteristics of the underlying storage, whether that represents the physical hardware, such as solid-state disks or hard disks, or the storage architecture such as storage-area network (SAN), network-attached storage (NAS) or direct-attached storage (DAS).

In other words, a storage hypervisor is more than just a combination of a storage "supervisor" and storage virtualization features. It represents a higher level of software intelligence that controls device-level storage controllers, disk arrays and virtualization middleware. It also provisions storage, provides services such as snapshots and replication, and manages policy-driven service levels. The storage hypervisor provides the technology on which software-defined storage can be built.

Network virtualization

Network virtualization involves dividing available bandwidth into independent channels, which are assigned, or reassigned, in real time to separate servers or network devices.

Network virtualization is accomplished by using a variety of hardware and software to combine network components. Network virtualization is categorized as either external virtualization or internal virtualization. External network virtualization combines or subdivides one or more local area networks (LANs) into virtual networks to improve a large network's or data center's efficiency. A virtual local area network (VLAN) and network switch comprise the key components. Using this technology, a system administrator can configure systems physically attached to the same local network into separate virtual networks. Conversely, an administrator can combine systems on separate local area networks (LANs) into a single VLAN spanning segments of a large network. Internal network virtualization configures a single system with software containers, such as a VNIC, to emulate a physical network with software.

Shak Kathirval
Application Architect, Architecture
__________________________________________________

Pragmatism and Enterprise Architecture

Hypervisor – the magic behind virtualization

Musings for Mar 2016

Does the market microstructure matter?

population-with-bachelor-degree-or-more

the caudillo