Immutability: Recipe for Cloud Migration Success: Strategies for Cloud Migration, IaC Implementation, and the Achievement of DevSecOps Goals (English Edition)

By Sachin G. Kapale

When migrating to the cloud, how can you minimize the time and effort spent on technical fixes? Creating a fault-tolerant, secure, automated, and scalable cloud on-demand infrastructure is a costly and time-consuming organizational operation. This book teaches you how to migrate infrastructure to the cloud utilizing programmable infrastructure. This book explains various ways to implement immutable infrastructure for scalable and secure infrastructure.

To begin with, the book educates you on how to spot problems in today's infrastructure. The book explores how to use programmable infrastructure to provide immutability at each tier level of a multitier application. It also explains how to use the Unified Modeling Language (UML) to create high-level design architecture artifacts since it is the most straightforward tool for depicting the layout of a sophisticated program. Finally, the book discusses a detailed CI/CD workflow for 3-tier custom-developed application infrastructure.

The reader will complete reading this book with a firm grasp of the fundamentals necessary to execute DevSecOps across a whole infrastructure. The book explains how to put into practice the cutting-edge cloud methodology of infrastructure provisioning using CI/CD pipelines in detail. In addition, the book gives a complete understanding of how to set up immutable multitier infrastructure utilizing programmable infrastructure/infrastructure as Code.

• Language: English
• Publisher: BPB Online LLP
• Release date: Dec 19, 2022
• ISBN: 9789355512109

Book preview

CHAPTER 1

What is Culture Formation?

An object at rest remains at rest, and an object in motion remains in motion at a constant speed and in a straight line unless acted on by an unbalanced force.

--Sir Isaac Newton

So are the organization’s cultural practices.

Introduction

With this chapter, we begin the journey of learning Immutability. In this introductory chapter, we will discuss organizational culture formation and understand how it affects the cloud migration strategy. We will also understand various types of cloud infrastructure offerings. We will discuss multiple migration strategies and study their impacts on various factors. We will try to understand what infrastructure maintenance activities performed in the past are technical debts in the cloud.

Structure

In this chapter, we will discuss the following topics:

Lessons learned from past

Public Cloud Service Providers’ offerings

IaaS or bare metal

PaaS

SaaS

FaaS or serverless

Major migration strategies

Rehosting

Manual

Automated tools

Replatforming

Repurchasing

Refactoring or rearchitecting

Retiring

Retaining

Impacts on other aspects of various migration strategies

Architectural patterns

Mainstream application development

Monolith architecture

Microservices architecture

COTS/Modified of the Shelf (MOTS) product

Understanding of technical debts

Objectives

This chapter explains culture formation in an organization, its challenges regarding DevSecOps implementation, and how a typical organization’s culture impacts DevSecOps implementation. The chapter will also give you an understanding about how your DevSecOps implementation is related to cloud migration. It also discusses the issues related to cloud migration’s lift and shift approach. This chapter identifies the use cases about when to go for immutable infrastructure. Identify the use cases for which you should be using a particular migration approach. It details each use case to address the concern related to Operation and Maintenance (O&M) cost, security of virtual servers, and environment disparity-related issues. It touches on application design from custom in-house developed products to COTS products, which need not be a deciding factor for your migration strategy. It thoroughly dissects each O&M use case, so the readers know about technical debts.

Lessons learned from the past—An example

My wife and I decided to move to an upgraded community place with ammenties. We both had one question in our mind besides logistics. Can you take a guess? What will you do first when you move from one place to another upgraded place? Think about it for the moment. Figure 1.1 is an illustration of a conversation between my wife and me while moving:

Figure 1.1: When we were moving to the new house

You will most likely not carry old, unused stuff accumulated over time.

The same applies to your IT infrastructure. The majority of organizations are looking at cloud transformation. You do not want to carry the same on-premises data center practices into the cloud. Cloud opens the door to many possibilities, and you want to avoid bringing the on-premises technical debts you have gathered over a while. You want to make the best use of cloud-native offerings.

Figure 1.2 represents another example of treating a cloud migration like any other infrastructure migration project. You are too busy moving technical debts with square wheels, while the cloud offers circular wheels for agility to your business. Move into the cloud with a different mindset than on-premises infrastructure. You have followed unfitting practices in the past. There have been many decisions made in the past considering on-premises limitations. It is your chance to adapt to Cloud-Native offerings and say yes to circular wheels.

Figure 1.2: Cloud migration with on-premise practice

Every organization has adapted to a practice that worked in the past for them. In my interaction with multiple clients, whenever we ask why it is done, we get the answer, "This is how it is done here."

That reminds me of another incredibly relevant experiment on practice and culture formation.

The experiment started in a closed cell with enforced boundaries. Experimenters placed a bunch of bananas inside the enclosure on top of the climbable ladder. Later, five monkeys were introduced inside the cell. After some time, one of the monkeys began to climp up the staircase in search of the banana. Immediately, when it touched the ladder, the experimenters began spraying the icy water on the other monkeys. When other monkeys attempted to get the banana, they sprayed the remaining monkeys with icy water. After a while, the monkeys prevented other monkeys from going after the banana.

Once cultural prohibition was established against going to the banana, experimenters stopped putting icy water for the rest of the experiment. After some time, experimenters replaced the original monkey with the new one. Upon noticing the banana, the new monkey went after it. Surprisingly, all the other monkeys attacked the new money. After one more attempt, the new monkey learned that if it tried for a banana and attempted to climb the ladder, it would be attacked; eventually, it stopped going after the banana. It had been assimilated into the cage’s "don’t go for the banana" culture.

Then, another of the original five monkeys was taken out of the experiments and replaced with a new one. As expected, the second new monkey went to the ladder and was attacked. But this time, the first new monkey also took part in attacking with enthusiasm. The experiment continued for quite some time until all the original new monkeys were replaced with new ones.

The new monkey was attacked by the other monkeys each time it climbed the stairs. Most of the relatively new monkeys beating it had no idea why they could not climb the ladder or participate in assailing the newest monkey. In the end, the original monkeys were swapped out. the surviving monkeys had never experienced a cold water spray. However, no monkey ever went up the stairs to reach the banana. They knew, "That’s the way it’s always been done around here." Figure 1.3 is an illustration of the mentioned example:

Figure 1.3: That is the way it has always been done around here

And that is how an organization’s culture is formed: Initially, unrelated and related events are established in response to critical external incidents, but over time, all that remains are firmly held notions. The same will be brought in as either acceptable or not acceptable behavior. With the exit of the original members of the group who were a part of the initial phase when the patterns and standards were established, the origins of these beliefs also vanished. There might be no members left in a long-lived organization who know why given cultural practices are considered acceptable or unacceptable. However, everyone in the organization is quick to uphold whatever the cultural standards may be.

So, are you among those new monkeys who do not know those technical debts? Or you are so busy in your new routine with inappropriate practices that you do not even realize you are living with an inefficient process. It might be one of those things you have inherited from the previous team.

You think you cannot do anything about it because there is sunk cost attached to refactoring or rearchitecting it. However, it is the only way to get the benefits of cloud-native offerings. No Offense, but the possibility is that you are the victim of the Dunning Kroger effect.

Don’t let history and culture dictate your migration strategy; let us look at your migration with a fresh new look.

Public Cloud Service Providers’(CSP) offerings

In this section, we will learn about the multiple infrastructure-level offering and discuss the pros and cons of each offering.

Figure 1.4 shows the various offerings in the cloud and differences in the management of layers:

Figure 1.4: Public cloud offerings

Infrastructure As A Service and bare metal in the cloud

Infrastructure As A Service (IaaS) can be considered the original "as a service" offering. Most CSPs—Amazon Web Services, Google Cloud, IBM Cloud, and Microsoft Azure began by offering IaaS services.

Figure 1.4 shows that most laaS are offered on the virtualization layer. Mostly, IaaS services users can choose between bare metal servers on dedicated hardware, as shown in bare metal service, or virtual machines hosted on shared physical hardware. When it comes to Virtual Machine (VM) on the cloud, the underlying infrastructure is shared with multiple customers, and CSP manages virtualization. Customers can configure, provision, and operate the servers and infrastructure resources via a graphical interface or an essential offering to provision them programmatically using application programming interfaces. In subsequent chapters, we will see how to use these APIs to stand up the entire infrastructure programmatically.

In 2021, certain public CSPs, recently introduced bare metal servers available through the console, where there is no virtualization layer. Some examples are AWS’s third-generation of servers like M6i and C6i. There are like in the hosting layer.

This is, most of the time costliest option, but independence and more control exist, which we will discuss further. IaaS provides access to provisioning servers’ CPUs, memory, storage, and networking resources. All these resources are created on-demand basis. Customers can provision, configure, and use similar to on-premises infrastructure. As shown in figure 1.4, layers marked in yellow are managed by the Cloud service provider, whereas in your data center, you are managing all the layers.

Platform As A Service

Platform As A Service (PaaS) provides one step further offering and provides a cloud-based platform for running and managing applications. The CSP hosts, manage, and maintain all the hardware and software included in the platform operating system, storage, networking, databases, middleware, runtimes, frameworks such as Node.js.net, Java Web container, and so on. In PaaS offerings, all you need to do is bring application code and data. CSPs take care of runtime upgrades, operating system patching and upgrades, automated backups, and more.

Like IaaS, PaaS can also be accessed using a graphical interface. The full application lifecycle, including coding, integration, testing, delivery, deployment, and feedback, can be work collaboratively by development or DevOps teams. As shown in figure 1.4, you have less control over the infrastructure but a more cost-effective solution. You will only be responsible for the application and data in this model. But you are tied up with the cloud vendor and must ensure your application is in line with the runtimes offered.

Examples of PaaS solutions are Google App Engine, AWS RDS, Elastic Beanstalk, Microsoft Windows Azure, and Red Hat OpenShift on IBM Cloud.

Software As A