Hi I'm Ryan Berger, a Cloud Automation Engineer at Cycle Labs

Hey everyone,

My name is Ryan Berger, and I’m a Cloud Automation Engineer II at Cycle Labs. I have been at Cycle Labs for almost two years now, and it has been quite the ride. So much has changed over those two years! We went from just having an on-premise executable offering, to literally building a SaaS version of Cycle Automation from absolute scratch. Obviously that process has been a lot of things, from exciting to frustrating. In short, I am extremely proud of the work my team and I have accomplished with Cycle Cloud.

My role here is mainly provisioning + supporting the cloud infrastructure that powers not only Cycle Cloud, but our internal infrastructure as well. I have been working with Azure as cloud provider for about 7 years now and have spent a lot of time automating Azure services, as well as manually building them out and managing them. When I first came here, I took this skillset and designed and wrote the code for the Cycle Appliance Azure deployment. One of the things I really wanted to learn and focus on was getting more involved in not just building typical infrastructure (virtual servers, networks, storage, etc) but learning how to deploy containerized applications into Kubernetes following a DevOps approach. Thankfully, that is what I’ve been doing and it has been exactly what I wanted to be doing at this point in my career. It helps that it perfectly aligns with what we’re doing at Cycle Labs!

I am constantly trying to learn about new tools that will make my life easier and allow me to automate things further. We’re living in such a crazy time with tech right now, that it is dang near impossible to keep up with everything. Some tools that have my attention right now and that we’re using at Cycle Labs are:

Kubernetes: The holy grail of containerization! Instrumental to us creating Cycle Cloud as a SaaS application. Kubernetes, or k8s, allows us to scale up or scale down and split our application into various micro services that run on a cluster of computing power within our cloud. Because of the nature of k8s, we automatically get high availability of our micro services since they automatically scale across the cluster. One less things for us to worry about!

Helm: Helm has been a key player in helping us manage our micro services deployments within our Kubnernetes environments. It gives us an easy way to automatically version our deployments and roll them back with one command if something breaks. We can build more complex deployments using Helm charts and really customize our deployments by overriding values of the chart. This allows us to use the same chart to deploy to Development → Staging → Production. Love me some Helm.

Terraform: This is more of a personal interest of mine, but hopefully I start using it for work soon enough. Recently I’ve been considering making the switch from ARM templates (how you automate Azure deployments) to using HashiCorp’s Terraform for writing my cloud automation templates. I really like the fact that it is cloud platform agnostic and not just tied to Azure. As time allows, I plan to start moving the Cycle Appliance over to Terraform!

Outside of tech, and outside of being a dad to a beautiful seven year old girl, my hobbies are pretty analog heavy. I have done film photography for about half of my life, and enjoy the process behind all of that. I spend a lot of time listening to records and reading. My favorite band is Explosions in the Sky, and my favorite author is Haruki Murakami. When staring at a screen for my whole work day, it’s nice to do something that is really, really far away from that.

Thanks for reading!

5 Likes

Wow! There is so much in this post to digest! I didn’t know you had a daughter!

I would love to see a more expanded ELI5 post about some of these tools you’re talking about. Seeing how they apply to Cycle development is an incredibly interesting insight!

I’ve never heard of Haruki Murakami - if I wanted to start with one of their books, where would you suggest?

1 Like

Yes, I do have a kid! :slight_smile:

Sure, I’ll give it my best shot. I’ll start with Kubernetes for today. It won’t be like your 5, but I’ll try and break it down and make it digestable.

Kubernetes: Really at its core, Kubernetes is a containerization platform, which at containerizations core, is sort of the isolating of parts of your application to run in isolated pods (a container), rather than taking a whole virtual machine to run. You can start to isolate these smaller pods across multiple virtual servers (part of a Kubernetes cluster) to create highly available applications that can be scaled up or down the cluster.

The diagram below should help with an understanding of a bare metal server, compared to a virtual server, compared to a containerized application. It’s layers of abstraction and complexity being removed to make it easier and easier for your applications to run somewhere (a Kubernetes cluster in this case).

Kubernetes pods start with a base image to use, which can be a custom image that you create or something simple like Ubuntu. The pods can be created using a Kubernetes manifest file which basically talks to the Kubernetes API and tells it to do something (build, destroy, change). The code below is a very basic pod that I created to run some debugging steps - so I can APPLY this manifest to our Kubernetes cluster using the Kubernetes API command line, and then a pod will be created using the Ubuntu image.

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu
  labels:
    app: ubuntu
spec:
  containers:
  - image: ubuntu
    command:
      - "sleep"
      - "604800"
    imagePullPolicy: IfNotPresent
    name: ubuntu
  restartPolicy: Always

This is a very basic example of an ‘application’ running in Kubernetes, but it gives you the idea. I now have a pod that is running Ubuntu, that I can remote into and run debugging commands (dns lookups, ping, etc etc) that takes literally fractions of resources to run compared to running full on Ubuntu on an actual laptop, or even a virtual server. That pod also gets created on the same virtual network as the rest of the Kubernetes cluster, so it can communicate with all of the other pods/services that exist in that cluster. So I hope you can see how this is rather powerful.

Next, is the idea of a service in Kubernetes. An abstract way to expose a network service on a pod/pods so that they can be accessed from other pods within the cluster (or later, from outside of the cluster using an ingress controller!). The neat thing about services in Kubernetes is that they can be defined to a logical set of pods, and since pods are nonpermanent things, the service will remain active as the pods are created/destroyed (like due to a new deployment, etc) and come back online with different IP addresses. The services get linked to pods via a selector (in the example below, pods with the same select of MyApp will be hooked up to this service that exposes port 9376).

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Now we can see use case for this internally but where it really shines is when we start talking about the idea of ingress within Kubernetes. To quote the official Kubernetes definition, “Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.” This is where things really get interesting. Allowing your private pods to be accessed from public web endpoints (like https://app.cyclelabs.io) allows you to let folks in from outside of your cluster, to use your application that is powered by micro services from within Kubernetes.

1 Like

I have read a few Murakami books thus far. The first one I read, as apart of a book club with Ryan, Brian, and Mitch, was “The Wind Up Bird Chronicles” which was excellent. It got quite surreal and brought some unique literary techniques. From what I can tell, it is one of his most commonly read books. I read “After Dark” which felt kind of like a long short-story, but still quite good. I am close to finishing “Killing Commendatore” and it’s probably been my favorite of his. Not quite as surreal as Wind Up Bird, but still a bit mystical and a bit more suspenseful.

2 Likes

These are some top quality posts, Ryan :clap:. Great breakdown of the basics of Kubernetes.

2 Likes

Agreed @cameren.dolecheck!

@ryan.berger it would be great to publish a blog post about how we use K8S with Cycle!

Still one of my favorites. A Wind Up Bird tattoo is in my near future.

We’re definitely in talks about this! Thanks @Josh

1 Like

Wow! That was an incredible deluge of information. I think I’m going to have to read it a few more times to fully wrap my head around it, but I think I understand the basics. That’s really cool! Thank you!

2 Likes

I wish we could react to posts with something other than :heart:s because I would put a :fire:.

1 Like