December 2017 – nettech Blog

December 9, 2017

1000 Cloud Servers: Start With One Click

Cloud and Open Source

The arrival of Cloud providers and Infrastructure-as-a-Service (IaaS) has opened up options and possibilities for solution architects. Our company is working with a client on a major transformation initiative. Leveraging Cloud IaaS and open-source integration platforms, together we have explored options, built competence, and delivered incremental solutions while keeping costs to a minimum. Without Cloud IaaS and open-source this freedom of expression in solution architecture would have been impossible. Just imagine justifying a multi-tier, multi-server solution to the CFO when one of the key drivers has been cost control!

The Basic Idea

In its most primitive expression, our client wanted a public Application Program Interface (API) layer to abstract access to an Integration layer, which in turn connected with all their internal repositories and partner systems to provide services. The image that follows provides an illustration. It appears quite straightforward and simple.

The API layer provides a simple Representation State Transfer (REST) interface as well as security. It also maintains logs that can be analysed for insights into client behaviour and the usage/performance of services. The Integration layer serves as an Enterprise Service Bus (ESB), connecting to databases, FTP and/or file servers, as well as internal and partner web services. In addition, it manages the interactions between all participating systems in the enterprise and ensures that valuable services are made available to the API layer.

Enter Cloud (AWS/Azure) and Open Source (WSO2)

The traditional route would have been to procure/secure access to servers in a data-centre or in-house server-room and buy licenses from a vendor. That would have meant a lead time of several weeks or months, to negotiate the price of licenses and consultancy, arrange for servers and networking, and to secure and disburse requisite financing. With Cloud and open-source software, upfront costs were near-zero. The greatest resource demand was the effort required to architect the Cloud infrastructure and to create the code to build, populate and operate it.

Building the Foundation

There were many options for building the networking and computing instances. We chose Kubernetes. Kubernetes is well established and provides abstractions that make it easy to switch Cloud providers. Using the analogy of a house for illustration; Kubernetes builds the shell of the house, setting up the rooms, corridors, and spaces for windows and doors. It keeps a record of each component, and notifies all other components if there has been a change to any one of them. In our use case, Kubernetes creates a private network in the Cloud (cluster), adds compute-instances, load-balancers, firewalls, subnets, DHCP servers, DNS servers, etc. Kubernetes also provides a dynamic registry of all these components that is kept up to date with any changes in real time.

The First Change: Redundancy

In the past, vertical scaling with large singleton servers was standard. These days, horizontal scaling with smaller machines (compute instances) that adjust to changing needs is the norm. This new approach also provides fail safety. If one machine fails, there will be other(s) to take up the load. Fortunately this is a core feature of Kubernetes. The cluster monitors itself to ensure that all the declared components are kept alive. If/when a component fails, the management services within the cluster ensure that it is replaced with an identical component. For this reason, rather than have one instance of each component, two or more are created and maintained.

The Second Change: Dynamic Delivery

We could have chosen to install all of our technology stack (software) on each compute instance on creation. That would be slow though, and it could mean that the instances would need to be restarted or swapped-out more often as memory and/or disk performance degrade. Instead of that, we used Docker to build Containers that are delivered to the instances. The Docker Containers borrow memory, CPU and other resources from the compute instance at the point of deployment. Containers can be swapped in and out, and multiple Containers can be run on the same compute instance. When a Container is stopped or removed, the block of borrowed resources are returned to the compute instance. A Container can be likened to a prefabricated bathroom; it is built offsite and plumbed in at delivery. Unlike a technology stack that is built from scratch over minutes or hours, a Container is usually ready for access within a few seconds/minutes of its deployment.

Implicit Change: Clustering

When more than one instance of a genre component is running at the same time, the complement of all is referred to as a cluster. Components running in a cluster have peculiar needs; one of which is the sharing of state (status). State is a snapshot of the world from the computer’s perspective. In a cluster, all component instances must share the same configuration and operate on the same data always. To facilitate this, we introduced two repositories. A Network File System (NFS) for sharing configuration details, and a database for sharing operational data. Kubernetes does not create these resources. We used Terraform, another abstraction technology, to create the NFS and a replicated multi-zone database. Terraform creates these in two private subnets within the private network created by Kubernetes. Having created the NFS and database though, there was a need to configure and populate them with necessary data upfront. While Terraform could be manhandled to achieve this, it is not really it’s raison detre. Another tool is more suited to operating at a fine detail on remote machines: Ansible. We created Ansible playbooks to configure users, directories and files on the NFS and to create instances, users and tables in the database.

Implicit Change: Discovery

The next challenge that our architecture threw up was discovery. Within our network, there was an API layer and an EI layer. In each of these layers, there could be several compute instances, and on each compute instance there could be one or more Docker Containers. Beyond the API and the EI layers, there were also databases and a network file system. How would clients or our platform gain access to our components, and how would the machines in one layer find those in another layer? The Kubernetes configuration includes ClusterIP services that provide a single DNS name that resolves to all the compute instances for a given component. For example, any API Container could be reached using a DNS name such as: cnt.api.example.com. Clients of our platform could therefore use a DNS name to connect to an API Container, and any API Container could likewise use a single DNS name to communicate with a Docker Container in the EI layer. Both the API and EI layers use a DNS name to communicate with the NFS and the database. The IP address of the underlying components might change, but the DNS name is constant for the life of the platform, giving ease of discovery and stability.

Tying it all Up

It is all well and good that the components in the Cloud are in place and can talk with each other. However, most of our operational systems are still on-premise; how do we join things up? We created a VPN connection between the network in the Cloud and our on-premise network and set up Firewall rules to allow access to and from the Cloud. The ClusterIP services were also revised to permanently maintain two static IP addresses. This makes it easy to integrate them with on-premise DNS servers and thereby open them up to access from clients. Below is an image that shows what it all looks like.

The Thousand Servers

All of these components, configurations, and customisations have been documented as scripts, configuration files and resources. The creation of a Cloud environment is reduced to running a script with two parameters: the name of the environment and the desired Cloud subnet. By integrating this script into an on-premise CI/CD server, it is now possible to spin up as many Cloud environments as we like; at the click of a button.

All this is quite high-level and simplified; in the next instalment (One Thousand Servers: Start with a Script), I intend to drop down to eye-level and throw up some of the details of how we implemented all of this. Watch this space for the activation of link above.

—
Oyewole, Olanrewaju J (Mr.)
Internet Technologies Ltd.
lanre@net-technologies.com
www.net-technologies.com
Mobile: +44 793 920 3120

December 8, 2017July 8, 2019

Factory Approach to Service Engineering – Preamble

World of Perspectives

We all see the world from different perspectives, and the sum of perspectives help us to get a better/fuller understanding of our world. In this article, we share a perspective on engineering services for business. This perspective can be summarised as: Intelligent Laziness – strategies to achieve equal or better productivity with equal or less effort and minimal stress. To illustrate how we try to achieve this, we will use five metaphors:

Factory
Pattern
Framework
Process
Service

PowerPoint Summary: A Factory Approach to Service Engineering

The Factory – First Glance

When people think of factories, they imagine the primitive/simple product-focussed line that spews out large numbers of identical, low-value items.
http://www.verbolt.co.za/company-home.htm
But there is another perspective; the advanced/composite service-focussed systems that create a few bespoke high-value units to specific customers.
http://www.orangecountychoppers.com/
There are similarities, in that both are repetitive and they both transform inputs to outputs. But there are significant differences too. The primitive factory involves lower risk, and less complexity whilst the advanced factory multiplies risk due to composition and customisation. There is a direct relationship between value and complexity, and it is often the case that the advanced factory uses outputs from primitive factories.

But factories occur in software engineering too, and the underlying principles apply here too. Whereas it is common to talk of dichotomy in software engineering: is it a science or an art? Software factories do not suffer such ambiguity. For every factory, whether hardware or software, two principles always apply:

The outcomes are predictable
The process is repetitive

Careful study of any system reveals re-occurring things/trends the production of which can be achieved with the factory principles. This is equally true in a McDonalds restaurant as in a Rolls-Royce workshop. This is also true in software engineering, especially service engineering.

The Pattern

The re-occuring things/trends in a factory are patterns. The predictability of the output of a factory and the fidelity of repetition depend on patterns. Patterns are fundamental to factories. In a factory, there is a need to understand what is to be produced and the patterns that are involved in its production. Each pattern is a kind of template. Given certain input and application of the template, a given output is guaranteed. A factory is likely to involve mastery of one or more patterns, depending on the type of factory. Fewer patterns generally reflect superior understanding of the problem domain. However, some patterns go through special evolution (exaptation) and could become the focus of a factory in their own right.

The Framework

The collection of patterns required to create a given output can be described as a framework. A good analogy is a box of Lego. It is a composite of patterns, which can be put together to create the structure illustrated on the box/packaging. The framework identifies all requisite patterns for a given output, and usually in a given technical/business context. Each pattern in a framework form synergies and are known to be beneficial in the specified context; examples of frameworks include building regulations (hardware) or Oracle AIA (software).

The Process

Of course having all the pieces of a Lego is insufficient to construct the picture on the box. The process elevates the framework from static to dynamic. The process describes how the patterns in a framework are to be sequenced and aggregated in a way that delivers synergy and the best output. The framework is a snapshot, whereas the process describes a flow from conception to completion. For business services, the process is the first point where IT and business meet. The process shows how value can be created while hiding (abstracting) the taxonomy/ontology of patterns and the framework(s) employed.

How does all of this come together, especially in our daily lives as software engineers serving businesses? And how does this help our clients (the business) better compete? Join me in the next instalment where I will be looking at the benefits, business connection, and potential future impact.

—
Oyewole, Olanrewaju J (Mr.)
Internet Technologies Ltd.
lanre@net-technologies.com
www.net-technologies.com
Mobile: +44 793 920 3120

December 8, 2017December 8, 2017

Factory Approach to Service Engineering – Business

From Technology to Business

In a previous article, I looked at how some metaphors can be used to understand the engineering of software (services). Of the five listed below, I introduced the first four.

Factory
Pattern
Framework
Process
Service

The first three have a clear technical focus; the fourth is a gateway between the technical world and the business world. The fifth though is where the business focus becomes paramount.

IT is an enabler – no one invests in technology for itself, rather it is for what IT can do for business. The service is the business perspective on the process. It focusses on how all those patterns and frameworks abstracted within those processes can be put to work for business. But even business is not without patterns! Every business operates in a sector, and belongs to a genre. For every business genre, there are certain must-have competencies common to all participants, as well as some differentiators that are peculiar to some players. The build up from our patterns to the processes must be honed to effectively serve out clients; the business, who themselves have clients: the buck-paying end-users.

The Service as Business Nexus

The reliability, efficiency and quality of our technical processes must feed into our business clients and aid their agility. A business that is supported by factories at different levels (pattern, framework, process) is more able to adapt to a changing environment. Such businesses are able to recombine solutions at different levels of granularity to address emerging needs.
It is vital to make a distinction between software-engineering per se and service-engineering. At the different levels of the vertical hierarchy of software, there are factories that have no alignment to any business whatsoever. They are simply technology enablers. The focus here is on services, i.e. software that is “client” driven. In a Service Oriented Architecture (SOA) there is an intrinsic/instinctive alignment to business. I go even further to speak of a “fundamentalist SOA“, characterised by the following principles:

Build Best
Owner-Agnostic
Interdependent Services
Service Ontology
Attritional Evolution

We should build on Steven Covey’s (The 7 habits of highly effective people) principle of interdependence and Steven Johnson’s (Where good ideas come from) ideas of next-adjacent, serendipity and exaptation. Everyone should not build everything. No one should build just for themselves. But let every output be seen as a target (service) for the genre or sector/industry rather than the department or the company.

There are significant benefits to this mindset:

Cheaper solutions: due to successful scaling of a few best patterns
Easier, Faster: due to extreme specialisation of the most successful patterns
Simpler Maintenance: due to deep understanding of the pathology of the patterns
Fewer Faults, Quicker Fixes: due to clear modularity/decomposition of the patterns
Better Scalability: due to to built-in fundamental qualities of patterns
More/Better Output: as patterns are re-composed at higher levels of abstraction

But these kind of solutions are themselves products of a new learning. This learning is focussed on the core nature of the problem rather than its specifics. It is meta-learning that looks for patterns in the problem domain and then maps each to a resolver in the solution domain. This Weltanschauung delivers, and it is an enabler for federation of output as seen in open-source software. It is a value well demonstrated in Amazon Web Services. Without this mindset, corporations like YouTube or DropBox would not have gotten off the ground. With it, the evolution of novice to expert is more likely to be successful and the duration of the transform is more predictable and much shorter. One expects that all this would also produce more of Jeff Bezos “work-life harmony” for those involved. As well as better and cheaper output for those buck-paying clients, at all levels!

Plus ça change … ?

Computers know nothing! Deep-blue would not know how to crawl out of a pond if it fell into one. But we can teach it to. We communicate with machines through patterns; the patterns represent an abstraction of our language and knowledge. The patterns help us to teach machines, and thereupon to delegate to them. Better abstraction means we can get more out of the machines. The patterns are our bridge to the nebulous machine world.

Increasing the variety and the speed at which we add abstractions will hasten the metamorphosis of ideas to reality. Each one extends our metaphorical bridge; from the machine end to the human end. As we do so, alterations to our present reality will emerge ever faster, as our most abstract ideas and desires are projected across bridge of abstraction into new and tangible experiences. The foundation of all this is and will be unavoidably linked to those principles that we started with earlier: the factory, pattern, framework, process, and service.
That is my (view point) perspective.

Good day and God bless.

—
Oyewole, Olanrewaju J (Mr.)
Internet Technologies Ltd.
lanre@net-technologies.com
www.net-technologies.com
Mobile: +44 793 920 3120