A success for DevOps: Developing and Deploying Mission Critical Applications

In today’s digital age, businesses rely heavily on technology to remain competitive. This means that the development and deployment of business-critical applications must be efficient and seamless.

Enter DevOps, a methodology that integrates development and operations teams to improve communication, collaboration, and automation to streamline the development and delivery of software. In this success story, we’ll explore how adopting new methodologies helped a company develop and deploy a business-critical application with great success.

The Challenge

A company that provides financial services to small businesses needed to develop and deploy a web-based application that would provide their clients with access to their financial data in real-time. The application needed to be secure, scalable, and available 24/7 to ensure uninterrupted access to critical financial information. The company’s IT team had experience in developing applications but struggled with the deployment process, which was manual and error-prone.

The company was facing challenges in the deployment process, and that was affecting the time to market for their application. They were unable to release new features quickly and were also struggling to ensure the application was always available to clients.

The Solution

To overcome these challenges, the company adopted new methodologies to streamline the development and deployment process. The development team worked closely with the operations team to identify bottlenecks and streamline the process. They implemented continuous integration and delivery (CI/CD) pipelines to automate the build, test, and deployment process. They also used infrastructure as code (IaC) to manage infrastructure and reduce the risk of configuration errors.

The newly adopted methodology allowed the development team and operations team to work together seamlessly, identify the issues in the deployment process, and implement the necessary changes. They automated the process of building, testing, and deploying the application to ensure that it was reliable and scalable. They also used IaC to manage the infrastructure as code, which allowed them to make changes to the infrastructure quickly and efficiently.

The Results

The adoption of a different set of methodologies led to a significant improvement in the development and deployment process. The company was able to roll out new features and updates to the application much faster and with fewer errors. The continuous deployment process also allowed the company to respond quickly to any issues that arose, ensuring that the application was always available to clients. The company’s IT team was able to focus on developing new features and improving the user experience, rather than dealing with deployment issues.

The company was able to reduce its time to market, which allowed them to release new features faster and stay ahead of the competition. They were also able to ensure that the application was always available to clients, which helped to build trust and loyalty with their customers.

Interpretation of Success

The success of this project can be attributed to the effective implementation of DevOps or Platform Engineering methodologies. The integration of development and operations teams allowed for better communication and collaboration, resulting in a streamlined process that reduced errors and improved efficiency. Automation through CI/CD pipelines and IaC reduced the risk of human error and ensured that deployments were consistent and reliable.

The company was able to provide their clients with a secure, scalable, and highly available application that met their business needs. The success of this project demonstrates the effectiveness of DevOps in developing and deploying business-critical applications.

In conclusion, adopting DevOps methodologies can help companies streamline their development and deployment process, reduce errors, and improve efficiency. This can allow companies to release new features faster, reduce their time to market, and ensure that applications are always available to clients.

10x the DevEX!

Recently there has been a shift in language surrounding System Reliability Engineering (SRE) and DevOps to Platform Engineering. Granted these terms have been used in various ways for a while, but how language terms are used gives way to how markets evolve. This post provides a few key areas of thought around ways to ultimately get products to production faster. Remember…code means nothing until it’s in production.

No matter the title, anyone in the pipeline touching production code is part of the team of ensuring success of critical applications in an enterprise. This is an important concept because everyone is part of the larger team and how teams work together ultimately determines the success of any project.

The focus here will be on the actual development team who is primarily writing the code. The code in question would be delivered as microservices running on a K8S cluster. Keep in mind the use of microservices will lend itself to multiple teams individually creating a service for other teams to consume. Already there is significant dependencies and a single line of code has yet to be written.

Each team ultimately needs to consume one or more code repositories, one or more “testing” systems, at least one pipeline for continuous integration, continuous delivery/deployment (CI/CD), and many other systems to get code to production.

The Platform Engineering team is ultimately responsible for ensuring the “platforms” are working in a way to support the developers. Ensuring a great experience is paramount.

The question is how do Platform Engineers continually improve the great developer experience? The answer many teams turn to is to create powerful systems with guardrails or opinions on how they are to be utilized based on the collective understanding of the teams modus operandi or how they work most effectively.

The key to how is reducing the repetitive work, the mundane menial tasks which take a toll on the cognitive workload of developers allowing them to be able to focus on writing good, clean code.

Giving the power to the developers to consume what is needed in a self-service fashion is one major step as is giving a limited set of choices in what toolsets to use. Make it easy for developers to build and deliver software without removing the useful capabilities of the core services.

In the ideal world, limit restrictions on the how allowing choices in using GitOps or ClickOps or using a API vs CLI vs UI. Use a “as a service” approach to create a system built iteratively by the entirety of the team based on direct feedback.

What it all comes down to is the fact that everyone has different ways they want to work. Its the platform engineering team who can help ensure all of the tools are available and functional to create a great developer experience which in turn will increase productivity and get new, shiny things to market faster.

90 days to success in DevOps

Starting a new role? Maybe this is the first foray into DevOps or Platform Engineering? What is needed to “hit the ground running” in a new role? Leaders in high positions of a company typically have a “100 day rule” to prove themselves. Let’s round it out with 3 months of progress for success.

In most enterprises on boarding new talent is typically left to the new employee. This is very unfortunate because the first 90 days of a new role will impact not only the new employee, but their immersion into the culture and their view of the company. Bottom line, in most cases it is up to the new employee to “learn the ropes” in navigating their new position.

The first 30 days

This month is usually the most important for everyone. The first thing a new employee needs to do is find a good mentor especially if they are not assigned one. Seek out those with institutional knowledge who knows how to navigate the company politics. Find someone who knows how the systems work, how to gain the access needed to be successful in the role. The mentor would have knowledge of “how things work” and what is seen as best practice for accomplishing the tasks at hand.

Some things to know:

  • Who’s who in the organization? – an org chart
  • How mature are they as a development organization?
  • What are the processes to put code into production?
  • Are the processes manual or automated?
  • What is the expectation of you on a day to day basis?

There is plenty more to uncover, but this will help to get started. Once the processes are understood and access is granted to perform the role, find some quick wins. Listen closely to where the frustrations may lie within your organization. Maybe the previous employee in this role didn’t automate certain tasks…submit a small PR to help.

It’s important to find some quick wins for many reasons. First it helps “break the ice”. It also shows strengths. Maybe there’s a way to improve some docs. There may be some ideas brought in from previous experience to help with a particular pain point.

The first 30 days is important to uncover the expectations of the team. Talking to stakeholders and “the customer” is important to get a big picture of what works and what doesn’t in order to find quick wins to make an impact early.

Days 30-60

The first 4 weeks are usually greeted with firehose sessions daily. Take a bit to digest everything. Review notes, brainstorm ideas, understand how the team and the company works. Armed with the broader knowledge about the organization, the team, and how things work at a high level it’s time to dig deeper into where the biggest impacts can be achieved.

In this 30 day block uncover:

  • The maturity of the team?
  • What is the approval process for delivering code to production?
  • What steps are needed to approve PRs?
  • How does code flow through the various systems?
  • What amount of QA is performed?

Find ways to help the team be more efficient. Listen to the complaints and see where possible improvements could be made. Again, quick wins are key at this stage. As a fresh face, a lot of times gaining access to otherwise inaccessible groups within the organization is usually fairly easy. Keep an ear to the ground to find ways to create impactful suggestions

It is important to remember as people get to know a new employee the interactions have lasting impacts. Ensure there is adequate listening and relevant questions to get underneath a complaint. Avoid making off hand suggestions, but rather find some common issues. Start to tackle the common issues and socialize improvements. The key here to to avoid “calling the baby ugly”.

Days 60-90

This is where a new employee’s impact can accelerate. At this stage having the access needed to be successful would be complete. Hopefully there’s been a few quick wins, new co-workers are impressed, and there’s been positive impact on the team.

Regular interaction with your leader would have been established. A solid understanding of what is expected is created and the mentor has made an impact. Knowing where to go to get answers if there is a roadblock and knowing how to avoid the “potholes in the road” is key.

This stage is where the “rubber hits the road”. Gaining traction in the day to day and making regular impact to the business is routine at this point. This is where all of the knowledge gained in the first 60 days can be parlayed into a winning hand.

What success looks like

The first 3 months of any new position sets the stage for every new employee. Creating a positive impression on the team helps build credibility within the broader organization and is key to instilling the confidence needed to being successful overall.

It may take far more than 90 days to feel comfortable with the role and that is okay. As long as there is a consistent method for learning and mistakes are not repeated the impact new employees make is usually sustainable for a long time. Make the best of it and keep track of the wins and losses for the inevitable review with “the boss”.

You got this. Go.

What’s missing in Kubernetes

Kubernetes is an open-source container orchestration system that automates the deployment, scaling, and management of containerized applications. It is widely used for its ability to manage containers at scale and is the de facto standard for container orchestration. However, despite its broad adoption, there are still a few missing pieces that need to be addressed to make it fully functional.

Network Setup

One of the main missing pieces in Kubernetes is a proper network setup. Kubernetes allows for the creation of multiple clusters, each with its own set of nodes, but it requires a well-defined network setup to manage communication between these clusters.

Without proper network setup, nodes in the same cluster may not be able to communicate with each other, or there may be issues with cross-cluster communication. This can result in application downtime, loss of data, and other issues that can impact business operations.

One solution to this problem is to use a software-defined networking (SDN) approach that allows for the creation of a virtual network infrastructure. An SDN controller can be used to manage the virtual network infrastructure and provide network services such as load balancing, routing, and security. With SDN, Kubernetes clusters can be properly connected, and communication between clusters can be streamlined.

Security

Another missing piece in Kubernetes is security. Kubernetes provides some basic security features such as role-based access control (RBAC) and network policies, but these are not always enough to secure the entire system.

Security is a critical aspect of any container orchestration system, and Kubernetes is no exception. Kubernetes clusters are complex systems with many components, and securing them requires a multi-layered approach.

To enhance security, Kubernetes clusters should be set up with secure communication channels and encrypted data storage. Additionally, it is important to create and enforce security policies that prevent unauthorized access to the system. This includes implementing identity and access management (IAM) policies, network segmentation, and regular vulnerability scanning.

Monitoring and Logging

Kubernetes also lacks inbuilt monitoring and logging capabilities. While Kubernetes includes some basic monitoring features, such as health checks and resource usage metrics, it does not provide comprehensive monitoring and logging capabilities.

In a production environment, it is essential to have comprehensive monitoring and logging capabilities to ensure the health and availability of the system. Kubernetes clusters should be set up with a logging and monitoring stack that can collect and analyze logs and metrics from all nodes in the cluster. This can provide insights into the health and performance of the system, as well as help identify and troubleshoot issues.

Conclusion

Kubernetes is a powerful container orchestration system, but there are still a few missing pieces that need to be addressed to make it fully functional. A well-defined network setup, enhanced security, and proper monitoring and logging are all essential components of a fully functional Kubernetes environment.

With the increasing adoption of containers and cloud-native applications, Kubernetes is becoming more important than ever. As organizations continue to adopt Kubernetes, it is important to ensure that the missing pieces are addressed to provide a reliable and scalable platform for containerized applications. By addressing these missing pieces, Kubernetes can continue to evolve and improve, providing a robust and secure platform for developers and IT teams.

Running OpenAI in Kubernetes

Using the OpenAI API with Python is a powerful way to incorporate state-of-the-art natural language processing capabilities into your applications. This blog post provides a step-by-step walk through for creating an OpenAPI account, obtaining an API key, and creating a program to perform queries using the OpenAI API. Additionally, an example demonstrating how to create a podman image to run the code on Kubernetes is provided.

Creating an OpenAI Account and API Key

Before building the code, create an OpenAI account and obtain an API key. Follow these steps:

  1. Go to the OpenAI website.
  2. Click on the “Sign up for free” button in the top right corner of the page.
  3. Fill out the registration form and click “Create Account”.
  4. Once an account has been created, go to the OpenAI API page.
  5. Click on the “Get API Key” button.
  6. Follow the prompts to obtain a API key.

Installing Required Packages

To use the OpenAI API with Python, install the OpenAI package. Open a command prompt or terminal and run the following command:

pip install openai

Using the OpenAI API with Python

With the OpenAI account and API key, as well as the required packages installed, write a simple Python program. In this example, create a program that generates a list of 10 potential article titles based on a given prompt.

First, let’s import the OpenAI package and set our API key:

import openai
openai.api_key = "YOUR_API_KEY_HERE"

Next, define the prompt:

prompt = "10 potential article titles based on a given prompt"

Now use the OpenAI API to generate the list of article titles:

response = openai.Completion.create(
    engine="text-davinci-002",
    prompt=prompt,
    max_tokens=50,
    n=10,
    stop=None,
    temperature=0.5,
)
titles = [choice.text for choice in response.choices]

Let’s break this down:

  • engine="text-davinci-002" specifies which OpenAI model to use. This example uses the “Davinci” model, which is the most capable and general-purpose model currently available.
  • prompt=prompt sets the prompt to our defined variable.
  • max_tokens=50 limits the number of tokens (words) in each generated title to 50.
  • n=10 specifies that we want to generate 10 potential article titles.
  • stop=None specifies that we don’t want to include any stop sequences that would cause the generated text to end prematurely.
  • temperature=0.5 controls the randomness of the generated text. A lower temperature will result in more conservative and predictable output, while a higher temperature will result in more diverse and surprising output.

The response variable contains the API response, which includes a list of choices. Each choice represents a generated title. This will extract the generated titles from the choices list and store them in a separate titles list.

Finally, print out the generated titles:

for i, title in enumerate(titles):
    print(f"{i+1}. {title}")

This will output something like:

  1. 10 Potential Article Titles Based on a Given Prompt
  2. The Top 10 Articles You Should Read Based on This Prompt
  3. How to Come Up with 10 Potential Article Titles in Minutes
  4. The Ultimate List of 10 Article Titles Based on Any Prompt
  5. 10 Articles That Will Change Your Perspective on This Topic
  6. How to Use This Prompt to Write 10 Articles Your Audience Will Love
  7. 10 Headlines That Will Instantly Hook Your Readers
  8. The 10 Most Compelling Article Titles You Can Write Based on This Prompt
  9. 10 Article Titles That Will Make You Stand Out from the Crowd
  10. The 10 Best Article Titles You Can Write Based on This Prompt

And that’s it! You’ve successfully used the OpenAI API to generate a list of potential article titles based on a given prompt.

Creating a Podman Image to Run on Kubernetes

To run the program on Kubernetes, create a podman image containing the necessary dependencies and the Python program. Here are the steps to create the image:

  1. Create a new file called Dockerfile in a working directory.
  2. Add the following code to the Dockerfile:
FROM python:3.8-slim-buster
RUN pip install openai
WORKDIR /app
COPY your_program.py .
CMD ["python", "your_program.py"]

This file tells Docker to use the official Python 3.8 image as the base, install the openai package, set the working directory to /app, copy your Python program into the container, and run the program when the container starts.

To build the image:

  1. Open a terminal or command prompt and navigate to a working directory.
  2. Build the image by running the following command:
podman build -t your_image_name . 

Replace “image_name” with the name for the image.

To run the image:

podman run image_name

This will start a new container using the image created and subsequently run the program created above.

Verify the image runs and spits out what the desired output. Run it on a Kubernetes cluster as a simple pod. There are two ways to accomplish this in Kubernetes, declaratively or imperatively.

Imperative

The imperative way is quite simple:

kubectl run my-pod --image=my-image

This command will create a pod with the name “my-pod" and the image “my-image".

Declarative

The declarative way of creating a Kubernetes pod involves creating a YAML file that describes the desired state of the pod and using the kubectl apply command to apply the configuration to the cluster.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: my-image

Save it as “my-pod.yaml”

Outside of automation running this on the Kubernetes cluster from the command line can be accomplished with:

kubectl apply -f my-pod.yaml

This command will create a pod with the name “my-pod" and the image “my-image". The -f option specifies the path to the YAML file containing the pod configuration.

Obviously this is quite simple and there’s plenty of ways to accomplish running this code in Kubernetes as a deployment or replicaset or some other method.

Congratulations! Using the OpenAI API with Python and creating a podman image to run a program on Kubernetes is quite straightforward. With these tools available. Incorporating the power of natural language processing into your applications is both straightforward and very powerful.

containers in arches

Securing cloud native containers

Security, in and of itself, is a broad topic. Container security adds yet another facet to the already nebulous subject of security. In a lot of enterprises today security is first and foremost and the process for securing applications continues to shift left, meaning security is moving to be integrated earlier into the development process. This post will focus on some of the high level tasks and automations developers and operators can implement to mitigate risk.

The issues.

Misconfiguration

The #1 security risk in any cloud native environment is misconfiguration. How do operators know if what they are deploying is secured properly? In a lot of cases, deployments are left insecure for long periods of time without anyone noticing. This is a massive problem, especially for new technologies such as Kubernetes.

Software Defects

Another security risk is software bugs. Every day new vulnerabilities are found in software. Some of the vulnerabilities are minor, but increasingly the discoveries constitute a potentially critical issue when deploying software to a public facing system. Vulnerabilities are “what is known”. There is a signature for each of the known vulnerabilities which can be used to scan software.

However, “you don’t know what you don’t know”. Keep in mind many defects exist which are not known. These are the zero-day vulnerabilities.

Defense-in-depth

Scanning

Scanning software for known vulnerabilities is an absolute must have in any defense-in-depth strategy. However, even the best scanning tools have unknown vulnerabilities (or known limitations). The best defense is offense so creating a system where your container images go through multiple scanners is always a good strategy.

It is important to scan at many different points in the development process and also continually when in production. Any change could potentially be a breach. It is also very important to have layers which would support the other layers if a layer is permeable. Impervious security requires layers and your goal as a security architect is to create impervious security. Read on for other layers.

Network visualization

“It starts and ends with the network”. Kubernetes, being the orchestrator of choice for cloud native deployments, attempts to keep things simple which has lead to a number of CNIs (container network interface) to give platform engineering many choices when deploying workloads. Having something to visualize the network is important, especially when you can act upon those connections. NeuVector provides these capabilities. Being able to quarantine a pod or take a packet capture is key to ensuring continuous protection against unknown attacks and for any required forensics.

Data protection

Many different regulations apply to data for enterprises. Being able to provide audit reports for specific data regulations is massively important for HIPAA or PCI DSS. Being able to provide reporting for SOC2 compliance may be important. If your tool cannot “see” into the packet before it traverses the kernel, then it cannot prevent data from crossing a “domain” or prevent sensitive information from being leaked.

WAF

A lot of cloud native security tools have the ability to block layer 3 packets. Very few have true layer 7 capabilities. Being able to manage traffic at layer 7 is critical to anyone who is running applications on Kubernetes. Layer 7 is where a lot of unknown vulnerabilities are stopped, but only if the tool can look into the application packet before it traverses the kernel. This is the important point. Once the packet crosses the kernel you are compromised. Use a tool which will learn your workloads behavior. This behavior is the workloads signature and would be the ONLY traffic allowed to traverse the network.

Wrapping it up

Security is the highest scoring word in buzzword bingo these days. Everyone wants to ensure their environments are secure and it takes specialized tools for specific platforms. Don’t use the perimeter firewall as a Kubernetes firewall…it simply will not suffice for complete security inside a Kubernetes cluster. Use a tool which can watch every packet and the data inside every packet ensuring only packets with your workloads signature and nothing else traverses the network. One that allows for visualization of the network along with the traditional scanning, admission control, and runtime security requirements every cloud native implementation requires.

Knowledge spew on GitOps

In working with a handful of customers the concept of GitOps continues to resonate more and more. Let us dive into a brain dump of some of the conversations related to GitOps and how these customers tackled the task at hand.

First thing to remember is these customers are not massive. They are rather common actually. A Gartner defined “medium-sized” enterprise. Keep in mind these customers have the same issues as the giant enterprises just at a different scale.

In every case there was a user story. At a high level, a common theme was the need to roll out updates to a specific application regularly enough to find ways to entice the consumer to purchase a widget of some sort. Ok, A/B testing. Simple enough.

Each of the customers were in different maturity levels when it came to development processes, kubernetes knowledge, and devops methods. However they all have one thing in common…the need to deliver an application to their customer base on a deadline and continuously improve the application based on user feedback. All three of them were successful in meeting their self imposed deadlines. How?

Simple. Every one of them came together, ironed out a plan, and implemented the plan. The interesting part, every one of them already knew how to get the product to market. All they needed was a bit of guidance on how to overcome obstacles and get shit done. How?

  • Step one. Define the top of the mountain, the finish line, the end result.
  • Step two. The project leads built out a high level timeline from end to beginning.
  • Step three. All of the team members came together to build out the task teams.
  • Step four. Each of the teams built out their respective timeline for contribution.
  • Step five. Build.

Now how does this relate to GitOps? GitOps was the pivotal methodology to get it done. The pipeline was built with all of the parts in mind. If you recall the DevOps “infinity loop“, the key is to use that and combine it with the OODA loop decision model. The combination creates a very powerful decision making framework facilitating agile development with constant improvement. Sound simple? It’s not. It is in theory, but the implementation is like a relationship. Everything is great when dating, but the hard work is when dating turns to marriage. Same goes for creating a product. Designing the product, what it needs to do, all of the moving parts is fun. The real work comes in when the first working build is complete.

This is where GitOps shines. The developers build things, test locally, and commit. The pipelines move it through the process and all of the other teams contribute to each part in this machine. If one part breaks down, the other work stops to crowdsource the problem. The problem is fixed and the machine continues on. GitOps is the magical fairy dust. What about the technology?

The technology is rather mundane actually. Git. A code repository. A CI/CD pipeline. A build system. A test harness. A deployment platform. Git…the tools of choice are Github or Gitlab. Github is pretty slick, but Gitlab will allow for running locally in small environments building closed source deliverables. Each has a pipeline mechanism or there are many other tools such as Texton, Argo, CircleCI and many others with various features depending on what was needed. For build systems, many exist and again each as features as needed. However the deployment platform consistently remains the same, Kubernetes.

Building deploy-able applications at scale is hard. There are many other moving parts, processes, tools, etc. in play. However one thing stands out in all of these engagements…give the right people who have the will to succeed the skills needed to succeed and the execution part will look easy.

It is always fun to be a part of something, but its most precious reward is being able to step away and watch the machine run on it’s own.

That’s the end of this spew. It went everywhere…maybe it’s more like a sneeze.

Peace out.

A chat with the GPT about DevOps.

The 1st prompt to set the stage

Me: Tell me why the Devops methodology works the best for cloud native application development. Explain as if you know nothing about development.

chat.openai.com: DevOps is a method of working where development and operations teams collaborate closely to deliver software and systems more efficiently. This approach works well for cloud native application development because it allows for faster and more frequent updates to be made to the application, which is important when working in a cloud environment. Additionally, the focus on automation and testing in DevOps helps to ensure that the application is stable and reliable, which is critical when running in a cloud environment where resources can be scaled up or down as needed. This can help to minimize downtime and ensure that the application is always available to users. Overall, DevOps helps to make the development and delivery of cloud native applications more efficient and reliable.

The 2nd prompt

Me: Explain why AI is important to devops

chatgpt.openai.com: AI (Artificial Intelligence) can be beneficial to DevOps in several ways. One of the main ways that AI can help is by automating certain tasks and processes. For example, AI can be used to automatically detect and diagnose problems in the system, which can help to reduce downtime and improve overall system reliability. Additionally, AI can be used to perform predictive maintenance, which can help to identify potential issues before they occur, allowing them to be addressed before they cause problems.

AI can also be used to improve the performance of the system. For example, it can be used to optimize resource allocation, such as scaling up or down the number of servers as needed to meet changing demand, which can help to improve the efficiency and cost-effectiveness of the system.

AI can also be used to improve the security of the system. For example, it can be used to detect and prevent security threats, such as intrusion attempts, by using machine learning algorithms to identify and respond to abnormal behavior.

Overall, AI can help to improve the speed, efficiency, reliability, performance, and security of DevOps processes, which can help organizations to deliver applications and services more quickly and effectively.

The 3rd prompt

Me: and why is automation a key concept in devops

chat.openai.com: Automation is a key concept in DevOps because it allows for the efficient and consistent execution of repetitive tasks and processes. By automating these tasks, organizations can reduce the risk of human error, increase the speed and accuracy of their work, and free up human resources to focus on more strategic and value-added activities.

In the context of software development, automation can be used to automate tasks such as testing, building, and deploying code. For example, automated testing can help to ensure that the code is working as expected and is free of bugs, while automated building and deployment can help to speed up the process of getting code into production.

In the context of infrastructure management, automation can be used to automate tasks such as provisioning, scaling, and monitoring of resources. For example, automation can be used to automatically spin up new servers as needed to handle increased traffic, and automatically scale back resources when they are no longer needed. This can help to optimize resource utilization and reduce costs.

Overall, automation is important in DevOps because it helps to increase the speed, efficiency, and reliability of the development and delivery process, which can help organizations to deliver applications and services more quickly and effectively.

Wrapping up

Interesting conversation. Instead of a big instruction set, I literally chatted with chat.openai.com. It did manage to describe DevOps fairly well and even though the prose was not exactly advanced chat.openai.com did get the point across based on my prompts. It appears the prose was actually prompted by how the questions were asked. Simple questions, simple responses. Had the questions been more eloquent the responses seem as if they would follow suit. Need to test out that theory next. What fun. Stay tuned.

Declarative vs Imperative in Kubernetes

To be declarative or to be imperative?

Kubernetes is a powerful tool for orchestrating containerized applications across a cluster of nodes. It provides users with two methods for managing the desired state of their applications: the Declarative and Imperative approaches.

The imperative approach

The Imperative approach requires users to manually issue commands to Kubernetes to manage the desired state of their applications. This approach gives users direct control over the state of their applications, but also requires more manual effort and expertise, as well as a more in-depth understanding of Kubernetes. Additionally, the Imperative approach does not provide any version control or rollback capabilities, meaning that users must be more mindful of any changes they make and take extra care to ensure they are not introducing any unintended consequences.

A simple set of imperative commands to create a deployment

To create a Kubernetes deployment using the Imperative approach, users must issue the following commands:

Create a new deployment named my-deployment and use the image my-image:

kubectl create deployment my-deployment --image=my-image

Scale the deployment to 3 pods:

kubectl scale deployment my-deployment --replicas=3

Declarative approach

In the Declarative approach, users express their desired state in the form of Kubernetes objects such as Pods and Services. These objects are then managed by Kubernetes, which ensures that the actual state of the system matches the desired state without requiring users to manually issue commands. This approach also provides version control and rollback capabilities, allowing users to easily revert back to a previous state if necessary.

Below is an example Kubernetes deployment yaml (my-deployment.yaml) which can be used to create the same Kubernetes deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-image:latest
        ports:
        - containerPort: 80

To create or update the deployment using this yaml, use the following command:

kubectl apply -f my-deployment.yaml

Infrastructure as Code

The primary difference between the Declarative and Imperative approaches in Kubernetes is that the Declarative approach is a more automated and efficient way of managing applications, while the Imperative approach gives users more direct control over their applications. Using a Declarative approach to Kubernetes gives rise to managing Infrastructure as Code which is the secret sauce in being able to maintain version control and rollback capabilities.

In general, the Declarative approach is the preferred way to manage applications on Kubernetes as it is more efficient and reliable, allowing users to easily define their desired state and have Kubernetes manage the actual state. However, the Imperative approach can still be useful in certain situations where direct control of the application state is needed. Ultimately, it is up to the user to decide which approach is best for their needs.

Using a dev container in VSCode

How to Use Dev Containers in VSCode

Dev containers are a powerful tool for developers to use when coding, testing, and debugging applications. VSCode provides an integrated development environment (IDE) for developers to use when working with dev containers. This guide will show you how to get started with dev containers in VSCode and how to use them to your best advantage.

  1. Install the Remote – Containers extension
  2. Create a dev container configuration file
  3. Launch the dev container
  4. Connect to the dev container
  5. Start coding!

Installing the Remote – Containers Extension

The first step to using dev containers is to install the Remote – Containers extension. This extension allows you to create dev container configurations and launch them from within VSCode. To install the extension, open the Extensions panel in VSCode and search for Remote – Containers. Click the ‘Install’ button to install the extension. After installation, you will need to restart VSCode for the extension to take effect.

Creating a Dev Container Configuration File

Once the Remote – Containers extension is installed, you can create a dev container configuration file. This file will define the environment for your dev container. For example, you can define the programming language, libraries, and other settings for your dev container. You can also specify a base image to be used by the dev container, such as a Linux or Windows image.

Example Dev Container Configuration File

Below is an example of a dev container configuration file. This configuration file specifies a base image of Ubuntu 18.04, a programming language of Python, and a library of TensorFlow.

{
    "name": "example-dev-container",
    "dockerFile": "Dockerfile",
    "settings": {
        "terminal.integrated.shell.linux": "/bin/bash"
    },
    "remoteUser": "devuser",
    "forwardPorts": [],
    "mounts": [],
    "image": {
        "name": "ubuntu:18.04",
        "remote": false
    },
    "workspaceMount": "/workspace",
    "runArgs": [
        "-v",
        "/workspace:/workspace",
        "-it",
        "--rm",
        "python:3.7.5-stretch"
    ],
    "extensions": [
        "ms-python.python"
    ],
    "libraries": [
        "tensorflow"
    ],
    "postCreateCommand": "",
    "remoteType": "wsl"
}

Launching the Dev Container

Once your dev container configuration file is created, you can launch the dev container. To do this, open the Remote – Containers view in VSCode. You should see your dev container configuration file listed. Click the Launch button to start the dev container. Once the dev container is launched, you will be able to access a terminal window, allowing you to control the dev container.

Connecting to the Dev Container

Once the dev container is running, you can connect to it. To do this, open the Remote – SSH view in VSCode. You should see your dev container listed. Click the Connect button to connect to the dev container. Once connected, you will be able to access the dev container’s terminal window and run commands.

Start Coding!

Now that you’ve connected to the dev container, you can start coding! You can use the integrated development environment (IDE) to write, debug, and test your code. This allows you to work on your project within the dev container, without the need for additional setup. Once you’re done, you can close the dev container and move on to the next project.