Building A Niche Cloud: A Pragmatic Approach

Posted by

0

Teamwork-ants-building-a-house

source: https://innolectinc.com/how-smart-is-your-team/teamwork-ants-building-a-house/

Overview

Before getting started you might want to read about the birth of the niche cloud in the first part of this two part series.

We have all heard the saying, you cannot teach an old dog new tricks. Yes that is true, but we aren’t thankfully dogs. Learning to do something new of course, requires an open mind-set and a desire for change. Many organizations are getting left out of digital disruption these days because they keep falling back on old outdated ideas, behaviors and habits. Our minds are so full, so occupied and so tired we simply cannot grasp or don’t have the energy for anything new. We spend our time applying what is new to what we know, which is old.

In this article lets reset our minds and look at an approach to build a niche cloud from the ground up. Instead of pealing back the onion we will apply layer after layer until we have the onion itself. Of course I realize there is a lot more and this article is just scratching at the surface, nevertheless it is an approach, a basic rule-set and guideline for getting started.

Continue reading →

OpenStack 14 (Rocky) Lab Installation and Configuration Guide for Hetzner Root Servers

Posted by

0

rdo

Overview

In this article we will focus on installing and configuring OpenStack Rocky using RDO and the packstack installer. RDO is a community platform around Red Hat’s Enterprise OpenStack Distribution. It allows you to test the latest OpenStack capabilities on a stable platform such as Red Hat Enterprise Linux (RHEL) or CentOS. This guide will take you through setting up Hetzner root server, preparing environment for OpenStack, installing the OpenStack Rocky release, adding a floating ip subnet through OVS, configuring networking, security groups, flavors, images and are other OpenStack related services. The outcome is a working OpenStack environment based on the Rocky release that you can use as a baseline for testing your applications using OpenStack capabilities. The installation will create an all-in-one deployment however you can use this guide to create a multi-node deployment as well.
Continue reading →

The Birth of the Niche Cloud?

Posted by

0

1200px-Flightless_Dung_Beetle_Circellium_Bachuss,_Addo_Elephant_National_Park,_South_Africa

source: https://en.wikipedia.org/wiki/Ecological_niche

Overview

In this article we will take a step back from my typical technical discussions and how-to guides to think about the path that lies ahead of us, in our industry. Today we have a very polarizing environment, similar in fact to the US political system.  On one side you have extremely customized on-premise environments that serve specific purpose or business niches but on the whole are hard, if not impossible to maintain and very costly. On the other side you have generic public cloud, infrastructure that always works (well almost, nothing is perfect), scales and is available at click of a button with predictable pricing structure but doesn’t fit specific purpose by default.

The industry has for many years recognized these worlds were growing further apart and defined the solution as hybrid cloud management to manage them or even bridge the worlds. But gluing two polarized worlds together was only ever destined to fail. Hybrid cloud, which often drags with it the management, is dead. I think more are interested in talking about multi-cloud and I see multi-cloud replacing what hybrid cloud once stood for. I see container platforms providing the glue, management platforms once promised.

The same battle purpose built vs generic repeats itself over and over in all facets of our lives. The truth is we need both. In this article we will explore a new thought or idea, called niche clouds which could provide a purpose built cloud of the future.

Continue reading →

OpenStack 13 (Queens) Lab Installation and Configuration Guide for Hetzner Root Servers

Posted by

2

rdo

Overview

In this article we will focus on installing and configuring OpenStack Queens using RDO and the packstack installer. RDO is a community platform around Red Hat’s Enterprise OpenStack Distribution. It allows you to test the latest OpenStack capabilities on a stable platform such as Red Hat Enterprise Linux (RHEL) or CentOS. This guide will take you through setting up Hetzner root server, preparing environment for OpenStack, installing the OpenStack Queens release, adding a floating ip subnet through OVS, configuring networking, security groups, flavors, images and are other OpenStack related services. The outcome is a working OpenStack environment based on the Queens release that you can use as a baseline for testing your applications using OpenStack capabilities. The installation will create an all-in-one deployment however you can use this guide to create a multi-node deployment as well.
Continue reading →

Satellite on OpenStack 1-2-3: Systems Management in the Cloud

Posted by

0

Logotype_RH_Satellite_RGB_Black plus_signopenstack

Overview

In this article we will explore an important part of day 2 operations in OpenStack or any IaaS, systems management. There are two ways to maintain applications: immutable or lifecyle. Satellite is a product from Red Hat that focuses on lifecycle management. Specifically the deployment, updating, patching and configuration of Red Hat Enterprise Linux (RHEL) as well as the applications running on top throughout entire lifecycle. We will discuss the value Satellite brings to OpenStack and why systems management is a key part of day 2 cloud operations. Investigate the Satellite architecture and how it applies to OpenStack. Finally we will go through hands-on deploy of Satellite on OpenStack, even deploying an instance and automatically connecting the instance to Satellite, all using Ansible.

The Value of Satellite in OpenStack

Satellite is the second product Red Hat created after RHEL. It has been around for over 10 years and recently gone through a major re-architecture from ground up to address cloud. Red Hat customers have used Satellite to create a standard operating environment (SOE) for RHEL and the applications that run on RHEL for 10+ years. Satellite provides the ability to create various content views and bring them together in a composite content view (a group of content views). This allows us to group content (RPMs, configuration management, Tar files, whatever else) and most importantly version it. Once we can group software and version it we can start thinking about release management across a lifecyle environment. A lifecycle environment is typically something similar the holy trinity: development, test and production. The versions of software for our OS and applications of course vary, you don’t want to update software in production without testing in development or test right?

Continue reading →

OpenShift: Getting Started with the Service Broker

Posted by

2

Logotype_RH_OpenShiftContainerPlatform_wLogo_CMYK_Black

Overview

In this article we will look at the OpenShift service broker, understand how to integrate external services into OpenShift and even create a custom broker. First before we begin a big thanks to Marek Jelen and Paul Morie, Red Hatters who both helped me understand the service broker in greater detail.

Obviously if you are reading this article you already understand microservices, containers and why it is all so incredible awesome on OpenShift. Of course everything should be in a container but unfortunately it is going to take a while to get there. As we start dissecting and breaking down the monolithic architectures of the past, likely there will be a mix of lightweight services running in containers on OpenShift and other more heavy services (databases, ESBs, etc) running outside. In addition while the service catalog in OpenShift is vast, even allowing you to add your own custom services for anything that can run in OpenShift as-a-container using a template, there will be the need, especially with public cloud to connect to external services. Both of these use cases, on-premise external services and off-premise cloud services really made it obvious that a service broker and more robust service catalog was needed. Originally OpenShift did not have a service broker so you couldn’t easily consume external services. All that existed was the service catalog and templates, so every service had to be a container running on OpenShift. Thankfully other companies also saw a need for an open service abstraction and the Open Service Broker API was born as an opensource project.

Continue reading →

Disaster Recovery with Containers? You Bet!

Posted by

0

disaster-recovery

Overview

In this article we will discuss the benefits containers bring to business continuance, reveal concepts for applying containers to disaster recovery and of course show disaster recovery of a live database between production and DR OpenShift environments. Business continuance of course is all about maintaining critical business functions, during and after a disaster has occurred.  Business continuance defines two main criteria: recovery point objective (RPO) and recovery time objective (RTO). RPO amounts to how much data loss is tolerable and RTO how quickly services can be restored when a disaster occurs. Disaster recovery outlines the processes as well as technology for how an organization responds to a disaster. Disaster recovery can be viewed as the implementation of RPO and RTO. Most organizations today have DR capabilities but there many challenges.

  • Cost – DR usually is at least doubles the price.
  • Efficiency – DR requires regular testing and in the event of a disaster, resources must be available. This leads to idle resources for 99.9% of the time.
  • Complexity – Updating applications is complex enough but DR requires a complete redeployment where the DR side almost never mirrors production due to cost.
  • Outdated – Business continuance only deals with one aspect,  disaster recovery but as mentioned cloud-native applications are active/active so to be effective today, business continuance architectures must cover DR and multi-site.
  • Slow – DR often is not 100% automated and recovery is often dependent on manual procedures that may not be up to date or even tested with the latest application deployment.

I would take these challenges even further and suggest that for many organizations business continuance and DR is nothing more than a false safety net. It costs a fortune and in the event of a true disaster probably won’t be able to deliver RPO and RTO for all critical applications. How could it when DR is not part of the continuous deployment pipeline and being tested with each application update? How could it with the level of complexity and scale that exists today and not 100% automation?

Continue reading →