Photo by Chronis Yan on Unsplash

Infrastructural Maturity and Return of Investment (ROI) with Containerization

The basics categories for Infrastructural Maturity are:

  • Manual & Domain Centric Infrastructure
  • Automated Provisioning (IaC) with Implied Configuration as Code (CaC)
  • Decoupled Infrastructures
  • Cloud-Native Approaches for Both Cloud Service Providers and On-Prem
  • Services on Demand with Implied Base Models

Manual & Domain Centric Infrastructure

This phase describes the infrastructure which requires a higher level of oversite and integration. These infrastructures can include:

  • Service Level Agreements (SLA)s that require third parties to change any aspect of the infrastructure. This can cause issues with scalability and availability when demands are higher than normal. This can also cause a budget concern when the demand is set way higher than what is actually represented by the metrics.
  • Noncentrallized state management system. This could lead to chaos engineering within your infrastructure. A possible loss of asset management can occur if state management is captured between physical machines and not a centralized location.
  • Continuous technical debt without the speed of innovation. This reference that most organizations are “under staff” leaving only time to deal with “keeping the lights on” instead of continuously improving. Hard to innovate when locked down by SLAs and budget restrictions. An increase in security goes hand in hand with technical debt. This can include outdated maintenance/security patches, increase Common Vulnerabilities and Exposures that cannot be assessed, and de-supported software.
  • Lack of continuous integration systems. In today’s world infrastructure is now written like code. This includes Continous Integration (CI) systems with central state management which allow teams around the world to work together to meet a common goal. The CI systems allow for fast feedback.

Automated Provisioning (IaC) with Implied Configuration as Code (CaC)

Now your teams are starting to realize the power of Infrastructure as Code (IaC) and Configuration as Code (CaC). These two can make the world of Configuration Management happy. This area can range from On-Prem, Hybrid, Cloud Native, to the Internet of Things (IoT) approaches. We have to remember that things in the cloud reside on something as well.

This infrastructure category can include:

  • Migration of hands-on to code-generated provisioning. This means that the current infrastructure is being transferred into code. This not only includes virtual machines/nodes but the capability of moving the entire architecture as well.
  • Change Management as Code. What does change management with code represent? Well in the word of change is configuration management. During this aspect, both change management and configuration management collide with code. This is a HUGE game changer. Taskers such as security patches, maintenance, or architecture innovation are now version-controlled and release orchestrated.
  • Agnostic full-stack delivery. As environments start to mature so does the capability of removing proprietary components. Proprietary components can lock down an organization and provide technical debt if the infrastructural component one day de-support itself. Organizations are realizing that technical debt causes high overhead and increases time to market. Infrastructure is not being decoupled by using tools such as Terraform which utilizes providers to communicate to third-party APIs or CLIs.

Decoupled Infrastructures

Provisioning infrastructures and continuously updating them with CaC is one thing, but another is decoupling it. Decoupling allows the capability of an organization to remove “Vendor lock-in”. What is vendor lock-in? This is when an organization specifically identifies a product to be the complete solution for all its delivery needs. Technical debt is included as components for the Software as a Service (SaaS) are de-supported or changed. Changes within a SaaS can cause a required involuntary change to the objectives of a product that increases the time to market.

This infrastructure category can include:

  • Decoupling entire platforms. Organizations are now migrating entire servers. What does this look like? Well instead of utilizing IaC to provision initially and then CaC to deal with change; containerization is being used. Containerization allows organizations to mitigate the risk far left.
  • Shifting left with Containerization. Developers and engineers are now morphing together. The world of being just a developer or an engineer is no longer good enough. Yes, there are positions out there that do look for just a Java developer or an Oracle Engineer, but they are a dying breed. The next level up is a so-called “Full-stack developer” where developers are to know multiple languages allowing an organization to do more with less.

Cloud-Native Approaches for Both Cloud Service Providers and On-Prem

Cloud-native can be misinterpreted for containing an infrastructure within a Cloud Service Provider (CSP). Most common CSPs of Amazon Web Services, Google Cloud Platform, or Azure. However, Cloud Native architectures can reside on On-Prem systems. Basically an On-Prem system with a container and functions as a service orchestration system.

This infrastructure category can include:

  • Decoupled within a Platform as a Service (PaaS). This is the process when infrastructure is decoupled, however, requires some sort of Orchestration system. These orchestration systems are “cloud agnostic” making it very easy to shift from one cloud service provide to another. Basically, this means that the same tools can be utilized therefore and an organization can orchestrate the delivery around the tool instead of around the Cloud Service Provider or Infrastructure.

Services on Demand with Implied Base Models

As infrastructures mature so does the capability of determining when services should be rendered or not. The world of microservices is ever-increasing but so does the cost if left unmitigated. That is where this infrastructural maturity comes in. As infrastructure, they can completely build-up to full infrastructures for services in minutes. This can be done with cloud functions such as Lambda on AWS to quickly execute code to provide to the customer.

This infrastructure category can include:

  • On-Demand Services based on Actual Demand. This reference the capability of not scaling up or down but provision on demand. The demand is the actual need from the customer utilizing the service. This means that code is pushed to build the infrastructures and functions as a service are utilized to provision them.

Enterprise Solution Architect | Certified Kubernetes Administrator ⚓ | SAFe SPC | LeSS Practioner | AWS Solutions Architect | Dev*Ops/GitOps Engineer 🔥

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store