A goal of modern software development teams is to rapidly and reliably build, test, and deploy applications. For cloud-native teams, this means not just automating application code delivery in a CI/CD pipeline but also automating cloud infrastructure build-out.
In this blog, you’ll explore:
Use the links below to jump to each section:
Let's start with CI/CD pipelines and Infrastructure as Code.
A Continuous Integration/Continuous Deployment (CI/CD) pipeline is an automated process that your software development team creates to deliver their software applications.
The CI/CD pipeline includes the necessary steps to transform lines of code into executing applications. These steps typically include building, testing, and releasing.
Historically, software development teams and their CI/CD pipelines only focused on the software application. The infrastructure (whether physical or virtual) that hosted the application was merely a resource that the CI/CD deployment step would assume to exist. In the past, separate teams owned the cloud infrastructure.
Today, cloud-native software development teams seek to remove assumptions by owning the full infrastructure stack that their software applications depend on. These cloud-native teams want to control the delivery of this cloud infrastructure using the same CI/CD pipelines that control the delivery of their software applications.
Cloud-native development teams define their needed cloud infrastructure in JSON syntax so this infrastructure definition can be version-controlled and stored alongside the software application code in GitLab or other source code repository. This is called Infrastructure as Code (IaC).
Cloud infrastructure such as virtual servers, virtual networks, and API gateways can be defined as JSON code in the same ways that software application logic is written in code. IaC removes the need for a dev team member to click through the AWS Management Console UI provisioning their needed cloud infrastructure (manual “click” sequences would be quite difficult to version control or automate).
Both AWS and Azure offer cloud-native teams the ability to define cloud infrastructure in Terraform or a cloud-specific IaC language (e.g., AWS CloudFormation, Azure ARM Templates).
All aspects of the cloud infrastructure available in the AWS Management Console or Azure Portal user interfaces can also be defined in code, such as Auto-Scaling maximums or the version of Ubuntu operating system on a Virtual Machine.
RapidScale has tooling and processes to more accurately create best-practice IaC based on your technical, commercial, and compliance requirements. Our tools benefit from our proven Terraform, CloudFormation, and ARM template libraries that already have provided the IaC foundation for clients’ audited cloud systems.
Cloud-native software development teams code steps in their applications’ CI/CD pipeline to dynamically provision the needed cloud infrastructure (as per the IaC definition) and then deploy the desired version of their application onto this infrastructure.
The CI/CD pipeline can easily be configured to launch cloned development or staging environments. Cloud-native software developers commonly want their own separate developer-testing environment. Or, a new pipeline step could automatically launch an independent staging environment for the InfoSec team to perform vulnerability testing.
In some cases, CI/CD pipelines launch separate production environments for each customer of the application. This is a novel approach for creating multi-tenancy without re-architecting a legacy application originally created for only a single tenant.
If infrastructure changes are needed (e.g., higher Auto-Scaling limits or an updated Ubuntu operating system version), the team does not make ad-hoc tweaks to the executing infrastructure. Ad-hoc infrastructure tweaks are likely to be forgotten, thus causing some important differences between dev environments and production environments.
For example, the team might find that a certain performance problem is solved by upgrading the webservers from Ubuntu 20 to Ubuntu 20.04. The team could simply apply this operating system patch to the existing webservers, but then the team would need to remember to apply the same patch to their staging and production environments.
Instead, cloud-native development teams make infrastructure changes (e.g., operating system patching) by updating their IaC. This enforces that all infrastructure changes are committed to version control.
Once committed, the cloud-native team deploys changes (application logic, IaC, or both) using their CI/CD pipeline. This combination of IaC and CI/CD pipelines guarantees that the correct combination of infrastructure version and application version are migrated from dev to staging to production.
This combined IaC and CI/CD pipeline process also provisions cloud infrastructure just-in-time, thus optimizing cloud costs. The cloud-native team can now rapidly and reliably develop, test, and deploy enhancements to both their application and its cloud infrastructure.
The cloud-native team can now rapidly and reliably develop, test, and deploy enhancements to both their application and its cloud infrastructure.
Benefits of a combined IaC and CI/CD pipeline process include:
Containerized applications running on Docker or Kubernetes are popular in part because containers are easier to secure and manage than virtual machines with complete operating systems.
Containers are easier to secure because they contain only the minimum O/S components needed to run the application. For example, a Windows Server container probably would not contain the Windows GUI—this Windows component does not benefit Windows’ ability to host the application.
This minimization decreases the operating system’s attack surface and helps harden the container against malware or intrusion attacks. Also, the container’s minimum O/S is less likely than a full operating system to require O/S patches because only patches for those minimum included components must be applied.
Many containers—including containers for different application roles (e.g., backend app Server, frontend webserver)—can be hosted on a single virtual machine. DevOps teams benefit because with containerized applications, they’re responsible for securing and managing fewer virtual machines with complete operating systems.
The CI/CD pipeline processes benefit when the host’s complete O/S is abstracted from the applications that execute within the containers. A change to the host’s complete operating system (e.g., O/S patching) is unlikely to affect applications executing within the hosted containers.
No. Ccontainerization isn’t always feasible. Many applications require deployment on full Linux or Windows operating systems, including:
If your application isn’t containerized and you want to deploy on AWS, then your applications will run on EC2 instances (virtual machines) with complete Windows or Linux operating systems. Each application role (e.g., frontend webserver, backend appserver) will require distinct EC2 instance(s) configured specifically for that role.
Applications hosted on EC2 can still enjoy the benefits of the combined IaC and CI/CD pipeline process. However, your CI/CD pipeline processes must consider that any changes to the complete operating system (e.g., O/S patching) might affect the executing application. The pipeline processes, especially application testing, should also execute whenever any O/S changes occur.
An application’s EC2 instances must be configured, deployed, managed, and monitored. Management tasks include O/S patching, backups, hardening, malware detection, and intrusion detection.
Remember: These are the same types of management tasks that are minimized through containerization, but here, we’re discussing applications hosted on complete EC2 instances.
RapidScale’s AWS Managed Services take over these server management responsibilities so your team can focus on application development. RapidScale has developed the tooling and 24/7/365 processes to perform these tasks in a best-practice and compliant manner.
If your application requires EC2 hosting, RapidScale offers services that provide similar benefits as container technologies, but for applications not architected for containers. Let’s consider these benefits within the context of your application’s IaC and CI/CD pipeline.
As we discussed, your cloud-native application’s CI/CD pipeline process creates both the application and its needed cloud infrastructure. Additionally, your CI/CD pipeline must consider that any changes to EC2 instances’ complete operating systems (e.g., O/S patching) might affect the executing application. The pipeline process should execute whenever any O/S or application changes occur.
Businesses commonly use 3 different IaC and CI/CD pipeline methodologies to reliably and repeatedly build, test, and deploy their EC2-hosted applications whenever application or O/S changes occur:
All these pipeline methodologies can make use of RapidScale's Image Factory to create secure AMIs with the current O/S patches. These methodologies differ in how much of the application and configuration is pre-baked into the AMI versus applied during the EC2 instance launch.
The RapidScale team offers expert advice to help businesses select the optimal pipeline methodology given technical, commercial, and compliancy requirements.
In the Single Golden AMI pipeline methodology, the IaC defines a single golden AMI that is the foundation for all the application’s EC2 instances. Then, as the instances launch, the CI/CD and bootstrap processes dynamically configure the instances’ operating systems and installed applications. Once the launched instance is configured according to its intended compute role (e.g., frontend webserver), the system can start distributing workload to the new instance.
Distinct steps in the Single Golden AMI methodology:
A benefit of the Single Golden AMI methodology is the simplicity of only baking and validating only one AMI.
A downside can be the time and complexity of the various on-launch configurations given the instance’s compute role. For example, the installation and configuration of the nginx webserver delays the introduction of newly launching frontend webserver instances into an overloaded load-balanced resource pool.
For faster Auto Scaling EC2 instance launch times, try a Hybrid AMI IaC and CI/CD pipeline methodology.
In the Hybrid methodology, the IaC defines a separate golden AMIs per compute role. An application typically has different roles like frontend webserver, backend appserver, and worker. Each of these roles has unique configuration requirements and therefore benefits from starting from a role-specific AMI.
For example, frontend webservers may have the nginx webserver component pre-installed and be configured to allow inbound traffic on ports 80 and 443. Backend appservers might only allow inbound traffic on port 443. The worker role might not allow inbound traffic on any port. In the Hybrid methodology, most if not all installations and configurations can be pre-baked into the role-specific AMI.
To balance performance versus maintainability, you need the optimal number of unique compute roles.
When Auto Scaling triggers and additional EC2 instances launch, RapidScale's Configuration Management quickly performs the final agent initializations and the CodeDeploy of your application.
Distinct steps in the Hybrid methodology:
The Hybrid AMI methodology can help you balance flexibility, maintainability, and Auto Scaling launch speed.
For the fastest possible Auto Scaling EC2 instance launch speeds, try the Immutable Infrastructure IaC and CI/CD pipeline methodology.
In the Immutable Infrastructure methodology, the IaC defines a pre-baked AMI per compute role. For example, the “frontend webserver” role-specific AMI will already have nginx and the application’s frontend components installed and will have all O/S configurations (e.g., opened ports 80 and 443) complete.
EC2 Auto Scaling speed is optimized because no additional configurations or application installations are needed at launch time.
Distinct steps in the Immutable Infrastructure methodology:
A downside of Immutable Infrastructure is that some software—including components that your application may rely on and certain anti-malware and intrusion detection agents—can’t be initialized within the pre-baked AMI.
RapidScale helps businesses select between the different IaC and CI/CD pipeline methodologies based on technical, commercial, and compliancy requirements.
RapidScale customers can use the RapidScale's Image Factory to generate AMIs to match their needs in all these IaC and CI/CD pipeline methodologies.
Our RapidScale's Image Factory can apply CIS hardening controls to meet your compliancy requirements. The Image Factory also keeps track of and applies your O/S configurations, latest O/S patches, security agents, and networking configurations.
Our Image Factory automatically tests its newly generated AMIs and offers compliance reports that make audits go smoothly.
RapidScale helps businesses optimize costs through efficient CI/CD.
RapidScale codes best-practice Auto Scaling logic into your IaC to optimally scale your EC2 hosted application. The RapidScale team offers expert advice on what rules should govern the expansion (scale out) or contraction (scale in) of your application to best balance performance versus cost.
Rules typically check for low memory, high disk use, high bandwidth use, slow application responses, or some combination of these. Different components of your application might have different performance needs and thus require unique Auto Scaling logic.
RapidScale’s Auto Scaling logic uses AWS CodeDeploy to automate the deployment of your application’s code to launch EC2 instances.
Our combined Auto Scaling and CodeDeploy IaC logic validates that new EC2 instances launched successfully before joining the new instances into your application’s pool of compute resources. If not, our logic automatically rolls-back and retries the Auto Scaling launch.
RapidScale also has developed CodeDeploy libraries for “blue/green” deployments. Some businesses use “blue/green” to release new application code to only half of their EC2 instances within a load balanced pool.
Our customers’ application dev teams use a wide range of Continuous Integration (CI) tools including Jenkins, TravisCI, GitLab CI, and Bamboo. Any CI tool can be used with our recommended IaC and CI/CD pipeline methodologies.
Your CI tool automates the steps that follow your developers’ code commits, including:
After EC2 instances launch, RapidScale's Configuration Management continuously validates that these running instances maintain the desired O/S configurations, security agents, and networking configurations.
RapidScale's Configuration Management uses puppet and SSM agent to periodically validate each running EC2 instance and to automatically perform any corrective actions.
For example, RapidScale's Configuration Management might detect that an anti-malware agent has crashed on an EC2 instance. RapidScale automatically restarts the agent and then re-runs the validation test.
RapidScale offers expert services including:
RapidScale helps your cloud-native development teams reliably and repeatedly build, test, and deploy applications and their cloud infrastructure, so they can focus on innovative application development.
Your cloud-native application’s IaC and CI/CD pipeline process creates both the application and its needed cloud infrastructure. For containerized applications, your IaC defines two separate portions of compute infrastructure:
RapidScale recommends the Amazon Elastic Kubernetes Service (EKS) to manage your clusters of hosts. Our team creates the IaC that defines your EKS cluster including the initial size and the scaling rules. Your CI/CD pipeline will trigger EKS to deploy the cluster of hosts just-in-time to host your application’s containers.
Once your EKS cluster is available, your CI/CD pipeline will then automatically create and deploy your application’s containers. Then, your pipeline can proceed with automated tests or production use.
Containers require only the minimum O/S components needed to run the application. The container’s minimum O/S is less likely to require O/S patches than a full operating system because only patches for those minimum included components must be applied.
The cluster hosts’ complete O/S is abstracted from the applications that execute within the containers. A change to the host’s complete operating system (e.g., O/S patching) is unlikely to affect applications executing within the hosted containers.
Therefore, the CI/CD pipeline process only needs to run when you change your application or in the rare case that something changes within the minimized container O/S. Your application development teams can focus more on application development and less on managing cloud infrastructure.
Your EKS clusters of hosts can run with the AWS default configuration (“managed clusters”) or can be customized for your specific needs.
RapidScale typically recommends custom configurations when your application requires custom Auto Scaling rules or custom rehydration rules.
EKS Auto Scaling rules balance cost versus performance for your entire EKS cluster. The cluster must grow to support additional containers that might be needed during your peak usage hours. The cluster can shrink when the Auto Scaling rules determine that some containers and hosts are no longer needed.
Rehydration rules govern when the cluster automatically respawns its hosts—usually when you’re deploying updated AMIs or O/S configurations to your cluster’s hosts.
RapidScale offers expert advice on whether your application should use managed clusters or custom Auto Scaling and rehydration rules based on your technical, commercial, and compliance requirements.
RapidScale EKS customers can use the RapidScale's Image Factory to generate AMIs for the clusters’ hosts that run the containers.
Our RapidScale's Image Factory can apply hardening rules to meet your compliancy requirements. The Image Factory also keeps track of and applies your O/S configurations, latest O/S patches, EKS agent, docker agent, security agents, and networking configurations.
Our Image Factory automatically tests its newly generated AMIs and offers compliance reports that make audits go smoothly.
RapidScale's Image Factory AMIs can generate AMIs used for either EKS “managed clusters” hosts or for customized cluster hosts.
Infrastructure as Code cluster architecture including:
These RapidScale services help your cloud-native development teams reliably and repeatedly build, test, and deploy applications and their cloud infrastructure, so they can focus on their application development.
RapidScale helps businesses simplify IT and unleash innovation. With our managed services and strategic partnerships, you can make technology your biggest competitive advantage. To get started, send a message to our team today.